AI 助手推荐的依赖被投了毒

9月16日，The Hacker News 披露了 Mandiant 在9月报告里的一个案例。一家 SaaS 厂商，开发者正在使用的 AI 编程助手会话被攻击者接管了。接下来发生的事很简单：助手推荐了一个已经被攻击者投毒的软件包，这位开发者接受了这个推荐。

装上之后，攻击者借着这个仍然活着的开发者会话，通过一个被投毒的 PyPI 包植入了信息窃取木马，顺手拿走了 GitHub OAuth 令牌。随后他把 Shai-Hulud 蠕虫放进了这家公司内部大约一百个代码仓库。蠕虫会自己跑，一遍扫过去，仓库里的密钥和公司产品的源代码都被带走了。事情还没完——公司官方命名空间里的包也被投了毒，另一名员工拉取了同一个被污染的版本，在公司内部造成了二次感染。

Mandiant 公开的部分到这里就结束了。没有点名受害者，没有说用的是哪款助手，没有说那个活跃会话是怎么被接管的，也没有给时间点。所以这不能当成一份可以照着复现的入侵复盘，它更像一个被完整记录下来的失败模式：一个被信任的助手给出了一个依赖建议，一个人点了接受，剩下的全自动发生。

值得多想一层的是，这件事里模型本身大概率并没有被攻破。Mandiant 没有说攻击者是怎么拿到那个活跃会话的，公开材料里也看不到任何"模型被越狱"的迹象。攻击者根本不需要让模型叛变，他只要坐在推荐链的上游——把包投毒，然后等助手把毒端上来。 这比攻破模型便宜太多，也稳定太多。

真正让人不放心的是防御站的位置。过去我们讨论"AI 助手会带进来什么"，盯的一直是模型输出：会不会写出有漏洞的代码，会不会推荐一个根本不存在的包。这次是另一回事：包是真实存在的，就挂在这家公司自己的命名空间里。而现有的供应链检测基本都架在"从公共仓库往里拉东西"这条路径上，依赖扫描、SBOM、镜像检查全是这个逻辑。"助手说这个包没问题"这句话，不在任何一条规则的覆盖范围里。

Shai-Hulud 这个名字并不新，这一年它一直在升级。8月初那条跟 keyv 相关的 npm 蠕虫投毒了几百个包，还在 Claude Code 和 VS Code 里种了钩子；9月初 GitGuardian 发现这个家族的窃密变种把扫描目标扩大了一大截：

目标非常明确，就是找那些还能用的凭据。攻击者不需要去攻破信任关系，他只要找到信任关系已经在用的那些钥匙——一个包发布令牌能发版，一个 GitHub token 能写更多仓库，一个 CI 凭据能碰到云。这也解释了为什么一个开发者"点了一次接受"，最后会变成一百个仓库失守。

Mandiant 针对 AI 辅助开发环境给了三条控制措施，都不复杂：助手推荐的第三方依赖，落地前要拿校验和与已批准的白名单对一遍；原始 API key、长期 OAuth 令牌这类东西，别放在扩展伸手就能拿到的地方；依赖流量走公司自己的受控仓库，不要直连公共源。翻译成日常动作更直白一些：关掉助手建议的一键安装，让"采纳一条建议"变成一次要走流程的变更；盘一遍公司里到底有哪些助手、插件和工具桥握着仓库与网络权限；能用短期 OIDC 令牌的地方，就别再留长期发布令牌。

如果已经怀疑中招，第一件要做的事不是删包，而是假定被波及仓库里的源码已经在对手手里——先轮换，再清理。轮换范围按"当时和那个会话属于同一身份"去圈：仓库密钥、CI 凭据、云访问密钥、包仓库令牌，一样都别漏。

说到底，这件事带来的变化不是"AI 不安全"，而是信任的入口又多了一个，而且它坐在流程最前面。以前我们说"别照着 Stack Overflow 的答案直接复制粘贴"，现在这句话得改成"别直接把 AI 助手递过来的依赖装上去"。区别在于，Stack Overflow 的答案你自己会扫一眼，而助手的建议是主动递到你手边的，还带着工具的背书。下一个 Shai-Hulud 一定会去找新的 469 个位置，甚至更多。我们能决定的不是它找不到，而是等它找到的时候，那些位置上的密钥还能不能开门。

信息来源：The Hacker News

本公众号发布的文章均转载自互联网或经作者投稿授权的原创，文末已注明出处，其内容和图片版权归原网站或作者本人所有，并不代表安世加的观点，若有无意侵权或转载不当之处请联系我们处理！

安世加为出海企业提供SOC 2、ISO 体系、PCI DSS认证咨询服务（点击图片可详细查看）