4 分•作者: SchizoDuckie•大约 2 个月前
今天我意识到一个重要的问题，我们都被骗了。<p>如果我们将特定语言的 vendor/node_modules/venv 目录签入 Git，并直接从中部署，那么目前发生的所有供应链攻击根本就不会发生。<p>去他的依赖项安装和升级步骤。去他的自动化构建步骤。去他的破坏性变更，因为 $package_owner 不遵守语义版本控制。<p>单独签入依赖项及其更新，一直是，也永远是摆脱这种困境的出路。<p>今天就从你的 .gitignore 中删除 vendor/ node_modules/ 和 venv/，并在你的 CI 中跳过安装步骤，你就能立即消除 99% 的攻击面。一直以来都这么简单吗？？？ 我认为是这样的！<p>你认为签入你的 composer.lock 或 package.lock 就能解决问题？哈。 npm install 是“智能”的，它会检查更新并默默地安装新版本并更新你的 lockfile。你应该使用 npm ci。我们积极地训练开发人员运行 'composer update' 来检查新版本，这些新版本修复了他们在本地可能遇到的“问题”，并删除 lockfile 作为解决问题的首要措施。<p>你检查了 composer.lock 的每次更新吗？那个看似无辜的提交哈希值可能只是引入了 20kb 的混淆的恶意代码，而你永远不会知道。<p>所有这些都因为一个长期存在的、可笑的 github 漏洞而变得更加复杂，你可以 fork 一个存储库并将你的提交推送到它，然后提取提交哈希值并将其附加到原始存储库 URL。在 Github Web 界面上，你会看到一个通知“此提交可能不属于此存储库或其 fork”，但在终端上你永远不会看到它，而这正是当前蠕虫利用的漏洞。<p>签入你的依赖项并消除安装步骤将使所有这些都可追踪和可追溯。在我看来，性能损失是值得的。