聊AI安全的时候，大多数人脑子里想的是什么？
是模型会不会骗人，会不会被越狱，会不会有一天不听指令自己搞事情。对齐、护栏、红队测试，这些词占据了AI安全话语的绝大部分版面。
但2026年8月11日曝光的这起事件告诉你，AI安全最先塌方的地方，不是模型本身，而是那些你根本没注意过的管道。
一个叫LiteLLM的开源Python包，被投毒了。
如果你做AI开发，大概率用过它或者你用的工具依赖过它。LiteLLM是一个统一接口层，让你用同一套代码调用OpenAI、Anthropic、Google、Mistral等各家模型的API。它的作用类似于水管接头，不起眼，但哪个水龙头都离不开它。
今年三月，一个叫TeamPCP的攻击组织找到了这根管道的裂缝。
故事是这样的。LiteLLM的构建流程中使用了一个安全扫描工具叫Trivy，用来检查代码有没有漏洞。攻击者先搞定了Trivy的发布流程，往里面注入了恶意代码。然后，因为LiteLLM的构建管线安装Trivy时没有锁定版本号（这个在安全圈叫「未钉定依赖」，是最基础的供应链卫生问题），被污染的Trivy就这样顺理成章地进入了LiteLLM的构建环境。
接下来发生的事情非常精密。恶意代码利用Trivy在LiteLLM构建环境中的特权，生成了两个被投毒的PyPI包版本，1.82.7和1.82.8。这两个版本在PyPI上只存在了大约40分钟就被发现和撤下了。
40分钟。
但就这40分钟，根据CloudSEK的威胁情报分析，超过2500家组织和434,000条CI/CD流水线可能暴露在了攻击范围内。
被点名的组织列表读起来像财富500强目录，微软、亚马逊、英伟达、思科、三星。
这里需要说清楚一个关键细节。「暴露」不等于「被攻破」。CloudSEK的报告非常谨慎地表示，这是「高置信度暴露匹配」，而不是确认数据已被窃取或攻击者已利用。但暴露本身就够让人冒冷汗了。
因为这个恶意载荷的设计极其阴险。
它不是在你import LiteLLM的时候才激活，而是在Python启动时就运行。它通过一个.pth文件实现这一点。.pth是Python的一个鲜为人知的机制，放在特定目录下的.pth文件会在Python解释器启动时自动执行。也就是说，只要你的CI/CD环境里安装了那两个被投毒的版本，不管你的代码有没有真正调用LiteLLM，恶意代码都已经在跑了。
它跑起来之后干什么？搜刮一切能找到的凭证。
SSH密钥、云服务凭证（AWS、GCP、Azure）、Kubernetes密钥、代码仓库token、环境变量文件、甚至是进程内存里的secrets。对了，还有LLM的API密钥和网关配置，因为用LiteLLM的环境大概率连着各家模型的付费接口，这些密钥本身就值钱。
收集完之后，数据被加密发送到一个打了错别字的域名。如果发送失败，恶意代码会在受害者自己的GitHub账号里创建一个公开仓库，把偷到的东西作为release资产上传。
这招太损了。因为泄露的数据看起来是从你自己的GitHub账号里发出来的，安全团队排查时很容易漏掉。
还有一个细节让这件事更加棘手。CloudSEK指出，被窃取的凭证在恶意包被撤下之后很长时间内可能仍然有效。你把中毒的包删了，把环境重建了，但如果那些被偷走的SSH密钥、那些云服务的access key没有被轮换，攻击者随时可以用它们回来。
这就像是小偷在你家停留了40分钟，配好了所有房间的钥匙就走了。你事后发现被闯入了，换了门锁，但你不知道他已经配好了阳台门、车库门和保险柜的钥匙。除非你把每一把锁都换掉，否则你永远不知道他什么时候会再来。
而且这次攻击的传播机制决定了，很多组织可能根本不知道自己曾经暴露过。CI/CD流水线是自动化运行的，如果在那40分钟窗口内恰好有一次构建跑起来，恶意代码就会被执行，凭证就会被窃取，整个过程没有任何人类肉眼可见的异常。日志里不会有明显的报错，构建结果看起来完全正常。
我想说明白为什么这件事比它听起来更严重。
大多数人理解的安全事件是「黑客攻入了某公司的服务器」。那是正面进攻。供应链攻击不是这样的，它更像是在自来水厂的管道里投毒，你不需要攻破每一户人家的门锁，只要搞定水源头，千家万户打开水龙头就中招了。
AI领域的供应链依赖问题比传统软件还要严重。 原因有三个。
第一，AI开发的工具链特别长。从数据处理到模型训练到推理部署，每个环节都依赖大量的开源组件。LiteLLM只是其中一个，还有LangChain、LlamaIndex、vLLM、Transformers……每一个都是潜在的攻击入口。
第二，AI开发环境的权限特别高。为了调用模型API、读取训练数据、部署服务，这些环境通常持有大量的云服务凭证和敏感数据访问权限。一旦被攻破，能偷到的东西比普通开发环境多得多。
第三，AI开发者对供应链安全的意识普遍薄弱。说句不客气的话，很多AI团队的安全实践停留在「能跑就行」的阶段。pip install不锁版本、CI/CD不验证依赖哈希、secrets直接写在环境变量里，这些在传统安全团队看来是低级错误的操作，在AI团队里是常态。
我观察到一个很有意思的现象。AI领域最聪明的一批人，在构建世界上最先进的模型系统时，使用的软件工程实践却经常停留在十年前的水平。不是因为他们不懂，而是因为AI开发的迭代速度太快了，没人愿意「浪费时间」在依赖锁定、密钥轮换这些「不直接产生模型提升」的工作上。
但这次事件证明了一件事。你可以有世界上最强的模型，但如果你的构建管线里有一个未钉定的依赖，一切都可以在40分钟内归零。
LiteLLM的构建流程没有锁定Trivy的版本号，这是导致整个事件的根本原因。一个安全扫描工具（注意，它本身就是用来保障安全的），因为没有被安全地集成，反而成了攻击入口。讽刺到了极点。
CloudSEK在报告中给出了明确的行动建议。第一步，识别你的环境中是否安装了受影响的版本。紧接着，轮换所有可能暴露的凭证，不只是LiteLLM相关的，而是受影响进程能接触到的所有凭证。第三，从已知干净的源重建受影响环境。第四，审计云服务、代码仓库、包注册表和Kubernetes的日志，查找异常的token使用。
最重要的一条是，不要等到确认被攻破了再行动。计划性的凭证轮换造成的中断，几乎总是比攻击者保持访问权限造成的损害要小。
这起事件最让我在意的不是它的规模（虽然2500家组织确实吓人），而是它暴露的一个行业盲区。
我们花了大量精力讨论AI模型的安全性。对齐研究、宪法AI、红队测试、安全评估，这些当然重要。但如果支撑整个AI生态运转的基础设施，那些构建工具、包管理器、CI/CD流水线，本身就是千疮百孔的，那再安全的模型也白搭。
打个比方，你可以给家里装最贵的防盗门、最先进的监控系统，但如果整栋楼的下水管道年久失修，随时可能爆裂淹没地下室，那些防盗措施就显得有点滑稽了。
AI的安全叙事需要一次重心转移。从「模型会不会失控」到「模型赖以运行的一切会不会先崩塌」。
对于正在读这篇文章的AI开发者，有几件事你今天就可以做。
把你项目的所有依赖锁定到具体版本号和哈希值。是的，这会让升级变麻烦，但比凭证泄露要好得多。检查你的CI/CD流程中有没有类似的「未钉定」工具。缩短凭证的有效期限，能用临时凭证的地方不要用永久密钥。给你的构建环境做一次资产盘点，搞清楚它到底能接触到哪些secrets。
这些都不是什么高深的安全工程。它们是基础卫生。但基础卫生恰恰是大多数AI团队最欠缺的东西。
我自己的感受是，这起事件给整个AI安全讨论补上了一块拼图。我们终于开始意识到，AI系统的安全性不能只看模型那一层，它是整个栈的函数，从硬件到操作系统到包管理器到构建流程到模型权重到推理服务到API网关，任何一层被突破都是全盘皆输。
下次有人跟你聊AI安全，聊超级对齐，聊AGI风险的时候，你可以提醒他们，也许在那些终极问题到来之前，一个没人关注的Python包在PyPI上存在40分钟就够让半个行业手忙脚乱了。
谢谢你看我的文章，我们，下次再见。
/ 作者：青玉白露
评论区
欢迎留下你的看法，支持匿名评论。
你的评论会公开展示，建议填写便于交流的昵称，并尽量提供有信息量的反馈。