Skip to content

Latest commit

 

History

History
85 lines (56 loc) · 6.71 KB

File metadata and controls

85 lines (56 loc) · 6.71 KB
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
/articles/about-maintainer-security-advisories
/github/managing-security-vulnerabilities/about-maintainer-security-advisories
/github/managing-security-vulnerabilities/about-github-security-advisories
/code-security/security-advisories/about-github-security-advisories
/code-security/repository-security-advisories/about-github-security-advisories-for-repositories
/code-security/security-advisories/repository-security-advisories/about-repository-security-advisories
/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories
versions
fpt ghec
*
*
contentType concepts
product {% data reusables.gated-features.private-vulnerability-reporting %}
category
Report and disclose vulnerabilities

About repository security advisories

{% data reusables.security-advisory.disclosing-vulnerabilities %} For more information, see AUTOTITLE.

{% data reusables.security-advisory.security-advisory-overview %}

With repository security advisories, you can:

  1. Create a draft security advisory, and use the draft to privately discuss the impact of the vulnerability on your project.
  2. Privately collaborate to fix the vulnerability in a temporary private fork.
  3. 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 %}

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.

Publication of security advisories

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_dependabot_alerts %} for published security advisories

{% 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.

Importance of fix versions

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.