2026 年 3 月中旬，开源安全扫描工具 Trivy 的 GitHub Actions 生态遭受供应链攻击。攻击者获取了 aquasecurity/trivy-action 仓库的写入权限后，对仓库中的版本标签实施_force-push_篡改，将 75 个已有标签重新指向包含恶意代码的提交。这一攻击利用了 CI/CD 流程对官方 Action 的信任，使得大量下游工作流在执行时自动下载并运行了恶意 Payload，导致存储在 GitHub Secrets、GitHub Actions 运行时环境变量以及云服务凭证被攻击者窃取。根据公开披露的信息，此次攻击影响了数千个依赖该 Action 的项目，造成的潜在泄露范围覆盖 AWS、GCP、Azure 的访问密钥，Kubernetes ServiceAccount 令牌以及部署流程中使用的 SSH 私钥。
攻击向量与影响范围
此次攻击的核心在于 GitHub Actions 的标签引用机制存在可变性。当工作流文件使用类似 uses: aquasecurity/trivy-action@v0.69.4 的写法时，GitHub 会在每次工作流触发时解析该标签指向的最新提交。如果攻击者拥有仓库的推送权限，即可通过 force-push 强制将已有标签指向任意 commit，形成「标签劫持」。被劫持的工作流 Runner 在执行 actions/checkout 步骤之前或之后，会加载攻击者植入的恶意脚本，这些脚本通常会遍历 ${{ secrets.* }}、${{ env.* }} 以及 Runner 进程的环境变量，将敏感信息通过 HTTP 请求发送到攻击者控制的外部服务器。安全研究人员追踪发现，攻击者还尝试从内存中提取已加载的云服务凭证，以便横向移动到受害组织的基础设施中。
受影响的不只是直接引用 aquasecurity/trivy-action 的仓库。由于 Trivy 生态中还存在 aquasecurity/setup-trivy、aquasecurity/trivy-policies 等多个关联仓库，攻击者可能通过这些依赖链进一步扩大影响范围。根据 The Hacker News 的报道，安全社区在 3 月 19 日至 20 日期间首次观测到异常的可疑标签更新活动，随后在 3 月 23 日左右完成公开披露。
工程化防御参数与配置清单
针对此类标签篡改攻击，组织可以从以下四个维度构建防御体系，每个维度给出可直接落地的参数建议。
一、版本引用强制使用完整 SHA
在所有工作流文件中，将 Action 引用从可变标签改为不可变的完整提交 SHA。GitHub 建议使用 7 位以上的 SHA 以兼顾可读性与安全性，实际工程中推荐使用完整的 40 位十六进制 SHA 以彻底消除哈希碰撞风险。具体配置示例如下：
# 错误示例：使用可变标签
- uses: aquasecurity/trivy-action@v0.69.4
# 正确示例：固定到完整 SHA
- uses: aquasecurity/trivy-action@8ba6f6a0a0c4bc9d9e6c6f0c7b3a2e1d9f8c7b6a
建议通过组织级别的 CI/CD 策略检查工具（如 conftest 或 opa）强制禁止在工作流中使用 @ 后跟非 SHA 字符串的模式。检测正则表达式可参考：uses:\s+[\w-]+\/[\w-]+@(?![\da-f]{40})[\w.-]+。
二、启用提交签名与分支保护规则
在所有管理 Action 的仓库中强制启用分支保护规则，具体参数如下：Require pull request reviews before merging 设置为至少 1 位审批者并要求审批者必须是仓库管理员或代码所有者；Require status checks to pass before merging 开启后必须包含 CI 检查；Require conversation resolution before merge 启用以确保所有评论得到处理。最关键的是 Require signed commits 必须开启，并配合 GitHub 的 GPG 密钥管理功能确保所有推送必须经过 GPG 签名。此外，Administrators 角色的仓库设置中应取消 "Include administrators" 选项的对撞防护豁免，防止管理员绕过保护规则。
三、迁移至 OIDC 临时凭证体系
长期存在的 Personal Access Token（PAT）和仓库 Secrets 是标签篡改攻击的主要目标。通过 OIDC（OpenID Connect）将认证改为短生命周期、可按需刷新的令牌，可显著降低凭证泄露后的横向移动风险。GitHub Actions 的 OIDC 部署配置需要满足以下条件：在云提供商（AWS、GCP、Azure）侧创建信任策略，仅授权特定 GitHub 组织名称 + 仓库名称 + 工作流触发分支；在 GitHub 侧使用 permissions: id-token: write 声明 OIDC 令牌请求权限，并使用云提供商的官方 Action（如 aws-actions/configure-aws-credentials）获取临时凭证。临时凭证的有效期通常控制在 1 小时以内，建议通过 duration-seconds 参数设置为 3600 秒以获得最长可用窗口。
四、标签异常监控与自动响应
在组织级别的安全监控体系中集成对 GitHub 仓库标签操作的审计。推荐部署的监控规则包括：检测单次推送中修改超过 10 个标签的事件；检测对受保护分支或标签的 force-push 操作；检测来自非管理员但具备写权限账户的标签删除操作。上述规则可通过 GitHub Audit Log API 配合 SIEM 平台（如 Splunk、Elastic）或开源方案（如 Wazuh）实现。在检测到可疑活动后，建议自动化执行以下响应步骤：首先通过 GitHub API 暂停所有使用受影响 Action 的工作流运行；其次通过仓库管理员渠道确认标签更新的合法性；最后在确认存在恶意篡改后，执行完整的凭证轮换流程，包括所有在最近 72 小时内被工作流访问过的云服务密钥、部署密钥和 API 令牌。
快速自检清单
以下是面向 DevSecOps 团队的即时可执行检查项，建议在阅读本文后立即完成验证：
第一，检查所有仓库的工作流文件中是否存在 uses: xxx/@v*.* 形式的非 SHA 引用，统计受影响的工作流总数并制定分批迁移计划。第二，确认管理关键 Action 的仓库已启用分支保护中的 Require signed commits 选项，并在管理员账户之外至少分配一名具备 GPG 密钥的代码所有者。第三，选取一个代表性项目，验证其云凭证获取方式是否已切换为 OIDC 模式，确保工作流中不再出现硬编码的 Access Key ID / Secret Access Key 组合。第四，在审计日志系统中配置标签变更的告警规则，验证告警通道（Slack、Webhook、邮件）能够正常触达安全运营团队。
资料来源
本文关键技术细节引自 The Hacker News 于 2026 年 3 月的公开报道，该报道披露了攻击的时间线、受影响标签数量以及安全社区建议的缓解措施。