作为维护者和发布者，如何在 npm 包中声明安全漏洞？ 质量安全报告应包含哪些内容哪些不应该报告

如何解决作为维护者和发布者，如何在 npm 包中声明安全漏洞？ 质量安全报告应包含哪些内容哪些不应该报告

当我发现自己发布的某个软件包中存在安全漏洞时，如何标记一系列易受影响的版本，以便下游消费者在运行 npm audit 时收到通知？

解决方法

本质上，您本身不会标记一系列易受影响的版本。相反，您可以通过 “报告恶意软件” 按钮直接向 NPM 报告，该按钮位于 www.npmjs.com 的特定 npm 包页面上。然后 npm 安全团队对报告进行分类，并在数据库中对其进行标记。然后在运行 npm audit 命令时相应地通知用户。

有关更多详细信息，请参阅 npm 博客中的 this post。虽然 npm 博客已停止使用，但 AFAIK 报告安全漏洞的过程大致相同。

下面引用了有关您需要向 NPM 提供的有关漏洞的信息的相关部分...

_{来源： https://blog.npmjs.org/post/179430064885/writing-quality-vulnerability-reports.html}

为了确保快速有效地处理报告的漏洞，我们需要您，我们的社区，向我们提供可操作的详细信息。以下是安全报告的一些基本注意事项：

质量安全报告应包含哪些内容

• 您遇到漏洞的软件包名称和版本。示例：标记@1.0.0 或标记@*
• 对该漏洞及其影响的简短描述。 示例：“如果用户能够控制对函数 foo 的输入，那么用户就能够执行命令，为攻击者提供与运行应用程序的用户相同的访问权限。”立>
• 您遇到漏洞的环境的详细信息。 示例：“发现可以在 OSX 上使用 node.js 6.0.0 进行利用，但未使用任何其他平台或 Node.js 版本进行测试。”
• 可证明的概念证明或重现相同结果的步骤。这有助于 npm 安全团队有效地对问题进行分类（请参见下面的示例）。
• 任何可能有助于 npm 安全团队或维护者更好地理解的特定参考、代码片段或文档（请参见下面的示例）。

哪些不应该报告

• 没有可操作上下文的报告对于我们的团队进行充分处理非常耗时。这些请求应以问题的形式提交给包维护者。
• npm 审计的输出 - 由于 npm 安全团队已经知道这些缺陷，因此最好直接与维护者联系以更新依赖项版本。
• 一般功能请求
• 堆栈跟踪或错误，但不解释它们对安全的影响。