HackerNews中文版

我今天意识到一个重大事实：我们都被愚弄了。目前发生的所有供应链攻击，如果我们只是将各自语言的 vendor/node_modules/venv 目录提交到 git，并直接从中部署，这些攻击根本就不会发生。放弃依赖安装和升级步骤吧。放弃自动构建步骤。放弃因为 $package_owner 不遵循语义版本控制而导致的破坏性更改。逐个提交依赖及其更新，一直以来都是摆脱这个混乱局面的办法。今天就把 vendor/node_modules/venv 从你的 .gitignore 中移除，跳过 CI 中的安装步骤，你就能立即消除 99% 的攻击面。难道这一直都这么简单吗？我觉得是的！你认为提交你的 composer.lock 或 package.lock 能拯救你吗？哈哈。npm install 是“智能”的，会检查更新并悄悄安装新版本，更新你的锁定文件。你应该使用 npm ci。我们还在积极训练开发者运行 'composer update' 来检查可能在本地遇到的“问题”的新版本，并将锁定文件作为修复问题的第一步删除。你会审核每一个对 composer.lock 的更新吗？那一个看似无辜的提交哈希一旦改变，可能就会引入 20kb 的混淆漏洞代码，而你却对此一无所知。所有这一切都被长期存在的搞笑 GitHub bug 加剧了：你可以分叉一个仓库并将你的提交推送到它，然后提取提交哈希并将其附加到原始仓库的 URL。在 GitHub 的网页界面上，你会看到一条通知：“这个提交可能不属于这个仓库或它的分叉”，但在终端上你永远看不到这一点，而这正是当前蠕虫所利用的。提交你的依赖并消除安装步骤将使所有这些变得可追踪和可追溯。在我看来，这样带来的性能损失是值得的。

查看原文

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 文件中移除。