75 lines
3.3 KiB
Markdown
75 lines
3.3 KiB
Markdown
|
# Security
|
|||
|
|
|
|||
|
|
## Reporting a Bug in Node.js
|
|||
|
|
|
|||
|
|
Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs).
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
### Node.js Bug Bounty Program
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
## Reporting a Bug in a third party module
|
|||
|
|
|
|||
|
|
Security bugs in third party modules should be reported to their respective
|
|||
|
|
maintainers and should also be coordinated through the Node.js Ecosystem
|
|||
|
|
Security Team via [HackerOne](https://hackerone.com/nodejs-ecosystem).
|
|||
|
|
|
|||
|
|
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).
|
|||
|
|
|
|||
|
|
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.
|