Trivy扫描器遭供应链攻击：76个版本标签被篡改

GitHub Actions的一个配置失误，让全球最流行的开源漏洞扫描器变成了攻击者的后门。攻击者没有新建恶意版本，而是直接修改了76个已有版本标签——这意味着那些没锁定代码哈希的企业，已经在不知情的情况下运行了数周恶意代码。

攻击时间线：一次" Incomplete "的修复如何酿成大祸

事件始于2025年2月底。攻击者利用Trivy的GitHub Actions环境配置错误，窃取了一个高权限访问令牌。3月1日，Aqua Security团队披露事件并执行了凭证轮换，但关键漏洞被遗漏——部分凭证仍然有效，攻击者并未被真正驱逐。

18天的静默期后，3月19日，攻击者发起第二阶段行动。他们向aquasecurity/trivy-action仓库的76个版本标签强制推送恶意提交，同时污染了aquasecurity/setup-trivy的全部7个标签。更隐蔽的是，一个被入侵的服务账户触发了自动化发布流程，将植入后门的Trivy二进制文件标记为0.69.4版本正式发布。

攻击者的核心策略是"寄生"而非"新建"——篡改现有标签比发布可疑的新版本更难被发现。恶意代码被设计成在合法Trivy扫描逻辑之前执行，CI/CD工作流看似正常运行，实则已在后台完成数据窃取。

窃密范围：CI/CD管道成了"凭证收割机"

恶意载荷在静默执行期间，系统性地收集CI/CD环境中的敏感信息。目标清单包括：API令牌、AWS/GCP/Azure三大云平台的凭证、SSH密钥、Kubernetes令牌以及Docker配置文件。窃取的数据被实时外传到攻击者控制的基础设施。

这次攻击精准打击了开源生态的一个普遍陋习——依赖可变版本标签（如v0.69.4）而非固定提交哈希（commit hash）。Aqua Security确认，其商业产品因架构隔离未受影响：专用管道、严格访问控制、滞后于开源发布的受控集成流程，构成了三道防线。

3月21日至22日的周末，调查发现了更多可疑活动。攻击者仍在尝试重新建立访问，表明这是一场持续进行的战役，而非一次性入侵。Aqua Security已与全球事件响应公司Sygnia合作，从初步遏制转向主动修复。

辩论：开源安全工具的信任危机，谁该背锅？

正方观点：Aqua Security的披露和响应足够及时

支持者认为，在复杂的供应链攻击中，3月1日的初步响应符合行业标准。凭证轮换是标准操作，残留访问的发现往往需要时间验证。Aqua Security在确认二次入侵后48小时内就完成了恶意版本的全面下架，覆盖GitHub Releases、Docker Hub和Amazon ECR三大分发渠道。

更关键的是，商业产品与开源项目的架构隔离被证明有效——这种"鸡蛋不放一个篮子"的设计，恰恰是负责任的安全实践。团队正在推进的不可变发布验证（immutable release verification）和长期令牌淘汰，属于结构性改进而非临时补丁。

反方观点："Incomplete remediation"暴露了流程缺陷

批评者抓住3月1日的修复失败不放。18天的窗口期让攻击者从容升级战术，从"潜伏"转向"大规模污染"。如果初次响应执行了更彻底的凭证审计，76个标签的篡改本可避免。

更深层的质疑指向开源项目的安全投入。Trivy作为被数百万CI/CD管道依赖的基础设施，其GitHub Actions环境的配置审核显然不足。攻击者利用的是基础性的配置错误，而非什么高级零日漏洞——这种"低级错误"在关键安全工具中出现，本身就值得反思。

我的判断：这是一次"典型"的供应链攻击，典型到令人不安

双方都有理，但也都回避了真正棘手的问题。正方夸大了架构隔离的普适性——大多数使用Trivy的企业没有商业版作为备份；反方则低估了供应链攻击的固有难度，残留访问的排查在大型代码库中从来不是 trivial 的事（琐碎的事）。

真正值得关注的，是攻击者选择的战术模式。他们不搞花哨的零日漏洞，而是精准利用开源生态的"默认不安全"：可变标签的便利性、CI/CD环境的凭证密集性、安全工具本身的信任溢价。这种"低成本、高杠杆"的攻击思路，正在被更多威胁行为者复制。

Aqua Security的修复清单包括全面凭证吊销、淘汰长期令牌、实施不可变发布验证。但这些措施解决的是"这次怎么被打的"，而非"下次怎么防别的"。当安全工具本身成为攻击面，整个行业需要重新思考开源基础设施的信任模型——不是要不要用，而是如何在不信任的前提下安全地使用。

截至3月25日，调查仍在进行中。攻击者仍在尝试重新进入系统，而数百万开发者的CI/CD管道日志里，可能还躺着未被发现的异常。