GitHub 有员工的设备因为安装了被污染的 VSCode 插件被入侵，导致 GitHub 内部仓库被泄露。攻击者声称拿到了大约 3800 个内部仓库。
但这类事情到现在才以这种规模爆出来，我已经觉得是奇迹了
一直以来，VSCode 插件、npm、crates.io、PyPI 这些开发者生态，其实都建立在一种非常脆弱的信任模型上。装一个插件或装一个包，它就能在你的电脑上执行任意代码。只要它被污染了，或者它的某个依赖被污染了，它就有机会去偷你的环境变量、GitHub token、npm token、SSH key、云厂商凭证、本地源码，甚至更敏感的东西。
大部分开发者过去也知道这里有风险，但大多数时候并不会在乎，会直接在 git clone 下来的项目上 npm install，会直接跑 README 里的命令。这是因为过去真正造成巨大公开影响的事件相对少。大多数时候，就算出事了，也会很快被发现，然后 publisher 被骂，包被下架，token 被轮换，事情就过去了。
这个生态靠一套很松散的社会信任系统支撑：大家默认 maintainer 是好人，默认依赖没有安全问题，出了事社区会发现。但如果开发者群体里有千分之一的人想捣蛋，这个机制早就该爆更多雷了。所以这个机制能用到今天已经很神奇了（确实大多数人是好人啊）。
但现在这个平衡很可能变了。
一方面，Vibe coding 和 agentic coding 的实践暴增，安全又是最容易被忽略的属性之一。产品视觉不对一眼能看出来，但是安全性有问题如果不刻意关注可能是毫无感知的。
另一方面，攻击者也可以用 agents 来做以前高成本的事情：批量找弱 maintainer，分析依赖链，生成看起来正常的 PR，伪装成普通贡献者，找 token 泄露，自动化投毒和利用。
我们需要新的更安全的软件开发的实践。
预防供应链攻击变得更重要了。减少不靠谱的外部依赖。依赖也不能无脑自动升级，因为你不知道新版本是不是刚被污染；但爆出了安全漏洞的包又要能及时升级。更现实的做法是 lockfile、Dependabot、CI 测试、安全扫描、依赖审计、provenance、最小权限 token、短期凭证、secret scanning 和自动轮换。
插件化软件不能再天真地采用 VSCode 这种模型，即使是面向开发者的。当然，VSCode 这种插件能力强，是它生产力强的重要原因；但从安全角度看，这个模型的风险也非常大。以后更合理的方向应该是默认沙盒隔离，显式 capability 授权，最小权限。中心化插件 Store 会更让人放心（例如 Raycast 的），至少可以做审核、签名、回滚、下架。但它不能保证天然安全。真正关键的还是 runtime sandbox 和权限边界。而类似 Obsidian 这种插件生态，就有很大的风险。能力上没约束，插件可以跑任意脚本，另一方面版本升级之类的不会触发审核。
Secure by default 的架构也会变得更有收益。比如端到端加密。它不能阻止本机恶意插件在明文阶段偷数据；但它能显著降低服务端、数据库、日志、仓库、备份泄露之后的影响面。对开发者来说晚上能睡好也很重要。Passkey、FIDO 这些东西的普及，也让端到端加密应用的体验变得更有可能做好。过去端到端加密软件最大的问题是密钥管理太反人类，现在有机会把它做得更自然好用。也许未来，所有涉及敏感数据的 Vibe coding 应用都该走端到端加密。
但这类事情到现在才以这种规模爆出来，我已经觉得是奇迹了
一直以来，VSCode 插件、npm、crates.io、PyPI 这些开发者生态，其实都建立在一种非常脆弱的信任模型上。装一个插件或装一个包，它就能在你的电脑上执行任意代码。只要它被污染了，或者它的某个依赖被污染了，它就有机会去偷你的环境变量、GitHub token、npm token、SSH key、云厂商凭证、本地源码，甚至更敏感的东西。
大部分开发者过去也知道这里有风险，但大多数时候并不会在乎，会直接在 git clone 下来的项目上 npm install，会直接跑 README 里的命令。这是因为过去真正造成巨大公开影响的事件相对少。大多数时候，就算出事了，也会很快被发现，然后 publisher 被骂，包被下架，token 被轮换，事情就过去了。
这个生态靠一套很松散的社会信任系统支撑：大家默认 maintainer 是好人，默认依赖没有安全问题，出了事社区会发现。但如果开发者群体里有千分之一的人想捣蛋，这个机制早就该爆更多雷了。所以这个机制能用到今天已经很神奇了（确实大多数人是好人啊）。
但现在这个平衡很可能变了。
一方面，Vibe coding 和 agentic coding 的实践暴增，安全又是最容易被忽略的属性之一。产品视觉不对一眼能看出来，但是安全性有问题如果不刻意关注可能是毫无感知的。
另一方面，攻击者也可以用 agents 来做以前高成本的事情：批量找弱 maintainer，分析依赖链，生成看起来正常的 PR，伪装成普通贡献者，找 token 泄露，自动化投毒和利用。
我们需要新的更安全的软件开发的实践。
预防供应链攻击变得更重要了。减少不靠谱的外部依赖。依赖也不能无脑自动升级，因为你不知道新版本是不是刚被污染；但爆出了安全漏洞的包又要能及时升级。更现实的做法是 lockfile、Dependabot、CI 测试、安全扫描、依赖审计、provenance、最小权限 token、短期凭证、secret scanning 和自动轮换。
插件化软件不能再天真地采用 VSCode 这种模型，即使是面向开发者的。当然，VSCode 这种插件能力强，是它生产力强的重要原因；但从安全角度看，这个模型的风险也非常大。以后更合理的方向应该是默认沙盒隔离，显式 capability 授权，最小权限。中心化插件 Store 会更让人放心（例如 Raycast 的），至少可以做审核、签名、回滚、下架。但它不能保证天然安全。真正关键的还是 runtime sandbox 和权限边界。而类似 Obsidian 这种插件生态，就有很大的风险。能力上没约束，插件可以跑任意脚本，另一方面版本升级之类的不会触发审核。
Secure by default 的架构也会变得更有收益。比如端到端加密。它不能阻止本机恶意插件在明文阶段偷数据；但它能显著降低服务端、数据库、日志、仓库、备份泄露之后的影响面。对开发者来说晚上能睡好也很重要。Passkey、FIDO 这些东西的普及，也让端到端加密应用的体验变得更有可能做好。过去端到端加密软件最大的问题是密钥管理太反人类，现在有机会把它做得更自然好用。也许未来，所有涉及敏感数据的 Vibe coding 应用都该走端到端加密。
