如何评估NPM软件包依赖项的安全性？近年来，编程领域已转向越来越高的安全标准。在过去五年中，超过50%的数据泄露事件在增加，并且记录了大量的网络犯罪攻击，因此，确保在线服务的安全性和可操作性正在逐渐消耗开发团队的时间。数据泄露的成本可能会使一家老牌公司瘫痪，更不用说可能会使一家初创公司被判处死刑。这就是为什么在每个级别上努力减少和减轻所开发软件的安全威胁非常重要的原因。
一、包裹检查工具
让我们从一些简单的命令开始，您可以将它们添加到构建脚本中或作为CI/CD步骤。
1.npm重复数据删除
重复数据删除命令只是尝试通过将依赖关系上移树来简化依赖关系。本质上，试图拥有一个可以被更多软件包使用的兼容的依赖项，而不是每个软件包都有其自己稍有不同的版本。更少的版本可以通过所说的依赖关系提供更少的攻击媒介（较新的版本往往具有针对已知和已发布漏洞的修复程序）。
2.npm审核
一个非常强大的命令，它将扫描您的项目中的所有已知漏洞，并为您提供安全报告以及潜在的修复程序。在某些情况下，它甚至可以为您更新软件包。在其他情况下，它仅告诉您如何进行修复。虽然功能非常强大，但也有其局限性。即它只能检查报告给npm
Registry的已知漏洞。对于所有尚未通过验证的漏洞，您真是不走运。
3.OWASP依赖项检查
OWASP依赖项检查是根据已知漏洞的公共数据库检查依赖项的。它具有一个CLI工具，可在本地存储要检查的整个数据库。这使得它适合您不想授予完全访问权限的系统。
4.NPQ
使用此命令行实用程序，您可以检查是否存在不良依赖关系，并提示您确认是否注意到您试图安装具有已知漏洞的软件包。
在这里，您可以找到一系列精选的面向安全性的不同node.js安全性资源。对于简单更新不那么容易的情况，它对于修复或缓解问题和漏洞可能很有用。
二、超越自动检查
除了可以添加到常规代码工作流中的内容之外，您可能还需要定期进行更深入的软件包分析。尝试为您的项目回答以下问题：
我要用这个模块做什么？还是有必要吗？
1.是否存在使用不同模块（或我们的代码）来解决同一问题的情况？
2.哪些软件包带有大多数子模块？我可以用一些“更扁平的”包装代替它们吗？
3.他们都还在积极发展吗？哪些长期未更新或没有活跃的开发人员？
4.看一下他们的问题/错误跟踪器，是否有关于漏洞或错误代码的报告？
5.他们是否发布测试覆盖率，通过和/或任何其他代码质量指标？
上面的问题将帮助您评估是否必须更新任何软件包或将其替换为替代软件包，或者甚至由团队进行编码。但是您可能必须走的更远。上面的问题集中于一些攻击媒介。主要是在开发人员有意或无意中将漏洞引入其代码库的情况。但是，如果发布者的用户帐户受到威胁该怎么办？
密码错误和重复是一个现实，它会影响每个在线服务（包括npm注册表）的安全性。如果您具有发布者的密码，则可以使用git克隆其代码，添加您的恶意代码，并将其构建并发布到NPM注册表中。一切看起来都不错，可能要花费数月和数百万次下载才能有人注意到有什么问题。
其中一个案例是一个包裹，该包裹在被发现之前从矿工的钱包中窃取了近三个月的比特币。当前，没有很好的方法来验证发布的内容是该项目的Github上显示的内容。
三、那么该怎么办？
有几种方法可以验证上述内容：
1.比较GitHub和您从注册表下载的版本之间的git commit散列。
2.下载源代码并自己构建，然后将其与从NPM下载的软件包进行比较。针对这两个版本运行测试和基准，并寻找结果和性能的任何变化，可能会发现代码差异，这可能表明存在潜在的恶意代码。
四、寻找新的可能的攻击媒介
这篇文章从您可以采取的一些简单步骤开始，以提高安全性。超出范围的所有内容都趋于变得更加复杂，并且在项目的日常工作中很难做到。除了知道现在可以使用哪些向量来破坏您的应用程序之外，您还必须注意将来可能发生的攻击向量（这些攻击向量仍是未知的或从未尝试针对npm注册表/软件包）。而且，可悲的是，为此，除了阅读博客，参加会议，寻找正式公告或让专门的安全专家为您做之外，您几乎无能为力。
这就是像我们这样的网络安全工具可以派上用场的地方。从理论上讲，您可以通过研究所有攻击媒介，漏洞报告站点，测试案例，代码基准以及创建运行所需的脚本和CI/CD管道以使其自动化来重新实现整个检查堆栈。但是，所有这些工作只会带您进入当前的最新状态。此外，仅要保持其运行就需要额外的维护工作。
但是，使用基于云的漏洞扫描器，您不仅可以订阅最新的漏洞检查技术。您还将委派您或您的团队必须获得并不断更新的所有专业知识和研究，以拥有用于安全验证的内部解决方案。
以上就是关于如何评估NPM软件包依赖项的安全性的全部内容介绍，想了解更多关于信息安全的信息，请继续关注。
