The Wayback Machine - https://web.archive.org./web/20201027071751/https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/about-github-security-advisories

About GitHub Security Advisories

You can use GitHub Security Advisories to privately discuss, fix, and publish information about security vulnerabilities in your repository.

In this article

Did this doc help you?

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

Or, learn how to contribute.

Anyone with admin permissions to a repository can create a security advisory.

Anyone with admin permissions to a repository also has admin permissions to all security advisories in that repository. People with admin permissions to a security advisory can add collaborators, and collaborators have write permissions to the security advisory.

Note: If you are a security researcher, you should directly contact maintainers to ask them to create security advisories or issue CVEs on your behalf in repositories that you don't administer.

About GitHub Security Advisories

GitHub 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 GitHub 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.

You can also use GitHub Security Advisories to republish the details of a security vulnerability that you have already disclosed elsewhere by copying and pasting the details of the vulnerability into a new security advisory.

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."

You can create a security policy to give people instructions for responsibly reporting security vulnerabilities in your project. For more information, see "Adding a security policy to your repository."

You can also join GitHub Security Lab to browse security-related topics and contribute to security tools and projects.

CVE identification numbers

GitHub Security Advisories builds upon the foundation of the Common Vulnerabilities and Exposures (CVE) list. GitHub 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 GitHub, you have the option of providing an existing CVE identification number for the security vulnerability. If you don't already have a CVE identification number for the security vulnerability in your project, you can request a CVE identification number from GitHub. GitHub usually reviews the request within 72 hours. Requesting a CVE identification number doesn't make your security advisory public. If your security advisory is eligible for a CVE, GitHub will reserve a CVE identification number for your advisory. We'll then publish the CVE details after you publish the security advisory.

Once you've published the security advisory and GitHub has assigned a CVE identification number to the vulnerability, GitHub publishes the CVE to the MITRE database. For more information, see "Publishing a security advisory."

GitHub Dependabot alerts for published security advisories

GitHub will review each published security advisory, add it to the GitHub Advisory Database, and may use the security advisory to send GitHub 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 GitHub may contact you for more information.

For more information about GitHub Dependabot alerts, see "About alerts for vulnerable dependencies." For more information about GitHub Advisory Database, see "Browsing security vulnerabilities in the GitHub Advisory Database."

Did this doc help you?

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

Or, learn how to contribute.