address more review comments
This commit is contained in:
@@ -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)."
|
||||
|
||||
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user