From 0041f1c0d3c32d1e4c19c2d19d71edb8bb3acff4 Mon Sep 17 00:00:00 2001 From: Sam Roberts Date: Mon, 23 Sep 2019 16:03:26 -0700 Subject: [PATCH] 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: https://github.com/nodejs/node/pull/29682 Reviewed-By: James M Snell Reviewed-By: Matteo Collina Reviewed-By: Luigi Pinca --- SECURITY.md | 90 +++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 64 insertions(+), 26 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index a82c5f48ceac12..7e984b7ba36872 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -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 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. + +* +* + +## 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.