安全报告

¥Security Reporting

有关有效安全策略的更多详细信息，请查看 此页面。

¥For more details on active Security Policies, checkout this page.

报告 Node.js 中的漏洞

¥Reporting a bug in Node.js

通过 HackerOne 报告 Node.js 中的安全漏洞。

¥Report security bugs in Node.js via HackerOne.

通常情况下，你的报告将在 5 天内得到确认，你将在 10 天内收到更详细的回复，其中会说明处理你提交报告的后续步骤。当我们的分类志愿者休假时，尤其是在年底，这些时间表可能会延长。

¥Normally, your report will be acknowledged within 5 days, and you'll receive a more detailed response to your report within 10 days indicating the next steps in handling your submission. These timelines may extend when our triage volunteers are away on holiday, particularly at the end of the year.

在对你的报告进行初步响应后，安全团队将尽力向你通报修复和完整公告的进展情况，并可能要求你提供有关所报告问题的更多信息或指导。

¥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 漏洞赏金计划

¥Node.js bug bounty program

Node.js 项目参与了面向安全研究人员和负责任的公开披露的官方漏洞赏金计划。该项目通过 HackerOne 平台进行管理。更多详情请参阅 https://hackerone.com/nodejs。

¥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.

信息披露政策

¥Disclosure policy

以下是 Node.js 的安全披露政策

¥Here is the security disclosure policy for Node.js

• 收到安全报告后，会指派一名主要处理人员。此人将协调修复和发布流程。针对所有受支持的 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 validated against all supported Node.js versions. Once confirmed, a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all supported releases. These fixes are not committed to the public repository but rather held locally pending the announcement.

• 我们已选定此漏洞的建议发布日期，并已申请该漏洞的 CVE（通用漏洞披露 (CVE®)）。

  ¥A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.

• 在禁令生效日期，公告副本将发送至 Node.js 安全邮件列表。更改将推送到公共仓库，新版本将部署到 nodejs.org。在邮件列表收到通知后的 6 小时内，公告副本将在 Node.js 博客上发布。

  ¥On the embargo date, a copy of the announcement is sent to the Node.js security mailing list. 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.

• 通常，禁运日期将在 CVE 发布后 72 小时设定。但是，这可能会根据错误的严重程度或修复难度而有所不同。

  ¥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 we need to coordinate with maintainers of other projects. We will try to handle the bug as quickly as possible; however, we must follow the release process above to ensure that we handle disclosure consistently.

接收安全更新

¥Receiving security updates

安全通知将通过以下方式分发。

¥Security notifications will be distributed via the following methods.

• Google Group

• Node.js 博客

  ¥Node.js Blog

对此政策的评论

¥Comments on this policy

如果你有任何关于如何改进此流程的建议，请访问 nodejs/security-wg 代码库。

¥If you have suggestions on how this process could be improved, please visit the nodejs/security-wg repository.

OpenSSF 最佳实践

¥OpenSSF Best Practices

开源安全基金会 (OpenSSF) 最佳实践徽章 是自由/自由和开源软件 (FLOSS) 项目展示其遵循最佳实践的一种方式。项目可以自愿进行自我认证，以确认其遵循各项最佳实践的方式。徽章使用者可以快速评估哪些 FLOSS 项目遵循最佳实践，从而更有可能开发更高质量的安全软件。

¥The Open Source Security Foundation (OpenSSF) Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices. Projects can voluntarily self-certify how they follow each best practice. Consumers of the badge can quickly assess which FLOSS projects are following best practices and as a result are more likely to produce higher-quality secure software.