「我们以为在扫描漏洞，其实漏洞在扫描我们。」一位安全工程师在复盘Trivy供应链攻击时写道。这句话成了过去两周DevOps圈子的黑色幽默。
Aqua Security的开源漏洞扫描器Trivy，全球下载量超1.5亿次，被集成进无数CI/CD流水线。2月底，它成了攻击者的跳板——不是被攻破后停用，而是被篡改成间谍工具，继续"正常工作"了三周。
攻击路径：一次未完成的清理
2月下旬，攻击者利用Trivy的GitHub Actions环境配置失误，窃取了一个高权限访问令牌。3月1日，Aqua团队公开披露并轮换凭证，但清理不彻底——部分令牌仍在有效期，攻击者留着后门。
18天后，攻击升级。3月19日，攻击者强行推送恶意提交到76个版本标签（共77个），覆盖aquasecurity/trivy-action仓库；同时篡改aquasecurity/setup-trivy的全部7个标签。同日，一个被入侵的服务账户触发自动发布流程，推送带后门的Trivy 0.69.4版本。
攻击者没有发布明显可疑的新版本，而是修改已有标签，让正在使用这些标签的企业毫无察觉地执行恶意代码。
恶意载荷设计精巧：它在合法Trivy扫描逻辑之前运行，被感染的流水线看起来完全正常。静默执行期间，程序收集CI/CD环境中的敏感信息——API令牌、AWS/GCP/Azure云凭证、SSH密钥、Kubernetes令牌、Docker配置文件，全部外传到攻击者控制的服务器。
争议焦点：谁该为这次暴露负责
事件发酵后，社区出现两种对立声音。
正方观点：开源维护者的责任边界
部分安全从业者认为，Aqua作为商业公司运营开源项目，却未将开源与商业环境彻底隔离，是架构层面的失职。「GitHub Actions的令牌管理是基础功课，」云安全顾问Kevin Beaumont指出，「3月1日的'部分轮换'说明团队缺乏事件响应的完整清单。」
更尖锐的批评指向版本标签的可变性。攻击者能批量篡改76个标签，说明项目未启用GitHub的签名提交强制验证，也未对发布流程实施双人复核。这些措施在关键开源项目中已成标配，Trivy的缺失被视作"便利优先于安全"的惯性。
反方观点：用户的配置债务
另一派将矛头指向使用方式。Aqua在公告中明确区分：使用固定提交哈希（commit hash）的用户未受影响，只有依赖可变版本标签（如@0.69.4）的用户暴露于风险。
「供应链安全的最佳实践写了多年，」DevOps工程师Maya Kaczorowski在社交媒体回应，「pin住依赖版本是CI/CD 101，不是高级技巧。」她引用OpenSSF（开源安全基金会）2024年报告：仅12%的企业对关键构建依赖实施哈希锁定。
这一派认为，开源项目提供"按原样"的软件，用户选择便利的浮动标签，就要承担相应风险。将商业级安全期望强加于免费工具，是责任错配。
我的判断：双方都低估了"正常幻觉"的杀伤力
这场辩论漏掉了一个关键事实：攻击的设计本身就是为了让所有人——包括谨慎的用户——难以察觉。
即使严格执行哈希锁定，如果该哈希指向的标签被重新标记到恶意提交，用户仍会中招。GitHub的标签是可变引用，哈希锁定防的是"意外更新"，不是"恶意重定向"。攻击者正是利用这一机制，让已有工作流在"未变更配置"的情况下执行新代码。
换句话说，传统供应链安全的假设——"固定版本=可复现构建"——在这次攻击中部分失效。
Aqua的商业产品确实未受影响，其架构隔离（专用流水线、严格访问控制、延迟集成）被证明有效。但讽刺的是，这些措施本可用于保护开源版本，却仅服务于付费客户。这不是技术能力问题，是资源分配的选择。
余波：攻击仍在继续
3月21日至22日的周末，调查团队发现攻击者试图重新建立访问，表明这是一场持续战役，而非一次性入侵。Aqua已与全球应急响应公司Sygnia合作，撤下GitHub Releases、Docker Hub、Amazon ECR上的全部恶意版本，完成全环境凭证轮换，并转向短期令牌机制。
更深层的影响正在显现。多家企业在复盘时发现，被窃凭证已被用于横向移动——攻击者不仅偷钥匙，还在用钥匙开门。具体损失范围尚不明朗，Aqua和Sygnia未披露受影响组织数量。
一位参与调查的安全研究员私下表示：「最麻烦的不是这次丢了什么，是我们不知道攻击者还留着什么。」Trivy 0.69.4的下载统计已被GitHub隐藏，但据镜像站缓存数据，该版本在公开期间被拉取超过4万次。
如果你或你的团队在过去三周使用过Trivy的GitHub Action或setup-trivy，立即检查流水线日志中是否存在指向185.234.72.0/24网段的外连记录——这是目前已知的攻击者基础设施网段。同时轮换全部CI/CD环境凭证，无论你是否"确定"使用过受影响版本。
热门跟贴