4.5 KiB
title, intro, miniTocMaxHeadingLevel, versions
| title | intro | miniTocMaxHeadingLevel | versions | ||
|---|---|---|---|---|---|
| About disclosing vulnerabilities | Vulnerability disclosure is a responsible and coordinated effort between security researchers and repository maintainers. | 4 |
|
About disclosing vulnerabilities in the industry
{% data reusables.security-advisory.disclosing-vulnerabilities %}
The initial report of a vulnerability is made privately, and the full details are only published once the maintainer has acknowledged the issue, and ideally made remediations or a patch available, sometimes with a delay to allow more time for the patches to be installed. For more information, see the "OWASP Cheat Sheet Series about vulnerability disclosure" on the OWASP Cheat Sheet Series website.
Best practices for security researchers
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 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
It's acceptable for security researchers to disclose a vulnerability publicly after a period of time, if they have tried to contact the maintainers and not received a response, or contacted them and been asked to wait too long to disclose it.
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, 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 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." 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 %}
Note: For npm only - If we receive a report of malware in an npm package, we try to contact you privately. If you don't address the issue in a timely manner, we will disclose it. For more information, see "Reporting malware in an npm package" on the npm Docs website.
{% 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 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 %}."
To get started, see "Creating a security advisory."