| title | About repository security advisories | |||||||
|---|---|---|---|---|---|---|---|---|
| intro | You can use repository security advisories to privately discuss, fix, and publish information about security vulnerabilities in your public repository. | |||||||
| shortTitle | Repository security advisories | |||||||
| redirect_from |
|
|||||||
| versions |
|
|||||||
| contentType | concepts | |||||||
| product | {% data reusables.gated-features.private-vulnerability-reporting %} | |||||||
| category |
|
{% data reusables.security-advisory.disclosing-vulnerabilities %} For more information, see AUTOTITLE.
{% data reusables.security-advisory.security-advisory-overview %}
With repository 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.
{% data reusables.repositories.security-advisories-republishing %}
{% ifversion repository-security-advisories-API %} You can also use the REST API to create, list, and update repository security advisories. For more information, see AUTOTITLE. {% endif %}
You can give credit to individuals who contributed to a security advisory. For more information, see AUTOTITLE.
{% data reusables.repositories.security-guidelines %}
If you created a security advisory in your repository, the security advisory will stay in your repository. We publish security advisories for any of the ecosystems supported by the dependency graph to the {% data variables.product.prodname_advisory_database %} on github.com/advisories. Anyone can submit a change to an advisory published in the {% data variables.product.prodname_advisory_database %}. For more information, see AUTOTITLE.
If a security advisory is specifically for npm, we also publish the advisory to the npm security advisories. For more information, see npmjs.com/advisories.
{% data reusables.repositories.github-security-lab %}
{% 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.
Publishing a security advisory notifies your community about the vulnerability it addresses, making it easier for them to update package dependencies and research the impact of the vulnerability.
When you publish a draft advisory from a public repository, visibility levels vary as follows:
- Anyone can see the current version of the advisory data, as well as any advisory credits that the credited users have accepted.
- Collaborators can view the conversation history of the advisory.
The URL of a security advisory does not change after publication.
If you need to update or correct information in a security advisory that you've published, you can edit the security advisory. See AUTOTITLE.
{% data variables.product.prodname_dotcom %} will review each published security advisory, add it to the {% data variables.product.prodname_advisory_database %}, and may use the security advisory to send {% data variables.product.prodname_dependabot_alerts %} to affected repositories. If the security advisory comes from a fork, we'll only send an alert if the fork owns a package, published under a unique name, on a public package registry. This process can take up to 72 hours and {% data variables.product.prodname_dotcom %} may contact you for more information.
Whenever possible, you should add a fix version to a security advisory prior to publishing the advisory. If you don't, the advisory will be published without a fixed version, and {% data variables.product.prodname_dependabot %} will alert your users about the issue, without offering any safe version to update to.
Depending on the vulnerability, you may need to adjust your approach. If a fix version is:
- Imminently available, and you are able to, wait to disclose the issue when the fix is ready.
- In development but not yet available, mention this in the advisory, and edit the advisory later, after publication.
- Not planned, be clear about it in the advisory so that your users don't contact you to ask when a fix will be made. In this case, it is helpful to include steps users can take to mitigate the issue.