当安全工具本身成为攻击载体:Trivy 供应链攻击事件深度解析

你用来发现漏洞的工具，正在悄悄偷走你的密钥。

引言：安全悖论

2026年3月19日，一个普通的周三下午。全球数千个 CI/CD 流水线照常运行，安全扫描工具 Trivy 默默守护着代码仓库。

但没有人意识到，守护者已经变成了入侵者。

在短短12小时内，攻击者通过被污染的 Trivy 生态系统，窃取了无数企业的云凭证、数据库密码、SSH 密钥，甚至加密货币钱包私钥。

这不是科幻小说，这是真实发生的供应链攻击事件。

事件回顾：一条精心设计的攻击链

第一幕：潜伏

故事要从2026年2月底说起。攻击者通过某种方式获取了 Trivy 项目的访问凭证。3月1日事件首次披露后，项目团队进行了凭证轮换。

但问题在于：凭证轮换不是原子操作。

在轮换窗口期内，攻击者利用仍有权限的旧凭证，窃取了新凭证。这就像你发现家里进了贼，换了一把锁，但忘记收回备用钥匙——贼手里已经有了新锁的钥匙。

第二幕：布局

3月19日，攻击者发动了组合拳：

1. 发布恶意版本 v0.69.4

攻击者推送了一个看似正常的 commit，但其中暗藏玄机：

• 将 actions/checkout 引用替换为恶意 commit

• 从仿冒域名下载恶意代码

• 跳过二进制验证流程

2. 劫持历史标签

强制推送了 76 个版本的 trivy-action 标签，注入信息窃取器。这意味着即使你使用的是两年前的版本标签，也会被攻击。

3. 污染安装工具

所有 7 个 setup-trivy 标签都被替换为恶意版本。

第三幕：收割

恶意代码极其专业，攻击目标覆盖：

• 云平台凭证：AWS、GCP、Azure、Kubernetes

• 数据库密码：MySQL、PostgreSQL、Redis、MongoDB

• SSH 密钥：私钥、授权密钥、已知主机

• Docker 配置：容器镜像仓库凭证

• 加密货币钱包：Bitcoin、Ethereum、Solana 等

• CI/CD 配置：GitLab CI、Jenkins、Terraform 状态

• Shell 历史记录：可能包含敏感命令和凭证

更可怕的是它的备用泄露机制：如果直接外传失败，它会用你的 GitHub PAT 在你的账号下创建一个公开仓库 tpcp-docs，把偷来的数据作为公开 release 发布。

你的密钥，就这样变成了公开资产。

深度思考：开源软件的安全困境

困境一：信任链条的脆弱性

现代软件是一个层层叠加的信任链条：

每一层都可能成为攻击入口。Trivy 事件中，攻击者选择的切入点是 GitHub Actions——一个被广泛信任的自动化工具。

你信任了 Trivy，Trivy 信任了 GitHub Actions，而 Actions 的标签是可以被劫持的。

困境二：版本标签的”可变性陷阱”

这是 Git 设计中的一个经典安全陷阱：

• 标签 理论上应该是不可变的

• 但实际上，git tag -f 可以强制覆盖标签

• GitHub 的 immutable releases 功能需要主动开启

在这次事件中，攻击者正是利用了这一点：两年前的版本标签 0.0.1 被强制推送到恶意 commit，用户以为自己在用”稳定老版本”，实际在执行恶意代码。

困境三：凭证管理的”窗口期风险”

凭证轮换是安全标准操作，但如何轮换往往被忽视：

串行轮换 ❌ 危险

存在窗口期，攻击者可窃取新凭证

原子轮换 ✅ 安全

同时撤销所有旧凭证，立即启用新凭证

Trivy 事件就是”串行轮换”的典型案例。在几天的窗口期内，攻击者完成了凭证转移。

困境四：开源项目的”信任赤字”

开源软件面临一个根本性矛盾：

• 开放性：源代码公开，理论上”更多人审计 = 更安全”

• 实际性：大部分用户不会审计代码，只是盲目信任

Trivy 拥有 24,000+ GitHub Stars，是云原生安全领域的主流工具。但 stars 数量不等于安全审计质量。

当安全工具被攻破时，受害者往往是那些最注重安全的企业。

防御策略：从事件中学到的教训

策略一：固定到不可变引用

❌ 危险：可变标签

✅ 安全：不可变 SHA

关键原则：版本标签是名字，commit SHA 才是身份。

策略二：验证发布物完整性

使用 sigstore 签名验证：

关键原则：不仅验证”这是正确的文件”，还要验证”这是在安全时间点发布的文件”。

策略三：启用不可变发布

GitHub 的 immutable releases 功能一旦启用，就无法删除或覆盖已发布的 release。

应该在项目早期就启用此功能，而不是在事件发生后。

策略四：最小权限原则

CI/CD 环境中的凭证应该：

• 只拥有完成任务所需的最小权限

• 设置较短的有效期

• 定期轮换（且要原子轮换）

• 隔离不同环境的凭证

策略五：监控异常行为

建立检测机制：

• 监控是否存在意外的公开仓库创建

• 检查 CI/CD 日志中的异常网络请求

• 追踪敏感文件的访问记录

更深层的思考

开源安全的未来

这次事件暴露了一个残酷的现实：开源供应链攻击正在成为主流攻击手段。

原因很简单：

• 一次攻击，影响面极大（Trivy 被数万企业使用）

• 攻击隐蔽性强（嵌入信任链条）

• 持续时间长（历史版本标签也会被污染）

我们需要什么样的安全？

传统的安全思维是”检查清单式”：

✅ 使用安全扫描工具

✅ 定期更新依赖

✅ 启用双因素认证

但供应链攻击告诉我们：安全工具本身也可能是攻击载体。

我们需要建立的是”零信任”思维：

• 不因为”这是安全工具”就信任它

• 不因为”这是老版本”就认为安全

• 不因为”有签名”就完全信任（签名时间也很重要）

写在最后

Trivy 事件不是孤例，也不会是最后一例。

从 SolarWinds 到 Log4j，从 event-stream 到这次 Trivy，供应链攻击已经成为国家级攻击者和高级威胁组织的首选武器。

对于开源生态：

• 项目维护者需要更严格的发布流程

• 平台需要提供更好的安全机制

• 用户需要更谨慎的信任策略

在软件供应链时代，每一次 npm install、pip install、docker pull，都是一次信任决策。

谨慎一点，不会错。

附录：事件关键时间线

2026年2月底 – 初始攻击开始

2026年3月1日 – 首次披露，凭证轮换

2026年3月3-4日 – 启用 immutable releases

2026年3月19日 17:43 UTC – 攻击者开始活动

2026年3月19日 18:22 UTC – 恶意 v0.69.4 发布

2026年3月19日 21:42 UTC – v0.69.4 移除（暴露约 3 小时）

2026年3月20日 05:40 UTC – trivy-action 清理（暴露约 12 小时）

参考来源：

• https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6×23

• https://github.com/aquasecurity/trivy/discussions/10425