1
0
mirror of synced 2026-01-02 12:04:38 -05:00

address more review comments

This commit is contained in:
mchammer01
2021-02-25 14:48:08 +00:00
parent df93083368
commit 6fbe885935
3 changed files with 11 additions and 11 deletions

View File

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

View File

@@ -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 %}

View File

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