6.8 KiB
title, intro, redirect_from, versions
| title | intro | redirect_from | versions | ||||
|---|---|---|---|---|---|---|---|
| About GitHub Security Advisories | You can use {% data variables.product.prodname_security_advisories %} to privately discuss, fix, and publish information about security vulnerabilities in your repository. |
|
|
{% data reusables.repositories.security-advisory-admin-permissions %}
{% data reusables.security-advisory.security-researcher-cannot-create-advisory %}
About disclosing vulnerabilities
When someone lets an organization maintainer know privately about a vulnerability, the maintainer tipically develops a fix, validates it, and notifies the repository users. The initial report of a vulnerability is made privately, and the full details are only published once a patch has been made available, sometimes with a delay to allow more time for the patches to be installed. For more information, see the "OWASP Cheat Sheet Series about vulnerability disclosure."
Maintainers should disclose vulnerabilities in a timely manner, if there is a security vulnerability in their repository. It's not acceptable to:
- Not disclose the vulnerability
- Not identify the vulnerability as a security issue
- Wait an unacceptably long time to create a fix
Publishing the details of a security vulnerability on your code doesn't make you look bad. Security vulnerabilities are present everywhere in sofware nowadays, and your users will thank you if you demonstrate a clear and established process for disclosing security vulnerabilities in your software instead of hiding issues with your code.
Security researchers should disclose vulnerabilities privately to maintainers. It's not acceptable to:
- Disclose the vulnerability publicly
- Not contact the maintainer,
- Disclose the vulnerability before patching the code
It's seen as fine for security researchers to disclose a vulnerability publicly after a period of time, if they have tried to contact the maintainers and not received a response, or contacted them and been asked to wait too long to disclose it.
About {% data variables.product.prodname_security_advisories %}
Here at {% data variables.product.company_short %}, the process for disclosing vulnerabilities is as follows:
If you are a security researcher who would like report a vulnerability:
- First check if there is a security policy for the related repository. For more information, see "About security policies."
- If there is one, follow it to understand the process before contacting the security team for that repository.
If you are a maintainer, it's likely that a security researcher will email you or otherwise privately contact you. This can be, for example, based on information in your security.md file. Alternatively, someone may open a (public) issue with details of a security issue.
{% note %}
Note: For npm only—if you report a vulnerability to npm, we try to contact you privately. If you don't address the issue in a timely manner, we will disclose it. For more information, see "Reporting malware in an npm package" in the npm Docs website.
{% endnote %}
As a maintainer, to disclose a vulnerability that exists in your repository (for example if someone got in touch and reported a vulnerability to you), you create a draft {% data variables.product.prodname_dotcom %} security advisory in your package's {% data variables.product.prodname_dotcom %} repository.
{% data variables.product.prodname_security_advisories %} allows repository maintainers to privately discuss and fix a security vulnerability in a project. After collaborating on a fix, repository maintainers can publish the security advisory to publicly disclose the security vulnerability to the project's community. By publishing security advisories, repository maintainers make it easier for their community to update package dependencies and research the impact of the security vulnerabilities.
With {% data variables.product.prodname_security_advisories %}, you can:
- Create a draft security advisory, and use the draft to privately discuss the impact of the vulnerability on your project.
- Privately collaborate to fix the vulnerability in a temporary private fork.
- Publish the security advisory to alert your community of the vulnerability once a patch is released.
{% note %}
Note: {% data variables.product.prodname_dotcom %} and npm currently publish advisories on both github.com/advisories and npmjs.com/advisories.
{% endnote %}
{% data reusables.repositories.security-advisories-republishing %}
To get started, see "Creating a security advisory."
You can give credit to individuals who contributed to a security advisory. For more information, see "Editing a security advisory."
{% data reusables.repositories.security-guidelines %}
{% data reusables.repositories.github-security-lab %}
CVE identification numbers
{% data variables.product.prodname_security_advisories %} builds upon the foundation of the Common Vulnerabilities and Exposures (CVE) list. The security advisory form on {% data variables.product.prodname_dotcom %} is a standardized form that matches the CVE description format. {% data variables.product.prodname_dotcom %} is a CVE Numbering Authority (CNA) and is authorized to assign CVE identification numbers. For more information, see "About CVE" and "CVE Numbering Authorities" on the CVE website.
When you create a security advisory for a public repository on {% data variables.product.prodname_dotcom %}, you have the option of providing an existing CVE identification number for the security vulnerability. {% data reusables.repositories.request-security-advisory-cve-id %}
Once you've published the security advisory and {% data variables.product.prodname_dotcom %} has assigned a CVE identification number to the vulnerability, {% data variables.product.prodname_dotcom %} publishes the CVE to the MITRE database. For more information, see "Publishing a security advisory."
{% data variables.product.prodname_dependabot_alerts %} for published security advisories
{% data reusables.repositories.github-reviews-security-advisories %}