How to Generate an SBOM for Container Workflows

容器工作流程的 SBOM 生成 | Docker

如何为容器工作流程生成 SBOM

发布于 2026 年 6 月 25 日

Aditya Tripathi

根据 Omdia 2026 年软件供应链安全报告，86% 的组织认为生成 SBOM 具有挑战性。主要驱动因素是工具碎片化：团队使用不同类型的扫描器处理不同类型的制品，导致在不同流水线中输出不一致，并花费大量工程时间来协调结果，而不是采取行动。

SBOM 对安全团队如何响应漏洞披露、合规团队如何满足审计要求以及采购决策如何做出变得越来越重要。这使得生成步骤变得至关重要。如果流水线生成的 SBOM 缺失了传递依赖项，记录的是声明的版本而不是解决的版本，或者没有与它描述的制品进行密码学绑定，那么所有基于这些数据的下游决策都会继承这些缺陷。

本文将涵盖决定 SBOM 质量的决策：何时何地生成，如何区分可操作的输出与仅用于满足要求的数据，以及如何在图像组合增长时保持生成的可靠性。

关键要点：构建时生成的 SBOM 比构建后扫描生成的 SBOM 更完整、更准确。完整性、准确性、新鲜度和可验证性决定了 SBOM 是否具有可操作性。生成工具需要以提升的构建权限运行，可能需要额外的安全考虑，例如固定到不可变的引用。附带预构建 SBOM 的镜像可以消除基础层的生成负担。

何时生成：构建时 vs 构建后

影响 SBOM 质量的最关键决策是何时生成它。有两种广泛的方法，它们会产生明显不同的结果。

构建时生成

构建时生成会直接集成到构建系统中。生成器可以访问已解决的依赖树、包管理器文件以及完整的构建上下文。它确切地知道哪些内容进入了制品，因为这些内容在制品组装时就存在。

具有原生认证支持的容器构建系统可以在镜像构建过程中生成一个 SPDX SBOM，将其作为 in-toto 认证附加，并通过一次操作将镜像和 SBOM 推送到注册表。语言特定的构建插件对应用程序依赖项采用类似方法，在标准构建生命周期中生成 SBOM。

其优势在于结构性：构建时生成可以捕获每个依赖项的解决状态，包括构建后扫描器可能遗漏的传递依赖项。

构建后扫描

构建后工具会扫描已完成的制品并反向推断其内容。它们通过识别包管理器元数据、文件签名以及制品中的已知模式来工作。这种方法适用于任何 OCI 兼容的镜像，无论其是如何构建的。

权衡在于覆盖范围。静态链接的二进制文件、供应商依赖项以及在中间构建阶段安装的操作系统包可能会被构建后扫描器遗漏。扫描器只能报告其能够检测到的内容，而检测是基于启发式方法，而不是从实际构建图中推导出来的。

当你有构建系统访问权限时，应在构建时生成。构建后扫描适用于你使用但未构建的第三方镜像，或没有构建系统集成的遗留制品。

对于容器镜像，我们的文档详细介绍了如何配置构建时的SBOM证明，包括不同构建工作流程的具体标志和生成器选项。

什么使SBOM有用

生成SBOM并不等于生成一个有用的SBOM。文件格式是标准的，但内容的质量会根据SBOM生成的时间和方式而有很大差异。五个标准将可操作的SBOM与仅用于勾选的SBOM区分开来。

1. 完整性

一个完整的SBOM会记录所有层和所有包类型中工件的每个组件。这包括来自基础镜像的操作系统包、构建过程中每个包管理器的应用程序依赖项，以及构建过程中添加的任何工具或实用程序。

这就是多阶段构建和最小基础镜像真正产生差距的地方。一个包含Node前端、编译成静态二进制文件的C或C++组件，以及无发行版最终阶段的Dockerfile，提出了三个不同的挑战：Node层有深度的传递依赖树，静态链接的二进制文件通常在磁盘上没有依赖清单，而无发行版的基础镜像根本没有包管理器。构建后扫描器可能会遗漏静态链接的依赖项，并可能低估Node树。只有在构建时生成，并且能够访问每个阶段解析后的依赖图，才能获得完整的视图。

2. 准确性

准确性意味着SBOM记录的是解析后的版本，而不是声明的范围。一个包清单可能声明“^4.17.0”，但锁定文件中的解析版本是4.17.21。SBOM必须反映实际安装的版本，而不是请求的版本。

3. 新鲜度

SBOM是一个与特定构建相关联的时间点快照。每次重新构建工件时，SBOM都应该重新生成。过时的SBOM会产生虚假的可见性。

4. 可验证性

一个可验证的SBOM是消费者可以确认它是由构建系统生成且未被篡改的SBOM。密码学签名和证明框架将SBOM绑定到特定的工件摘要，并记录工件的构建来源和方式。

5. 格式兼容性

标准格式如SPDX和CycloneDX定义了必填和可选字段。一个符合模式验证的SBOM可以在扫描工具、策略引擎和合规工作流程中实现互操作性。不符合的SBOM可能与当前工具兼容，但当你更换工具时可能会出现问题。

一些基础镜像已经附带了符合所有五个标准的SBOM，以及SLSA构建等级3的来源信息和漏洞利用数据。这些SBOM是在加固的构建平台上在构建时生成的，具有不可伪造的来源信息，经过密码学签名，并作为in-toto证明绑定到镜像摘要。它们在每次重新构建时都会持续重新生成，因此新鲜度得以维持，无需人工干预。对于这些镜像，生成问题已经在堆栈最关键的一层得到了解决，而你的工作重点则转移到为添加在顶部的应用层生成一个完整的SBOM。

你的生成工具链是攻击面

你用来生成SBOM的工具在构建环境中拥有提升的访问权限。它们读取你的源代码、依赖树和构建工件。一个被入侵的生成器不仅会产生错误的输出，还拥有窃取或修改扫描内容的权限。

这不是一个理论上的担忧。GitHub Actions 和容器镜像上的版本标签是可变的。今天你固定到 v2.1 的一个工具，如果维护者账户被入侵或标签被强制推送，明天就可能变成完全不同的东西。这类事件的暴露窗口通常以小时计算，但自动化流水线可能在几分钟内就拉取到被入侵的版本。

对待你的生成工具，要像对待其他任何构建依赖项一样严格：

• 固定到不可变的引用（提交 SHA，而不是版本标签）。

• 在执行前验证校验和。

• 在 CI 中运行生成，而不是在开发人员机器上，以确保输出可重复且可审计。

• 监控生成工具的上游安全公告。

这是更广泛的软件供应链安全挑战的一个维度：流水线中的每个工具都是一个依赖项，需要像应用程序代码一样受到同样的审查。对于基础镜像，你可以完全规避这种风险。在经过加固的构建平台构建的镜像，其供应链元数据从源头开始就携带了不可伪造的来源信息，并通过端到端的加密验证确保其完整性。

将 SBOM 生成集成到 CI/CD 中

手动生成 SBOM 适用于一次性审计。对于生产工作流程，生成需要自动化、可重复，并与交付流水线的其余部分集成。这种模式在所有 CI 系统中都是一致的。

在构建时生成

将 SBOM 生成作为构建阶段的一步，紧随镜像生成之后。对于容器镜像，BuildKit 的认证标志是最可靠的方法。对于应用程序依赖项，语言特定的插件（如 Maven/Gradle 的 CycloneDX，Node 的 npm/yarn）能生成质量最高的输出，因为它们可以访问解析后的依赖图。

对于多阶段构建，只从最终阶段生成 SBOM。中间阶段通常会安装构建工具和测试框架，而这些内容不会包含在生产镜像中。如果对中间阶段生成 SBOM，会导致 SBOM 中包含未部署的组件，从而在漏洞扫描中产生噪声。

选择一个认证格式

SPDX 是 BuildKit 认证的原生输出格式，如果许可证合规是主要关注点，SPDX 是更优的选择。CycloneDX 提供了更丰富的漏洞关联支持和更细致的组件分类，因此更适合以安全为重点的工作流程。如果你的使用工具（策略引擎、漏洞扫描器、合规仪表板）有偏好，请遵循它。如果它们都支持，对于容器镜像默认使用 SPDX，因为它不需要超出 BuildKit 内置生成器的额外工具。

附加到制品

将 SBOM 与它描述的制品一起存储。对于容器镜像，这意味着将其作为 OCI 认证附加到注册表中，而不是将其保存为制品存储中的单独文件。基于认证的存储方式使 SBOM 可被发现、版本化，并绑定到特定的镜像摘要。当镜像从开发环境提升到测试环境再到生产环境时，SBOM 会随着镜像在每个注册表中一起移动，而不是需要一个不可避免会漂移的单独复制和同步流程。

发布前验证

在生成和推送至注册表之间添加一个验证步骤。将 SBOM 通过格式验证器进行验证（SPDX 和 CycloneDX 都提供了官方的 schema 验证工具），检查组件数量是否合理，确保 SBOM 引用了正确的镜像摘要。如果一个构建生成了 12 个组件，而你清楚知道该镜像包含 200 多个包，那么该构建应失败于流水线，而不是静默地发布。

持续扫描和强制执行

在构建时生成 SBOM 可以捕获实际发布的内容。持续扫描可以告诉你自发布以来出现了哪些新的漏洞。每天都会出现新的 CVE，一个在构建时干净的 SBOM 可能在几周内出现关键暴露。通过 SBOM 数据进行持续分析，可以将新的披露信息与你的清单进行匹配，而无需重新拉取镜像，并且可以即时发现策略违规。通过将 SBOM 附加到每个镜像，你可以控制部署：没有有效 SBOM 的镜像不能发布，包含已知漏洞包（严重程度超过设定阈值）的镜像不能部署。

实现细节因 CI 系统而异。我们的文档涵盖了在常见容器构建工作流中生成和附加 SBOM 认证的具体标志和配置。

验证你的 SBOM 输出

在依赖 SBOM 输出进行合规性报告或漏洞管理之前，请验证其是否符合以下质量标准。

• 组件数量合理性检查：将 SBOM 中的组件数量与 Dockerfile、锁定文件和基础镜像中预期的数量进行比较。一个声明了 200 个依赖项的 Node.js 应用，一旦包含传递依赖，应生成大量条目。

• 已解析的版本，而非范围：抽查条目以确认 SBOM 记录的是具体的版本（如 4.17.21），而不是声明的范围（如 ^4.17.0）。

• 传递依赖深度：验证传递依赖是否出现在 SBOM 中，而不仅仅是顶层包。如果你的应用声明了 30 个直接依赖，但 SBOM 中只有 32 条记录，传递依赖的覆盖可能不完整。

• 操作系统包覆盖：确认基础镜像的操作系统包与应用程序依赖项一起出现在 SBOM 中。

• 摘要绑定：验证认证引用了正确的镜像摘要。未绑定的 SBOM 无法被信任以描述其对应的制品。

• 格式验证：将 SBOM 通过 schema 验证器进行验证（SPDX 和 CycloneDX 都提供了官方工具）。

开始生成，然后开始验证

将 SBOM 生成添加到你的流水线的最佳时机是下次你修改 CI 配置时。从流量最高的生产镜像开始。配置构建时的生成，将 SBOM 作为认证附加，并将输出与上述检查清单进行验证。然后扩展到你的整个产品组合。

如果你想有一个良好的起点，Docker Hardened Images 已经附带了完整的 SBOM、SLSA 构建级别 3 的来源信息和 OpenVEX 数据，因此你可以完全跳过基础层的生成步骤。对于你构建在基础层之上的所有内容，Docker Scout 提供了针对 SBOM 数据的持续漏洞匹配，并在你的镜像组合中强制执行策略。

• 立即使用 Docker Hardened Images 开始 →

• 通过 Docker Scout 探索漏洞监控 →

常见问题

SBOM 的最佳格式是什么？

对于容器镜像，默认使用 SPDX，因为它是 BuildKit 原生的验证输出，不需要额外的工具。如果您的主要使用场景是安全扫描，并且下游工具更倾向于使用 CycloneDX，则选择 CycloneDX。

如果我的镜像已经包含了一个 SBOM，是否还需要生成新的 SBOM？

如果您使用的是已包含预构建 SBOM、来源信息和可利用性数据的基础镜像，那么对于该层不需要重新生成 SBOM。包含的 SBOM 在构建时生成，并且可以完全访问构建图，同时通过密码学方式绑定到镜像。

为了验证预构建的 SBOM 是否可信，请检查以下两点：

• SBOM 是否作为签名的验证信息附加（而不是一个松散的文件）？

• 验证信息是否包含 SLSA 来源信息？

如果来源信息可以追溯到一个加固的构建平台，并且具有不可伪造的来源信息，那么您可以将该层的 SBOM 视为权威的。您仍然需要为添加在该层之上的应用程序依赖项生成 SBOM。

我应该多久重新生成一次 SBOM？

每次重新构建制品时都需要重新生成 SBOM。如果您的 CI 流水线生成了一个新的镜像，它也应该生成一个新的 SBOM 以匹配。在两次重新构建之间，现有的 SBOM 仍然是准确的，因为制品本身没有发生变化。

生成 SBOM 是否是合规的必要条件？

在美国，总统行政命令 14028 为销售给联邦机构的软件设定了 SBOM 的要求。欧盟《网络安全韧性法案》将 SBOM 的要求扩展到所有在欧盟销售的带有数字元素的产品。

随着人工智能工作负载受到诸如欧盟《人工智能法案》等新法规的约束，这些法规对技术文档和透明度提出了期望，组件级别的清单正成为团队展示高风险系统内部内容的一种实用方式。像 NIST SSDF 和 CISA 的 SBOM 指南等行业框架越来越多地将 SBOM 作为基本预期的参考。无论目前是否法律强制要求，SBOM 正在成为采购的必要条件。

来源

Omdia，《Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption》，2026 年 5 月。

作者简介

Docker 高级首席产品市场经理

Aditya Tripathi 负责 Docker 安全产品组合的产品营销，专长包括安全默认值、供应链风险以及如何让安全对开发人员有用。

概念

Docker 加固镜像

Docker Scout

SBOM

安全

产品

目录

相关文章

• 2026 年 5 月 12 日 Docker AI 治理：安全地解锁代理自主性 介绍 Docker AI 治理：集中控制代理如何执行、它们可以访问网络上的哪些资源、可以使用哪些凭证以及可以调用哪些 MCP 工具，这样公司中的每个开发人员都可以在其工作环境中安全地运行 AI 代理。您的笔记本电脑就是新的生产环境。代理是最大的生产力解锁…… Srini Sekaran 立即阅读

• 2026 年 6 月 25 日 如何为容器工作流生成 SBOM 学习何时、何处以及如何为容器镜像生成 SBOM。涵盖构建时与构建后的方法、质量标准以及 CI/CD 集成。Aditya Tripathi 立即阅读

• 2026 年 6 月 25 日 欧盟《网络安全韧性法案》：概述、要求和时间表 学习欧盟《网络安全韧性法案》的要求，包括 SBOM 的强制规定、漏洞报告以及容器团队的合规截止日期。Dan Stelzer 和 Monique Altman 立即阅读

• 2026 年 6 月 23 日 什么是 SBOM（以及为什么没有它就无法发货）？了解软件物料清单（SBOM）是什么，为什么它对供应链安全至关重要，如何生成一个 SBOM，以及应使用哪些格式和标准。Aditya Tripathi 立即阅读