-
Notifications
You must be signed in to change notification settings - Fork 30k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: sync security policy with nodejs.org
The Node.js security disclosure policy has diverged between the website and github: - https://nodejs.org/en/security/ - https://github.com/nodejs/node/security/policy The website is more recent and accurate, so sync the content from: - https://github.com/nodejs/nodejs.org/blob/master/locale/en/security.md PR-URL: #29682 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
- Loading branch information
1 parent
35e1d8c
commit 0041f1c
Showing
1 changed file
with
64 additions
and
26 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,37 +1,75 @@ | ||
# Security | ||
|
||
If you find a security vulnerability in Node.js, please report it to | ||
security@nodejs.org. Please withhold public disclosure until after the security | ||
team has addressed the vulnerability. | ||
## Reporting a Bug in Node.js | ||
|
||
The security team will acknowledge your email within 24 hours. You will receive | ||
a more detailed response within 48 hours. | ||
Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs). | ||
|
||
There are no hard and fast rules to determine if a bug is worth reporting as a | ||
security issue. Here are some examples of past issues and what the Security | ||
Response Team thinks of them. When in doubt, please do send us a report | ||
nonetheless. | ||
Your report will be acknowledged within 24 hours, and you’ll receive a more | ||
detailed response to your report within 48 hours indicating the next steps in | ||
handling your submission. | ||
|
||
## Public disclosure preferred | ||
After the initial reply to your report, the security team will endeavor to keep | ||
you informed of the progress being made towards a fix and full announcement, | ||
and may ask for additional information or guidance surrounding the reported | ||
issue. These updates will be sent at least every five days; in practice, this | ||
is more likely to be every 24-48 hours. | ||
|
||
* [#14519](https://github.com/nodejs/node/issues/14519): _Internal domain | ||
function can be used to cause segfaults_. Requires the ability to execute | ||
arbitrary JavaScript code. That is already the highest level of privilege | ||
possible. | ||
### Node.js Bug Bounty Program | ||
|
||
## Private disclosure preferred | ||
The Node.js project engages in an official bug bounty program for security | ||
researchers and responsible public disclosures. The program is managed through | ||
the HackerOne platform. See <https://hackerone.com/nodejs> for further details. | ||
|
||
* [CVE-2016-7099](https://nodejs.org/en/blog/vulnerability/september-2016-security-releases/): | ||
_Fix invalid wildcard certificate validation check_. This was a high-severity | ||
defect. It caused Node.js TLS clients to accept invalid wildcard certificates. | ||
## Reporting a Bug in a third party module | ||
|
||
* [#5507](https://github.com/nodejs/node/pull/5507): _Fix a defect that makes | ||
the CacheBleed Attack possible_. Many, though not all, OpenSSL vulnerabilities | ||
in the TLS/SSL protocols also affect Node.js. | ||
Security bugs in third party modules should be reported to their respective | ||
maintainers and should also be coordinated through the Node Ecosystem Security | ||
Team via [HackerOne](https://hackerone.com/nodejs-ecosystem). | ||
|
||
* [CVE-2016-2216](https://nodejs.org/en/blog/vulnerability/february-2016-security-releases/): | ||
_Fix defects in HTTP header parsing for requests and responses that can allow | ||
response splitting_. This was a remotely-exploitable defect in the Node.js | ||
HTTP implementation. | ||
Details regarding this process can be found in the | ||
[Security Working Group repository](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md). | ||
|
||
When in doubt, please do send us a report. | ||
Thank you for improving the security of Node.js and its ecosystem. Your efforts | ||
and responsible disclosure are greatly appreciated and will be acknowledged. | ||
|
||
## Disclosure Policy | ||
|
||
Here is the security disclosure policy for Node.js | ||
|
||
* The security report is received and is assigned a primary handler. This | ||
person will coordinate the fix and release process. The problem is confirmed | ||
and a list of all affected versions is determined. Code is audited to find | ||
any potential similar problems. Fixes are prepared for all releases which are | ||
still under maintenance. These fixes are not committed to the public | ||
repository but rather held locally pending the announcement. | ||
|
||
* A suggested embargo date for this vulnerability is chosen and a CVE (Common | ||
Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability. | ||
|
||
* On the embargo date, the Node.js security mailing list is sent a copy of the | ||
announcement. The changes are pushed to the public repository and new builds | ||
are deployed to nodejs.org. Within 6 hours of the mailing list being | ||
notified, a copy of the advisory will be published on the Node.js blog. | ||
|
||
* Typically the embargo date will be set 72 hours from the time the CVE is | ||
issued. However, this may vary depending on the severity of the bug or | ||
difficulty in applying a fix. | ||
|
||
* This process can take some time, especially when coordination is required | ||
with maintainers of other projects. Every effort will be made to handle the | ||
bug in as timely a manner as possible; however, it’s important that we follow | ||
the release process above to ensure that the disclosure is handled in a | ||
consistent manner. | ||
|
||
## Receiving Security Updates | ||
|
||
Security notifications will be distributed via the following methods. | ||
|
||
* <https://groups.google.com/group/nodejs-sec> | ||
* <https://nodejs.org/en/blog/> | ||
|
||
## Comments on this Policy | ||
|
||
If you have suggestions on how this process could be improved please submit a | ||
[pull request](https://github.com/nodejs/nodejs.org) or | ||
[file an issue](https://github.com/nodejs/security-wg/issues/new) to discuss. |