HackerNews中文版

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

查看原文

I head the major realisation today that we've all been bamboozled.All the supply chain attacks currently happening would never even happen if we just checked in our language-respective vendor/node_modules/venv directories into git and just deployed straight from that.Screw the dependency install and upgrade step. Screw the automated build step. Screw the breaking changes because $package_owner doesnt adhere to semver.Checking in dependencies and their updates individually is, and has always been the way out of this mess.Remove vendor/ node_modules/ and venv/ from your .gitignore today and skip the install step in your CI and you eliminate 99% of the attack surface instantly. Was it always that easy???? I think it was!You think checking in your composer.lock or package.lock saves you? Hah. Npm install is "smart" and checks for updates and silently installs new versions and updates your lockfile. You should have used npm ci instead. We actively train devs to run 'composer update' to check for new releases that fix 'issues' they might encounter locally and delete the lockfiles as a first measure to fix issues.Do you vet every update to your composer.lock? That one innocent commit hash that's changed could just pull in 20kb of obfuscated exploit code and you'd never know.All of this is compounded by the longstanding hilarious github bug where you can fork a repository and push your commit to it, then pluck the commit hash and append that to the original repository URL. On the Github webinterface you'll see a notice "this commit has might not belong to this repo or a fork of it" but on the terminal you'll never see that, and that's exactly what the current worms exploit.Checking in your dependencies and eliminating the install step would make all of this trackable and traceable. Imo the performance hit is worth it.

解决供应链问题的方案是，别再把你的依赖项从 .gitignore 里移除了。