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 <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

1 files changed, 64 insertions, 26 deletions

diff --git a/SECURITY.md b/SECURITY.md
index a82c5f48ce..7e984b7ba3 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 <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.