Skip to content

Latest commit

 

History

History
86 lines (57 loc) · 6.81 KB

File metadata and controls

86 lines (57 loc) · 6.81 KB
title 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
/code-security/concepts/vulnerability-reporting-and-management/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.