What is an SBOM (and Why Can’t You Ship Without One)?

解释软件物料清单（SBOM） | Docker

什么是SBOM（以及为什么没有它就无法发货）？

发布于 2026 年 6 月 23 日

Aditya Tripathi

根据 Omdia 2026 年软件供应链安全报告，73% 生成 SBOM 的组织表示它们能够更高效地缓解漏洞，但仍有 86% 的组织发现生成过程具有挑战性。这种公认价值与操作难度之间的差距是大多数团队所面临的困境。对于构建和保护容器化应用程序的团队来说，了解 SBOM 是什么以及如何使其有用，已经不再是可选的。

本指南涵盖 SBOM 包含的内容、它们对软件供应链安全的重要性、标准格式和工具的工作原理，以及行业在法规和执行方面的发展方向。

关键要点：SBOM 是软件制品中每个组件的机器可读清单。当 SBOM 与来源证明和加密签名结合使用时，其价值才真正显现。在镜像构建时生成 SBOM 可以捕获完整的依赖树，包括操作系统包。法规要求（如 EO 14028、CISA 指南、欧盟 CRA）正在使 SBOM 成为采购的基准。

什么是 SBOM？

每个软件制品都带有依赖项。基于 Alpine Linux 的容器镜像可能包含数十个系统包，每个包都有自己的版本、许可证和上游维护者。顶部的应用层添加了框架、库和传递依赖项，这些依赖项可能是开发人员从未明确选择的。堆栈越深，回答一个基本问题就越困难：生产环境中实际运行的是什么？

软件物料清单回答了这个问题。它是一个结构化、机器可读的清单，列出了软件制品中的每个组件、库和模块。与 package.json 或 requirements.txt 这样的包清单列出声明的依赖项不同，SBOM 在构建后捕获了已解析的依赖树，包括传递依赖项、系统级包以及每个组件的来源、版本和许可证的元数据。可以将其视为软件的营养标签。

SBOM 包含的内容

一个结构良好的 SBOM 包含每个组件的几类元数据：

• 组件标识：包名称、版本和供应商（例如，openssl 3.1.4，由 OpenSSL 项目维护）

• 许可证：管理重新分发和使用的许可证类型（MIT、Apache 2.0、GPL）

• 依赖关系：组件之间如何相互依赖，包括直接和传递依赖

• 唯一标识符：包 URL（purl）或 SWID 标签，这些标识符可用于与漏洞数据库进行交叉引用

• 校验和和摘要：加密哈希，使消费者能够验证组件未被篡改

这些数据使用开放标准（主要是 SPDX 或 CycloneDX）进行结构化，以保持其机器可读性和在工具、注册表和合规工作流程中的互操作性。实际上，一个 SPDX SBOM 条目对于单个包看起来如下所示：

{
  "name": "openssl",
  "SPDXID": "SPDXRef-Package-openssl",
  "versionInfo": "3.1.4",
  "supplier": "Organization: OpenSSL Project",
  "licenseDeclared": "Apache-2.0",
  "checksums": [{ "algorithm": "SHA256", "value": "a1b2c3..." }]
}

一个真实的 SBOM 包含每个组件的条目，从基础镜像的操作系统包一直到应用程序的运行时依赖项。

SBOM 的价值在出现问题的那一刻就变得显而易见。2021 年 12 月 Log4Shell 漏洞披露后，拥有当前 SBOM 的组织可以在几分钟内查询其库存并识别所有受影响的镜像。而没有 SBOM 的团队则需要花费数天时间手动追踪跨注册表和部署清单的依赖关系。

Sonatype 的研究表明，近 65% 的开源 CVE 缺乏 NVD 分配的 CVSS 分数，而独立评分后，46% 的漏洞被判定为高风险或关键风险。没有 SBOM，这些未评分的漏洞将变得不可见。

更快的事件响应

当一个新的 CVE 出现时，第一个问题总是：我们暴露在哪些地方？SBOM 能在几秒钟内回答这个问题，而不是几天。将受影响的包和版本与 SBOM 库进行交叉参考，你就能立即知道影响范围。将 SBOM 与持续的漏洞扫描结合使用，这一过程可以实现自动化：新的 CVE 会与现有的 SBOM 进行匹配，受影响的镜像会被自动标记，无需人工干预。

客户案例：JWP 是一个服务于超过 10 亿用户的视频流媒体平台，他们在不到一小时内实现了对 400 多个仓库的漏洞扫描。通过 SBOM 提供的扫描流水线，该团队修复了数千个漏洞，同时过滤掉了数万个非关键问题，减少了噪音并加快了修复速度。

合规性要求

SBOM 正在从最佳实践转变为法律要求。在美国，总统行政命令 14028 为销售给联邦机构的软件设定了 SBOM 的要求。CISA 的 2025 年最低要素指南旨在明确一个有用的 SBOM 应包含哪些内容。欧盟的网络韧性法案（EU CRA）将类似的要求扩展到了在欧洲市场销售的产品。对于在受监管行业（如金融、医疗、国防和关键基础设施）运营的组织来说，SBOM 的交付正在成为采购的准入条件。

主动验证，而非被动信任

SBOM 将安全模型从假设软件是安全的转变为验证其是否安全。团队不再仅仅因为注册表的说法而信任基础镜像是干净的，而是可以通过检查 SBOM 来确认哪些包存在、哪些版本正在运行以及是否存在已知的漏洞。

实际上，这意味着基于 SBOM 数据编写策略：如果镜像中包含来自未经批准供应商的包，则不允许发布；如果某个生命周期结束的组件超过了定义的宽限期，则不允许继续存在；如果没有匹配的 SBOM 证明，则不允许部署镜像。这些检查可以在 CI 中自动运行，将 SBOM 从被动文档转变为一个主动的控制点。

当与来源证明和加密签名结合使用时，SBOM 成为了从源代码到部署的可验证的托管链中的一层。你不再仅仅依赖注册表的说法，而是通过加密验证其真实性。

SBOM 格式和标准

为了使 SBOM 在团队、工具和组织之间具有实用性，它需要一种通用的语言。目前有两个主流的开放标准，每个标准都针对不同的主要使用场景。

SPDX（软件包数据交换）

由 Linux 基金会（ISO/IEC 5962:2021）开发，SPDX 是目前最广泛采用的用于许可证合规和开源审计的格式。它也是 BuildKit 内置 SBOM 生成器使用的格式，该生成器在构建过程中将一个 SPDX 文档作为证明附加到容器镜像上。

CycloneDX

由 OWASP 基金会开发，CycloneDX 针对安全工作流程和 DevSecOps 管道进行了优化。它包含用于漏洞元数据和依赖关系图的字段，并且与 OWASP Dependency-Track 等工具集成良好。

一瞥 SBOM 格式

SPDX

CycloneDX

主要关注点

许可证合规、开源审计

安全、漏洞管理

由以下组织管理

Linux 基金会（ISO/IEC 5962:2021）

OWASP 基金会

格式类型

JSON、YAML、标签值、RDF/XML

JSON、XML、Protocol Buffers

最适合

合规、尽职调查、审计

DevSecOps 管道、CI/CD 集成

容器生态系统支持

BuildKit 证明原生支持

也由 Syft 和 Trivy 等工具生成

如果你正在构建容器镜像，从 SPDX 开始。它是 BuildKit 原生生成的格式，因此你可以在构建过程中零额外工具生成 SBOM。你的下游扫描工具可能更喜欢 CycloneDX，这也没关系。这两种格式是互操作的，并且存在在它们之间转换的工具。让构建过程生成 SPDX；如果消费工具需要，让它们处理转换。

SWID（软件识别标签），由 ISO/IEC 19770-2 管理的第三种格式，主要用于企业及政府采购中的 IT 资产管理。但在云原生和容器工作流程中，它已经失去了大部分吸引力。

SBOM 在容器工作流程中的位置

在传统的软件开发中，SBOM 通常是在事后生成的，在发布过程中作为合规性工件附加。容器工作流程提供了一种更好的方法：在构建时生成 SBOM，作为镜像构建过程的原生输出。

构建时生成

当你使用 BuildKit 构建容器镜像时，构建器会扫描最终的镜像文件系统，并生成一个反映实际内容的 SBOM，而不仅仅是 Dockerfile 中声明的内容。因为它捕捉了所有构建阶段完成后的解析状态，因此包括操作系统级别的包、应用级别的依赖项，以及从外部源复制的任何文件。

在构建之前从清单文件生成的源级 SBOM 经常会遗漏传递依赖项和系统包。镜像层 SBOM 反映的是现实情况。

证明和来源

SBOM 告诉你镜像中包含什么内容。来源证明则告诉你它是如何构建的：使用了哪个构建器、哪个源代码提交、哪个构建平台。它们共同构成了一个可验证的证据链，审计员和策略引擎可以对其进行编程评估。这就是 SLSA（软件工件供应链级别）所描述的模型，其中构建级别 3 要求使用具有不可伪造来源的加固构建平台。SLSA 是规范，in-toto 是它使用的证明格式。

SBOM 本身通过使用 SPDX 预测格式作为 in-toto 证明附加到镜像上。来源信息也以相同方式附加，因此两者都随镜像一起作为可验证的、机器可读的元数据进行传输。

注册表存储

一旦镜像及其证明信息构建完成，它们需要存储在消费者可以访问的地方。将镜像推送到符合 OCI 标准的注册表中，可以将 SBOM 与它所描述的工件放在一起。这很重要，因为如果 SBOM 存储在独立的系统、共享驱动器、合规门户或 CI 工件存储桶中，最终会与生成它的镜像失去同步。共存消除了这一差距：拉取镜像时，同时也会拉取其 SBOM 和来源证明。

持续扫描

当 SBOM 附加到镜像并存储在注册表中时，它们就成为持续漏洞监控的输入。新的 CVE 会与 SBOM 中列出的组件进行匹配，而无需重新分析镜像本身。当披露新的漏洞时，扫描器不需要重新扫描所有镜像，而是通过交叉参考 SBOM 清单，立即标记受影响的镜像。

策略执行

扫描识别风险，执行则针对风险采取行动。策略引擎可以使用 SBOM 数据，根据团队定义的规则来控制部署：如果镜像包含来自未经批准供应商的软件包，则不允许发布；如果组件已过生命周期且超过定义的宽限期，则不允许继续使用；如果没有匹配的 SBOM 证明信息，则不允许部署镜像。

这些检查在 CI 中自动运行，使 SBOM 从被动文档转变为一个主动的控制点。你不再依赖人工审查来发现有问题的依赖项。流水线会在镜像进入生产环境之前就捕获到问题。

SBOM 成熟度：你的组织处于哪个阶段？

SBOM 的采用并不是非黑即白的。大多数组织处于从临时到完全扩展的光谱中的某个位置。以下的成熟度模型可以帮助团队评估他们目前所处的位置以及下一步应优先考虑的内容。

| 层级 | 生成 | 存储 | 扫描 | 治理 | |------|------|------|------|------| | 临时 | 手动，按需生成 | 本地文件或共享驱动器 | 偶尔，依赖工具 | 无正式策略 | | 试点 | 自动化，用于 1-2 个应用或服务 | 与构建工件一起存储 | 集成到试点应用的 CI 中 | 草拟基本策略 | | 生产 | 自动化，用于所有新镜像 | 附加到 OCI 注册表中的镜像 | 持续扫描并具有警报功能 | 在流水线中执行策略 | | 扩展 | 所有镜像，包括第三方镜像 | 集中式 SBOM 管理平台 | 持续扫描并带有策略控制 | 跨组织治理、审计追踪、供应商要求 |

Omdia 2026 年软件供应链安全调查发现，超过一半生成 SBOM 的组织只是在特定情况下生成 SBOM。

关于 SBOM 的常见误解

SBOM 只是一个合规性检查框

仅为了满足采购需求而生成 SBOM 的团队忽略了其操作价值。SBOM 最有价值的是作为漏洞管理、事件响应和依赖跟踪的实时数据源。为审计一次性生成的 SBOM 并存档，会给人一种错误的安全感。

它们与 SCA 相同

软件成分分析（SCA）工具扫描代码或镜像中的已知漏洞。SBOM 是使这种扫描成为可能的清单。SCA 和 SBOM 通常协同工作。SBOM 是清单，SCA 工具使用该清单，通常生成自己的清单，以检查已知的漏洞。这一区别很重要，因为扫描的效果往往取决于其背后的清单质量。

SBOM 是一次性工件

SBOM 与特定的镜像摘要相关联。每次重新构建镜像时，都应该重新生成 SBOM 以反映任何依赖项的变化。过时的 SBOM 会在你认为正在运行的内容和实际部署的内容之间造成差距。自动化构建时生成可以消除这种偏差。

SBOM 替代运行时安全

SBOM 告诉你哪些内容被部署了。它们不会告诉你运行时发生了什么。SBOM 无法检测尚未公开的零日漏洞，无法检测正在运行的容器内的异常进程行为，也无法验证应用程序逻辑是否正确。SBOM 是纵深防御模型中的一层：它们处理清单和组成。运行时监控、网络策略和访问控制则处理其余部分。

#### 没有 SBOM 会发生什么

假设一个广泛使用的库中披露了一个零日漏洞。没有 SBOM 的情况下，安全团队开始进行手动排查：检查 Dockerfile，查询注册表，询问开发人员使用的是哪些版本。时间过去了好几个小时。由于受影响的包是一个三层深度的传递依赖项，一些镜像被遗漏了。等到确定漏洞影响范围时，该漏洞已经公开了两天。

如果每个镜像都附有 SBOM，同样的排查只需几分钟。查询 SBOM 数据库中受影响的包和版本，获取包含它的所有镜像列表，并根据部署上下文优先处理修复。

开始使用 SBOM

团队最常见的错误是将 SBOM 采用视为一个大规模的转型项目，这会阻碍工作流程。其实不需要这样。

• 从一个镜像开始。选择一个生产镜像，并在下一次构建时启用 SBOM 生成。使用 BuildKit，只需一个标志：

docker buildx build --attest type=sbom --tag myapp:latest .

查看输出结果。这一步通常会揭示你之前不知道存在于镜像中的传递依赖项和操作系统包。

• 在 CI 中自动化生成。将该标志扩展到 CI 流水线中，使每个镜像构建都自动生成 SBOM。

• 将 SBOM 与镜像一同存储。将 SBOM 作为证明信息附加到 OCI 注册表中，使 SBOM 与它所描述的工件保持共存。

• 连接到监控。将 SBOM 输入到可以持续将组件与新 CVE 匹配的漏洞监控工具中。这在清单和行动之间形成了闭环。

• 设置策略。定义什么是可以接受的：最大 CVE 年龄、所需的最低 SBOM 完整性、被阻止的许可证。在流水线中强制执行这些策略，使不符合要求的镜像在部署前被标记。

Docker 使这一工作流程成为原生支持。Docker 加固镜像附带完整的 SBOM、SLSA 构建等级 3 的来源信息、OpenVEX 漏洞利用数据以及每张镜像的加密签名。同时，Docker Scout 通过附加到镜像的 SBOM 数据提供持续的漏洞监控，为整个镜像组合提供可操作的洞察。它们共同为团队提供从源代码到生产环境的可验证的保管链，无需任何手动组装。

常见问题

SBOM 是什么的缩写？

SBOM 是“软件物料清单”的缩写。它是一个结构化的清单，列出了软件制品中包含的每个组件、依赖项和元数据元素，并以机器可读的标准格式（如 SPDX 或 CycloneDX）进行格式化。

SBOM 是否是法律要求？

在美国，总统行政命令 14028 要求向联邦机构销售的软件必须附带 SBOM。CISA 2025 年的草案指南提出了更新的最低元素要求。欧盟的《网络安全韧性法案》将类似的要求扩展到在欧洲市场销售的产品。对于受监管行业的组织，SBOM 正在逐渐成为采购的前提条件，而不仅仅是自愿实践。

SBOM 和包清单有什么区别？

包清单（如 package.json、requirements.txt、go.mod）列出了开发人员声明的依赖项。而 SBOM 在构建后捕获完整的依赖树，包括传递依赖、系统级包以及如许可证和校验和等元数据。清单是构建的输入；SBOM 是构建输出的反映，说明实际部署了什么。

SBOM 应该多频繁更新？

每当相关制品被重新构建时，都应该重新生成 SBOM。对于容器镜像，这意味着每次构建镜像时都要生成一个新的 SBOM。在重新构建之间，现有的 SBOM 对其描述的具体镜像摘要仍然有效，但针对其列出的组件可能会发现新的 CVE。通过持续监控存储的 SBOM 可以发现这些漏洞，而无需重新构建。

来源

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

关于作者

Docker 高级首席产品市场经理

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

概念

Docker 加固镜像

安全

软件供应链安全

产品

目录

相关文章

• 2026 年 5 月 12 日 Docker AI 治理：安全地释放代理自主权 介绍 Docker AI 治理：集中控制代理如何执行、它们在网络中可以访问什么、可以使用哪些凭证、可以调用哪些 MCP 工具，使公司中的每位开发人员都能在任何工作环境中安全地运行 AI 代理。笔记本电脑是新的生产环境。代理是最大的生产力解锁…… Srini Sekaran 阅读更多

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

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

• 2026 年 6 月 16 日 Docker 内容信任：退役和迁移指南 Docker 内容信任（DCT）和 notary.docker.io 上的 Notary v1 服务将被完全退役（首次于 2025 年 7 月宣布）。这篇博客解释了将发生哪些变化，哪些人会受到影响，以及如何迁移到现代替代方案。Julia Wilson 和 Aditya Tripathi 立即阅读