Trivy遭毒手：76个版本标签被篡改

3月19日，全球使用量最高的容器扫描工具Trivy被攻陷。攻击者篡改了76个版本标签，让每一次"安全检查"变成密钥收割机。你的流水线显示绿色通过，SSH密钥、云凭证、Kubernetes令牌已悄然外泄。

这不是演习。Aqua Security确认：攻击窗口约12小时，但后续余波持续三周。更麻烦的是，很多人至今不知道自己是否中招。

攻击链复盘：从一枚漏网的令牌开始

时间倒回2月下旬。一个名为"hackerbot-claw"的自动化机器人，利用Aqua Security CI环境中配置错误的GitHub Actions工作流，窃取了一枚高权限个人访问令牌（PAT）。

攻击者先用这枚令牌，在Open VSX平台向Trivy VS Code扩展推送了恶意代码。3月1日，Aqua公开披露此事并轮换凭证——但轮换不彻底。一个服务账户、一枚PAT、一条残留访问路径，仍然活着。

这就是后续灾难的伏笔。

3月19日17:43 UTC，TeamPCP组织用那枚仍有效的凭证，向trivy-action仓库的76个标签强制推送恶意提交，setup-trivy的7个标签全部沦陷。这些提交伪造了维护者身份，GitHub虽标记"此提交不属于任何分支"，但流水线日志里这行字极易被忽略。

39分钟后，18:22 UTC，恶意Trivy二进制文件v0.69.4同步发布到所有渠道：GitHub Releases、GHCR、Docker Hub、ECR Public、deb/rpm仓库、get.trivy.dev。全球任何拉取该版本的流水线，都在运行攻击者代码。

Aqua在3月20日05:40 UTC完成trivy-action标签修复。12小时窗口期，足够收割大量凭证。

为什么你发现不了

恶意代码藏在entrypoint.sh开头，约105行攻击逻辑之后才是正常的Trivy扫描程序。扫描正常完成，日志正常输出，流水线正常变绿。

攻击者甚至懒得破坏功能——毕竟，一个报错的扫描工具会被立即停用。完美的寄生，是让宿主看起来完全健康。

这有点像体检时，医生用的仪器本身被做了手脚。你的血压数据正常，但你的基因样本已被复制。

3月22日，攻击者用另一组被盗的Docker Hub凭证，绕过所有GitHub控制，继续推送v0.69.5、v0.69.6和latest标签的恶意镜像。同一天，Aqua的aquasec-com组织下44个仓库被篡改，用的是一枚能跨组织跳转的被盗服务账户令牌。

3月24日，战役扩大到Checkmarx KICS和LiteLLM的PyPI包（版本1.82.7、1.82.8）。从单一工具到供应链多点开花，三周时间，一次不彻底的凭证轮换酿成的苦果。

你的流水线可能还在用毒版本

GitHub Actions的引用方式决定了这次攻击的杀伤力。大多数人用标签引用：@v0.20.0、@v0.19.0——这正是被篡改的76个标签。只有极少数人用SHA固定提交，这次基本幸免。

问题是：很多人从不更新Action引用。一个三年前配置的@v0.10.0，如果当时拉取到了被污染的版本，可能至今仍在运行。

Aqua建议立即检查：所有引用trivy-action或setup-trivy的工作流，核对执行时间是否在3月19日17:43至3月20日05:40 UTC之间。但说实话，大多数人没有保留那么细的流水线审计日志。

更隐蔽的风险是缓存。Docker层缓存、GitHub Actions缓存、甚至企业内部的镜像仓库，都可能保存着那个v0.69.4的毒镜像。清理比想象中困难。

这次攻击暴露了一个设计层面的张力：GitHub Actions的标签机制追求易用性，SHA固定追求安全性，两者之间的选择成本由用户承担。而用户，通常选易用的那个。

TeamPCP的战术也很值得玩味。他们没有搞勒索、没有删数据、没有高调宣布——只是安静地收集凭证，让一切看起来正常运转。这种克制本身是一种信号：收集到的凭证，可能用于更后期的精准打击，而非即时变现。

3月22日的Docker Hub二次攻击更说明问题：攻击者手里有多组凭证，来自不同泄露事件，可以交叉使用、绕过单点修复。这就像打地鼠，你堵住了GitHub的洞，发现对方已经从Docker Hub钻出来了。

Aqua的响应速度不算慢——12小时修复核心标签，在供应链攻击里属于中上水平。但"不彻底修复"的教训太典型：3月1日公开披露时，如果那把漏网的钥匙被找到，整个三月的连锁事件可以避免。

安全团队现在面临一个尴尬的问题：怎么向管理层解释，那个每天跑几十次的"安全扫描"，本身就是风险源？

建议的缓解措施包括：所有GitHub Actions改用SHA引用、启用GitHub的依赖项审查、对关键工具做二次签名验证。但每条都增加摩擦，每条都会被一部分团队以各种理由推迟。

这次事件最讽刺的可能是：Trivy的定位是"发现容器镜像里的漏洞"，而它自己成了漏洞本身。工具的安全性与工具所保护对象的安全性，突然变成了同一个问题。

你的流水线最后一次运行Trivy是什么时候？用的是哪个版本？日志里有没有那句"此提交不属于任何分支"的警告？这三个问题，现在值得花十分钟确认一下。