你的AI在跑谁的代码，这是个问题

上周我写那篇AI agent自己发游戏的文章时，还在替机器能独立完成整条链路感到兴奋。今天看到CloudSEK这份报告，后背有点发凉。2500多家公司，大量CI/CD流水线，一个叫LiteLLM的开源Python包被投毒，直接捅穿了AI供应链。这不是什么边缘小厂的事故，是Meta都中招的大事件。

先说结论：AI供应链攻击比传统软件供应链攻击更隐蔽，也更致命。原因很简单，AI工具链的依赖关系复杂到你根本不知道自己在跑谁的代码。

一次教科书级的投毒

事情的经过大概是这样。有个叫TeamPCP的黑客组织，用的凭证是从Aqua Security的Trivy漏洞扫描器之前那次入侵里偷来的。他们用这些凭证发布了被投毒的LiteLLM包到PyPI。LiteLLM是什么？一个很流行的AI网关库，相当于连接应用和大模型之间的中间层。很多公司用它来统一调用OpenAI、Anthropic这些API。

一个被投毒的Python包，撬动了2500多家公司的数据。Mercor那边泄露了4TB数据，Meta直接暂停了合作。

这个链条很清晰：先黑一个安全工具厂商，拿到发布凭证，然后往开源生态里投毒，最后通过依赖关系一路蔓延到终端用户。整个过程没有攻击任何一家公司的防火墙，但数据该拿的全都拿到了。

我这边有个做安全的朋友，之前一直跟我说，供应链攻击是未来三年的头号威胁。我一直觉得他有点夸大，这年头安全事件见得多了，无非是勒索病毒、钓鱼邮件那几样。但这次不一样，它攻击的是AI基础设施本身，是所有AI应用的共同地基。

合规认证给了虚假安全感

Strikegraph那篇文章里有句话说得特别到位：暴露最严重的公司，是那些同时依赖未审计的开源AI基础设施和未验证的合规认证的公司。

这话我琢磨了很久。很多公司拿到SOC 2、ISO 27001这些证书就觉得安全了，但证书只证明你审计过自己的系统，它不保证你的供应商也经得起查。你用了LiteLLM，LiteLLM的包被投毒了，你通过了多少次合规审计都没用。Mercor是给AI公司做数据标注的，按理说应该是隐私保护最严苛的环节，结果4TB数据照样被拖走。

这让我想起之前写AI agent自主性那篇时的一个观点：自主性越强越难控制边界。现在看，这句话放在供应链上同样成立。依赖越深越难追踪，你根本数不清自己的模型推理链上有多少个第三方组件。

我们该慌吗

说实话，该慌。但慌完之后总得做点什么。

我给自己列了个检查清单，也建议各位做AI相关开发的朋友照着看看：

• 盘点一遍所有用到的开源库，特别是AI工具链里的，确认来源和作者
• 那些长期不更新的老库，能换就换，投毒者最喜欢蹲守这类目标
• CI/CD流水线的权限控制收紧，轮换凭证，别让第三方工具持有你的发布权限
• 对AI供应商做一次真正的尽职调查，不要只看证书，去看他们的代码仓库和发布流程

清单不算长，但做起来会很费劲。尤其是大公司，光理清楚自己用了哪些开源组件就是个大工程。不过这事不能省，或者说，省了这一步，后面要付的代价只会更大。

AI供应链的失守只是开始。我那个安全朋友说得对，攻击者永远在找最省力的路径，而开源生态和信任链，就是当下最省力的那条路。

---

本文编译自 Hacker News，原文：https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines
版权归原作者所有，本文为基于公开报道的编译与独立分析。