你的代码中隐藏着什么？

即使是简单的项目也会快速膨胀，并且通过轻松合并现有代码或节点库，这种趋势会被放大。

当您是唯一编写该代码的人时，这在某种程度上仍然是可以管理的，但是当代码由许多开发人员和团队编写时，它会变得更加困难，就像通常的情况一样。

即使是团队领导，负责批准所有拉取请求的人，也无法了解每一行代码、每个函数和每个变量。

信任问题

这就是 2020 年底 Orion 应用程序发生细微代码更改的原因之一，该案例后来被称为 太阳风， 这么长时间都没有被发现。整个改动只有几十行代码，而且非常好 隐藏在原来的类中.

更改后的产品已正确签名，因此没有理由怀疑它，并且开发团队信任代码的所有者。

直到最近我们才了解到 NPM 有一个“逻辑缺陷”这使得恶意行为者能够将流氓库冒充为合法库。基本上，NPM 允许将任何人添加为软件包的维护者，而无需通知这些用户或征得他们的同意。 

这使得创建带有恶意软件的软件包并在他们不知情的情况下将它们分配给受信任的、受欢迎的维护者。信任错置的情况可能意味着您的代码中隐藏着有问题的漏洞。

需要考虑的另一个常见做法是开发人员从现有库或 StackOverFlow 复制并粘贴代码，以便在自己的代码中使用或重新上传到新库。这样做会增加复制现在基本上未跟踪的不安全和易受攻击的代码的机会。即使原始代码将获得 CVE 并最终得到修复，您复制的有问题的函数也是不可见的，并且可能会污染未来几年使用它的任何代码库。 

堪萨斯大学最近进行的一项研究（“什么叉子？在 npm 中查找隐藏的代码克隆”），研究人员说明了即使使用经过全面审查的软件包也可能是不安全的。

你能为这个做什么？

因此，您不能信任供应商的签名产品和更新。由于所有这些外部库和代码都合并到其中，您自己的代码可能已经被修改或添加。那么，您可以做什么来真正确定您没有将恶意文件安装到您的系统中呢？

您可以做以下几件事：

1. 向您合并的每个库所有者或程序供应商索取完整的 SBOM。 SBOM 可以帮助您确定库或产品中的所有“成分”是什么。此外，如果您在库或产品中发现 SBOM 中未列出的内容，则应将其视为可疑。您可以详细了解什么是 SBOM 点击这里.
2. 请求供应商或库所有者提供可信证明，证明已进行完整性检查并且您得到了预期的结果。您不必只相信供应商自己的保证。
   
3. 安装软件包时使用 npm CLI 标志 --ignore-scripts 以避免在安装阶段执行来自 3rd 方软件包的脚本。
4. 使用 包lock.json 文件来锁定包版本号。当您使用 包lock.json 您不仅锁定了正在使用的软件包版本，还锁定了它们的依赖项。风险在于您不会引入任何可能包含各种错误修复的自动软件包更新。但是，如果您已投入工作来验证某个版本，并且不想在未先验证的情况下包含任何其他内容，那么锁定版本号是最好的选择。

跟随 新的规定，大多数人预计会在不久的将来开始使用 SBOM。越多的公司要求提供 SBOM 和其他证明，就越多的组织和维护人员必须遵守。