文章总结： 本文介绍了ABOM（动作物料清单）的概念，它是一份记录CI/CD流水线所有依赖项的完整清单，包括直接依赖、传递依赖和内嵌工具。文章通过Trivy事件说明了跟踪这些依赖的重要性，并推出了开源工具abom用于生成和检查ABOM，以帮助组织进行事件响应、CI准入控制和合规性管理。 综合评分： 85 文章分类： 供应链安全,应用安全,云安全,安全工具,解决方案

别等下一个 Trivy：开源ABOM工具看清你所有GitHub Actions依赖

Dubito Dubito

云原生安全指北

2026年3月31日 08:35

注：本文翻译自 Juliet Security Team 的文章《Introducing the ABOM: Why Your CI/CD Pipelines Need a Bill of Materials》[1]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

一、引言

一份 ABOM（动作物料清单，Actions Bill of Materials） 是您 CI/CD 流水线所依赖的每一个 GitHub Action 的完整清单——包括那些隐藏在复合 action、可复用工作流以及工具封装器（tool wrapper）中、且您的工作流文件从未直接提及的传递依赖。

如果您了解什么是 SBOM，那么您就明白 ABOM 的概念了。SBOM 负责编录应用的依赖项，而 ABOM 则负责编录流水线的依赖项。而就目前而言，大多数组织对其 CI 环境中实际运行的内容毫无头绪。

二、问题所在

以这个工作流为例：

- name: Scan for vulnerabilities
  uses: crazy-max/ghaction-container-scan@v3

其中完全没有提到 Trivy。但 ghaction-container-scan 会在内部下载并运行 Trivy。2026 年 3 月，当 77 个 Trivy 发布标签中的 76 个被植入了窃取凭证的恶意软件[2] 时，那些仅在工作流中搜索 trivy-action 的组织并未发现任何问题——于是他们便认为自己很安全。

然而事实并非如此。

这并非 Trivy 特有的问题，而是一个结构性问题。GitHub Actions 和应用代码一样，拥有自己的依赖树，但一直以来并没有人对其进行追踪。

三、为什么 SBOM 无法覆盖这种情况

SBOM 记录的是进入你软件内部的内容——即库、包、容器基础镜像等。这是针对制品的部分。

但负责构建、测试、扫描和部署该软件的流水线，其自身也有一棵依赖树。一个被攻破的 CI action 可以窃取你流水线中的每一个 secret，污染它所接触的每一个制品，并向每一个下游系统传播——而这些都不会出现在 SBOM 中。

在 Trivy 事件之后，这就不再只是理论上的可能性了。该攻击从 CI runner 中窃取了 AWS 凭证、Kubernetes 令牌、Docker 配置以及 SSH 密钥，然后利用窃取到的 npm 凭证，将一个能够自我传播的蠕虫发布到了下游包中。这条流水线就是这一切的入口点。

四、ABOM 包含哪些内容

一份 ABOM 会映射你工作流中的每一个 action，并进行递归解析：

直接依赖——你工作流中显式引用的 action。这就是 grep 能找到的部分。

传递依赖——由你工作流所使用的复合 action 或可复用工作流调用的 action。这是 grep 会遗漏的部分。你工作流中的一个 uses: 行，可能会解析出一条包含五六个嵌套 action 的链条，其中任何一个都有可能被攻破。

内嵌工具——那些不会调用其他 action，但会在后台下载并执行外部工具（如 Trivy、Grype 或 Snyk）的 action。这些工具根本不会作为 action 依赖项暴露出来——你必须分析 action 的元数据和输入参数才能检测到它们。

对于每一个 action，ABOM 都会记录其所有者、仓库、版本引用、该引用是指向一个不可变的 SHA 还是一个可变的标签，以及你的工作流是通过怎样的完整链条到达该 action 的。

五、如何使用 ABOM

事件响应。当一个 GitHub Action 被攻破时，你需要在几分钟内就知道自己是否受到影响——而不是等到对工作流所使用的每个复合 action 都做完人工审计之后。通过查询 ABOM 来定位受影响的 action，你就能立即得到答案，包括传递依赖和内嵌工具所暴露的风险。

CI 准入控制。在每次 pull request 时生成一份 ABOM，如果其中包含已知的被攻破 action，就终止本次构建。这与你因为应用依赖中存在严重 CVE 而终止构建的方式是一样的。

合规性。如果你已经在为满足监管或客户要求而生成 SBOM，那么你的 CI/CD 流水线就是这份清单中的一个缺口。而 ABOM 可以填补这个缺口。

漂移检测。对比不同构建之间的 ABOM，以便检测是否有新的传递依赖出现，或者之前固定（pin）到 SHA 的 action 是否被改为了可变标签。

六、标准格式

ABOM 不应成为某种专有格式。CI 流水线中的依赖关系可以很好地映射到现有的 BOM 标准上：

• • CycloneDX 1.5 — action 作为组件（component），传递关系放在依赖图中，被攻破的 action 以漏洞的形式呈现。可直接接入 Dependency-Track、Grype 等工具。
• • SPDX 2.3 — action 作为包（package），通过 DEPENDS_ON 关系进行关联。可与现有的许可证合规及 SBOM 聚合工具配合使用。

这意味着你可以用管理应用依赖的同一套工具来管理你的流水线依赖。

七、试用

我们构建了 abom[3] 工具，用于从任意 GitHub 仓库生成 ABOM：

# 安装
go install github.com/julietsecurity/abom@latest

# 为你的仓库生成 ABOM
abom scan .

# 对照已知被攻破的 action 进行检查
abom scan . --check

# 导出为 CycloneDX 格式
abom scan . -o cyclonedx-json

该工具会从 GitHub 获取 action 元数据以解析传递依赖，在本地缓存结果，并对照一个由社区维护的已知被攻破 action 的公告数据库[4]进行检查。它基于 Apache 2.0 许可证开源。

八、此类事件还会再次发生

Trivy 被入侵事件并非个例。GitHub Actions 是高价值目标：它们运行时能够访问云凭证、部署密钥、包仓库令牌以及生产基础设施。任何一个被广泛使用的 action，都可能仅仅因为一个配置错误的令牌，就成为下一个供应链安全事件的主角。

问题在于：你是希望借助工具来确认自己是否受到了影响，还是等到事故报告出来之后才恍然大悟。

引用链接

[1] 《Introducing the ABOM: Why Your CI/CD Pipelines Need a Bill of Materials》: https://juliet.sh/blog/introducing-the-abom-why-your-ci-cd-pipelines-need-a-bill-of-materials [2] 77 个 Trivy 发布标签中的 76 个被植入了窃取凭证的恶意软件: https://juliet.sh/blog/trivy-supply-chain-compromise-what-kubernetes-teams-need-to-know [3] abom: https://github.com/JulietSecurity/abom [4] 由社区维护的已知被攻破 action 的公告数据库: https://github.com/JulietSecurity/abom-advisories

交流群

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云原生安全指北 Dubito Dubito《别等下一个 Trivy：开源ABOM工具看清你所有GitHub Actions依赖》