Trivy被黑3天后，95亿次下载的AI网关也栽了

3月19日到24日，5天，3家安全公司，1个通用AI网关被攻破。攻击者用被盗凭证在PyPI发布了两个后门版本，三小时内完成渗透。这不是演习，是TeamPCP对供应链安全行业的公开处刑。

讽刺的是，被攻击的正是那些卖"供应链安全"的公司。

「这些公司本为保护你的供应链而生，却连自己都保护不了。」TeamPCP在Telegram上写道。他们还宣布与LAPSUS$合作——那个曾黑掉英伟达、微软、三星的青少年黑客组织。

让我们按时间线复盘这场连环劫。

第一枪：Trivy沦陷

3月19日，Aqua Security的Trivy（开源漏洞扫描器，DevSecOps领域最知名的工具之一）被TeamPCP攻破。具体入侵路径未公开，但凭证泄露是后续所有动作的钥匙。

Trivy的定位是"发现别人代码里的漏洞"。它每天扫描数百万个容器镜像和代码仓库，告诉开发者哪里有风险。现在它自己成了风险源。

这就像体检中心的大夫自己被查出传染病，却继续给人做检查。

四天沉默。攻击者在观察，还是在准备下一波？

第二枪：KICS的GitHub Actions和VS Code扩展

3月23日，Checkmarx的KICS（基础设施即代码扫描工具）遭殃。攻击者用同一套被盗凭证，入侵了其GitHub Actions和VS Code扩展。

这里的关键是攻击面扩展。GitHub Actions是CI/CD流水线里的自动化脚本，VS Code扩展则直接安装在开发者本地。两者都是"高权限、高信任"的节点——开发者默认它们安全，系统给它们开了绿灯。

KICS的用户群体是基础设施工程师，他们的Terraform、CloudFormation配置文件里往往藏着云资源的访问密钥。攻击者拿到这些，等于拿到了数据中心的备用钥匙。

第三枪：LiteLLM——36%云环境的通用网关

3月24日，同一批凭证打开了LiteLLM的CI/CD管道。

LiteLLM是什么？简单说，它是AI应用的"万能转接头"。你的应用想调用OpenAI、Anthropic、AWS Bedrock、Azure OpenAI？不用写四套代码，接LiteLLM就行。它帮你路由请求、管理API密钥、统一计费、做速率限制。

数据：36%的云环境在使用LiteLLM，月均下载量9500万次。

这意味着什么？LiteLLM的管道被控制，攻击者可以往发布到PyPI的版本里塞任何东西。而他们确实这么做了——两个后门版本在三小时内被下载、安装、运行。

后门的具体行为原文未披露，但LiteLLM的架构决定了它的危险性：它持有企业所有的AI供应商API密钥，坐在应用和100多个AI服务之间。如果这里被攻破，攻击者可以窃听、篡改、重放任何AI交互，或者直接卷走密钥去刷爆你的账单。

三小时。从发布到暴露窗口关闭，足够在大量生产环境里扎根。

攻击者的嘲讽与行业的尴尬

TeamPCP的Telegram发言值得逐字读：「这些公司本为保护你的供应链而生，却连自己都保护不了。」

这不是技术炫耀，是商业模式的精准打击。Aqua Security、Checkmarx、LiteLLM的母公司BerriAI，都在向企业客户推销"供应链安全""零信任""左移安全"。现在他们的工具本身成了供应链攻击的载体。

与LAPSUS$的"合作"声明更值得玩味。LAPSUS$的风格是社交工程+内部人员招募，擅长从客服、外包员工、供应链伙伴处突破。TeamPCP展示Trivy/KICS/LiteLLM的入侵成果，等于给LAPSUS$的招募广告背书：「看，这些安全公司不难进。」

安全工具的悖论在此暴露：它们需要极高的权限来扫描和防护，因此一旦被攻破，造成的破坏比普通工具更大。

你用Trivy扫描容器镜像？它要读取你的代码。你用KICS检查Terraform？它要解析你的云配置。你用LiteLLM路由AI请求？它要保管你的API密钥。每一个都是"必要之恶"——信任是功能的前提，也是风险的源头。

原文作者UNIJOS的网络安全学生抛出了一个问题：「如果你在工作中使用安全工具——扫描器、CI/CD集成、AI库——使用前你希望了解它们的哪些安全信息？」

这个问题本身比任何答案都尖锐。因为现实中，大多数人根本不会问。

我们检查供应商的SOC 2报告，却假设写扫描器的公司自己的代码没漏洞。我们审计AI网关的加密实现，却信任它的发布管道没被篡改。我们要求"供应链安全"，却忘了安全工具也是供应链的一环。

TeamPCP的攻击链条揭示了一个被忽视的向量：安全工具之间的信任传染。Trivy的凭证泄露→KICS的Actions和扩展→LiteLLM的CI/CD。攻击者没有每次都重新入侵，而是沿着"工具信任工具"的链条滑行。

这像什么？像你用一把钥匙打开了小区门禁，发现楼里所有住户的门锁都是同一个型号。

原文结尾，作者说：「防火墙不够，工具不够，连保护我们的工具本身也需要被保护。」

但"保护保护者"是个无限递归。真正的出路可能是可验证性——不是信任扫描器没漏洞，而是假设它有，然后设计架构让单点攻破不会级联。SLSA框架、Sigstore签名、 reproducible builds（可复现构建），这些技术存在，但采用率与9500万月下载量相比，微不足道。

LiteLLM的三小时窗口期是个残酷的数据点。PyPI的恶意包检测、企业的依赖扫描、开发者的代码审查——三层防线，没拦住三小时。

攻击者比防御者更懂"工具的信任边界"在哪里。

最后一个细节：原文作者说会读每一条评论。这个姿态本身说明，连网络安全专业的学生也在寻找答案，而非拥有答案。