diff --git a/content/github/managing-security-vulnerabilities/about-disclosing-vulnerabilities.md b/content/github/managing-security-vulnerabilities/about-disclosing-vulnerabilities.md index f4e1209941..bb7a4db383 100644 --- a/content/github/managing-security-vulnerabilities/about-disclosing-vulnerabilities.md +++ b/content/github/managing-security-vulnerabilities/about-disclosing-vulnerabilities.md @@ -14,9 +14,9 @@ The initial report of a vulnerability is made privately, and the full details ar #### Best practices for security researchers -Security researchers should try to report vulnerabilities privately to maintainers. When possible, please avoid: +Security researchers should try to report vulnerabilities privately to maintainers. When possible, as a security researcher, you should avoid: - Disclosing the vulnerability publicly -- Bypassing the maintainer +- Bypassing the maintainers - Disclosing the vulnerability before a fixed version of the code is available - Expecting to be compensated for reporting an issue, where no public bounty program exists @@ -25,18 +25,18 @@ It's acceptable for security researchers to disclose a vulnerability publicly af #### Best practices for maintainers Maintainers should disclose vulnerabilities in a timely manner. If there is a security vulnerability in your repository, you should: -- Treat the vulnerability as a security issue rather than a simple bug +- Treat the vulnerability as a security issue rather than a simple bug, both in your response and your disclosure. For example, you'll need to explicitly mention that the issue is a security vulnerability in the release notes. - Plan to disclose the vulnerability responsibly - Give credit where credit is due - Aim to publish a fix as soon as you can Publishing the details of a security vulnerability doesn't make maintainers look bad. Security vulnerabilities are present everywhere in software nowadays, and users will trust maintainers who have a clear and established process for disclosing security vulnerabilities in their code. -### About reporting and disclosing vulnerabilities in {% data variables.product.prodname_dotcom %} +### About reporting and disclosing vulnerabilities in projects on {% data variables.product.prodname_dotcom %} The process for reporting and disclosing vulnerabilities for projects on {% data variables.product.prodname_dotcom_the_website %} 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](/github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository#about-security-policies)." If there is one, follow it to understand the process before contacting the security team for that repository. If there isn't a security policy for the repository, you may try to privately contact the maintainer based on information available in the _security.md_ file. + 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](/github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository#about-security-policies)." If there is one, follow it to understand the process before contacting the security team for that repository. If there isn't a security policy for the repository, you may try to privately contact the maintainers based on information available in the _security.md_ file. {% note %} @@ -44,9 +44,13 @@ The process for reporting and disclosing vulnerabilities for projects on {% data {% endnote %} + If you've found a security vulnerability in {% data variables.product.prodname_dotcom_the_website %}, please report the vulnerability through our responsible disclosure process. For more information, see the [{% data variables.product.prodname_dotcom %} Security Bug Bounty](https://bounty.github.com/) website. + If you are a maintainer, it's likely that a security researcher will email you or otherwise privately contact you. Alternatively, someone may open a (public) issue with details of a security issue. As a maintainer, to disclose a vulnerability that exists in your repository, you first create a draft security advisory in your package's repository in {% data variables.product.prodname_dotcom %}. {% data reusables.security-advisory.security-advisory-overview %} For more information, see "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories)." To get started, see "[Creating a security advisory](/github/managing-security-vulnerabilities/creating-a-security-advisory)." + + diff --git a/content/github/managing-security-vulnerabilities/about-github-security-advisories.md b/content/github/managing-security-vulnerabilities/about-github-security-advisories.md index 902140c58d..c44501f78a 100644 --- a/content/github/managing-security-vulnerabilities/about-github-security-advisories.md +++ b/content/github/managing-security-vulnerabilities/about-github-security-advisories.md @@ -24,11 +24,7 @@ With {% data variables.product.prodname_security_advisories %}, you can: 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. For more information, see "[Publishing a security advisory](/github/managing-security-vulnerabilities/publishing-a-security-advisory)." -{% note %} - -**Note**: {% data variables.product.prodname_dotcom %} and npm currently publish advisories on both [github.com/advisories](https://github.com/advisories) and [npmjs.com/advisories](https://www.npmjs.com/advisories). - -{% endnote %} +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](https://github.com/advisories). 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](https://www.npmjs.com/advisories). {% data reusables.repositories.security-advisories-republishing %} diff --git a/data/reusables/security-advisory/disclosing-vulnerabilities.md b/data/reusables/security-advisory/disclosing-vulnerabilities.md index 5de3bfbed9..b4d42c8481 100644 --- a/data/reusables/security-advisory/disclosing-vulnerabilities.md +++ b/data/reusables/security-advisory/disclosing-vulnerabilities.md @@ -1 +1 @@ -Vulnerability disclosure is an area where collaboration between security researchers and project maintainers is very important, from the moment a potentially harmful security vulnerability is found, right until a vulnerability is disclosed to the world, ideally with a patch available. Typically, when someone lets a maintainer know privately about a security vulnerability, the maintainer develops a fix, validates it, and notifies the users of a project or a package. +Vulnerability disclosure is an area where collaboration between security researchers and project maintainers is very important, from the moment a potentially harmful security vulnerability is found, right until a vulnerability is disclosed to the world, ideally with a patch available. Typically, when someone lets a maintainer know privately about a security vulnerability, the maintainer develops a fix, validates it, and notifies the users of the project or package.