SBOM（软件物料清单）

• CycloneDX 规范的核心概念
• BOM、component、dependency、service 的含义
• 工程应用

CycloneDX 是面向软件供应链的 SBOM 开放规范，用 JSON/XML 表示物料清单。核心对象：BOM（Bill of Materials）是描述软件组成的清单根节点；component 表示每个组件（库、应用、文件等），含 supplier、version、license 等元数据；dependency 描述组件间的依赖关系（直接与传递依赖）；service 表示软件依赖的外部服务（如 API、消息队列）。工程应用：构建时用 CycloneDX 工具生成 SBOM，随制品发布，供 SCA 扫描、漏洞关联与合规审计消费，形成可机器读的供应链数据。

CycloneDX 的 component/dependency/service 分层清晰，能既描述"组件清单"又描述"依赖与服务"，是供应链可视化的标准载体。

• SBOM 完整性的影响因素
• 依赖解析遗漏与动态构建依赖
• 与实际制品一致性的验证

SBOM 的完整性指清单是否覆盖实际制品中的全部组件，可信度指清单是否真实准确。失真来源：依赖解析遗漏（如未被包管理器记录的依赖、脚本动态下载的组件、构建期注入的依赖）、动态构建依赖（运行时下载、容器层内安装、CGO 等编译期引入的组件）、以及构建环境差异导致清单与产物不一致。验证与制品一致：在构建后生成 SBOM，而非仅用源码清单；用扫描器（如 Syft）从实际制品（镜像/二进制）反推组件清单并与 SBOM 比对；对制品与 SBOM 计算签名/哈希绑定，确保可追溯。

SBOM 的准确性取决于"从哪生成"，构建期从实际产物生成 + 用制品反推校验，才能保证清单与产物一致。

• NTIA 最小字段的内容
• 合规要求
• 落地方式

NTIA（美国国家电信与信息管理局）定义的 SBOM 最小字段（minimum fields）是 SBOM 的最低要求，包含：供应商名称（supplier name）、组件名称（component name）、组件版本（version）、组件的唯一标识（unique identifier）、依赖关系（dependency relationship）、作者（author）、时间戳（timestamp）。满足合规：生成的 SBOM 需覆盖这些字段，使用标准格式（CycloneDX/SPDX）以便机器可读，并随制品与发布流程生成与维护。许多自动化采购与监管要求以此作为 SBOM 的最低门槛。

NTIA 最小字段定义了"什么是可用 SBOM"的底线，是合规审计与供应链可见性的基础验收标准。

• 最小元素的内容
• 各元素含义
• 工程应用

SBOM 的最小元素（minimum elements）是描述每个组件所必需的核心字段，包括：supplier（供应商，提供组件的组织）、component（组件标识，名称与类型）、version（版本号，用于漏洞匹配）、license（许可证，用于合规判断）。此外常含唯一标识（如 SWHID、purl 包 URL）与依赖关系。工程上，一个可用的 SBOM 至少要为每个组件给出这些元素，才能支撑漏洞关联（按版本）、许可证合规（按 license）与溯源（按 supplier）。

最小元素是"组件级"的最低描述，缺任一字段都会影响漏洞/许可/溯源的可消费性。

• 各工具特点
• 生成方式
• 选型

SBOM 自动生成工具：Syft 是 Anchore 开源扫描器，从容器镜像、文件系统生成 SBOM（支持 CycloneDX 与 SPDX 格式），准确率高；SPDX Tools 是官方工具集，支持构建 SPDX 文档；CycloneDX CLI 是 CycloneDX 官方 CLI，可生成与校验 CycloneDX SBOM。工程上，在 CI 构建后用 Syft 从制品生成 SBOM，用 CycloneDX CLI 校验格式，再随制品签名发布。选型看格式偏好（CycloneDX vs SPDX）、扫描对象（镜像/源码）与集成需求。

生成工具决定 SBOM 的覆盖与准确性，Syft 为代表的"从制品反推"方式比源码清单更贴近实际产物。

• 三种生成方式
• 各方式的优缺点
• 选型

SBOM 三种生成方式：build-time（构建期生成）在构建过程中收集依赖信息，准确且与构建绑定，但需构建工具支持；post-build（构建后生成）在构建完成后扫描产物（如镜像）反推组件，覆盖实际产物但依赖扫描准确性；runtime（运行期生成）在运行时从进程/环境收集组件，反映真实运行组件但覆盖动态加载且开销大。工程上常用 build-time 或 post-build 组合：build-time 保证准确性，post-build 从制品兜底校验，runtime 用于运行态可见性。

选择生成方式取决于"准确性 vs 覆盖 vs 成本"，多数企业用 build-time + post-build 组合保证 SBOM 与实际产物一致。

• 两种格式的差异
• 工具生态
• 选型建议

SPDX 与 CycloneDX 都是主流 SBOM 标准。SPDX 由 Linux 基金会维护，偏重许可证表达（SPDX license expression）与合规，历史悠久、规范全面；CycloneDX 由 OWASP 维护，偏重安全与供应链（组件、依赖、漏洞、服务），结构与 JSON 友好、漏洞关联强。工具生态：SPDX 有 SPDX Tools、Supported 工具；CycloneDX 有 CycloneDX CLI、Syft 等原生支持。选型：侧重合规与许可证选 SPDX，侧重安全/漏洞/供应链与 DevOps 集成选 CycloneDX；多数企业两者都支持，按消费方需求输出。

SPDX 与 CycloneDX 各有侧重，选择取决于"合规优先"还是"安全供应链优先"，以及下游工具的消费格式。

• SPDX 核心对象
• document、package、license、relationship
• 工程应用

SPDX 2.3 是软件包数据交换规范，用于描述软件组成与许可证。核心对象：document（SPDX 文档，包容器与元数据）、package（软件包，含名称、版本、下载地址、checksum）、license（许可证信息，用 SPDX license ID 表达）、relationship（关系，描述 package 之间、package 与文件的依赖关系，如 DEPENDS_ON、CONTAINS）。工程应用：生成 SPDX SBOM 描述包与许可证，用于合规审计与漏洞关联，relationship 支撑依赖图的可视化与传递分析。

SPDX 的 document/package/license/relationship 结构能完整表达"包里有什么、什么许可、依赖谁"，是合规型 SBOM 的标准。

• SBOM 的核心应用
• 漏洞关联
• 合规应用

SBOM 的核心应用是供应链风险管理：漏洞关联（将 SBOM 中的组件版本与漏洞库比对，定位受影响制品，实现"一漏洞、全清单"的快速响应）、合规（许可证审计、NTIA 最小字段、供应链监管要求）、依赖可视化与溯源、采购评估。漏洞关联上，SBOM 提供结构化组件清单，SCA 工具直接消费实现扫描与告警；合规上，SBOM 是许可证与成分审计的机器可读依据。工程上 SBOM 随发布生成并归档，供持续消费。

SBOM 的价值在于"一份数据多场景复用"，漏洞关联与合规是两大核心消费场景，支撑供应链的可见性与响应。

• SBOM 防篡改
• 签名与制品绑定
• 溯源机制

SBOM 若被篡改或投毒，会导致漏洞/合规误判，因此需防篡改与溯源。手段：对 SBOM 进行数字签名（用发布者私钥签名，如 cosign、GPG），确保其未被篡改且来源可信；将 SBOM 与制品绑定发布（同签名、同发布流程，或用 attestation 把 SBOM 哈希与制品哈希绑定），使"清单-产物"可验证对应；通过签名的发布元数据（如 SLSA attestation、in-toto）记录生成者与生成过程，实现溯源。工程上在发布流水线生成、签名、归档 SBOM，消费方用公钥验证签名再使用。

SBOM 防篡改靠"签名绑来源 + 制品绑定防替换 + attestation 溯源"，三者结合防止清单被投毒，保证供应链数据可信。

• SBOM 门禁化
• 生成与校验纳入流水线
• 缺失/非法制品拦截

SBOM 门禁化指把 SBOM 的生成与校验作为发布流水线的强制步骤。流程：构建后自动生成 SBOM，校验其格式（如 CycloneDX/SPDX schema 校验）、字段完整性（NTIA 最小字段）、签名有效性；若 SBOM 缺失、格式非法或校验失败，则阻断发布（门禁）。落地通过 CI 工具（如 CycloneDX CLI 校验、Syft 生成、cosign 签名）串成流水线阶段，并设置门禁规则。这样保证每个发布制品都有合法、可信的 SBOM。

SBOM 门禁化把"供应链可见性"从可选变成强制，缺失或非法的 SBOM 直接拦截，从源头保证清单质量。

• creator 的含义
• 三种类型
• 工程应用

SPDX 的 creator 字段描述 SBOM 文档的创建者，用于溯源，有三种类型：Person（个人，如维护者）、Organization（组织，如公司或项目）、Tool（工具，如 Syft、CycloneDX CLI）。creator 反映"谁生成了这份清单"，是审计与可信度判断的依据（如工具生成 vs 人工维护）。工程上，生成的 SBOM 自动填充 creator 工具信息，发布时确认组织与工具正确，便于追溯生成来源与生成方式。

creator 元数据支撑 SBOM 的溯源与可信度，区分"自动工具生成"与"人工/组织声明"，是供应链审计的基础信息。

• license expression 概念
• 运算符（AND/OR/WITH）
• 工程应用

SPDX license expression 用标准化的表达式描述许可证，支持复合规则：AND（多个许可证同时适用）、OR（可选其一，如 Apache-2.0 OR MIT）、WITH（带例外，如 GPL-2.0-only WITH Classpath-exception-2.0）、括号分组。它解决了"一个组件可能受多许可证约束"的表达问题，也允许列出适用的许可证。工程上，SBOM 中组件用 license expression 精确描述许可，便于合规工具解析与判断兼容性。

license expression 是 SPDX 表达许可证的标准化语言，AND/OR/WITH 让"多许可、可选许可、例外"都能机器可读。

• relationship 类型
• DEPENDS_ON、CONTAINS
• 依赖图构建

SPDX 的 relationship 字段描述 package/document 之间的关系，常见类型：DEPENDS_ON（包依赖另一个包）、CONTAINS（包包含文件或子包）、DESCRIBES（文档描述某包）、BUILD_TOOL_OF 等。通过 relationship 可以把零散的组件连接成依赖图，展示直接与传递依赖、包与文件的关系，支撑依赖可视化、漏洞传递路径分析与许可证传递判断。工程上，SBOM 中的 relationship 让工具能重建完整依赖结构。

relationship 是 SBOM 从"清单"到"图"的关键，DEPENDS_ON/CONTAINS 等类型支撑依赖关系与传递分析。

• tag-value 格式
• JSON 格式
• 格式选型

SPDX 支持多种格式：tag-value（键值对行格式，SPDX 原生、简洁、适合人类阅读与简单解析）、JSON（结构化、易与工具和 CI 集成、适合机器消费）、RDF/XML（语义化、适合复杂查询）。选型：人类可读与简单场景选 tag-value；需要与 CI/工具/API 深度集成、机器消费选 JSON；需要语义/关联查询选 RDF/XML。工程上多数 CI 集成用 JSON，既结构化又轻量。

tag-value 简单人类可读，JSON 结构化机器友好，选型取决于"消费方是工具还是人"以及集成深度。

• verification code 概念
• 计算方式
• 验证用途

SPDX 的 verification code（验证码）用于验证包内文件集合的完整性：对包内所有文件的 SHA1 哈希排序后计算聚合哈希，得到 verification code。当文件集合变化（增删改），verification code 会改变，从而可用于检测包内容是否被篡改或与清单不一致。工程上，验证 SBOM 时重新计算包内文件的 verification code 并与 SBOM 记录比对，判断"清单与实物是否一致"，支撑溯源与防篡改。

verification code 是"包内文件清单"的指纹，用于检测 SBOM 描述与实际文件集是否一致，是防篡改的校验手段。

• 构建期生成的优势
• 更新机制
• 落地

SBOM 应在构建期生成：构建时依赖信息最准确、最完整，能与实际构建产物绑定，避免"源码清单"与"产物"不一致。构建期生成后，SBOM 随制品版本归档，并在每次发布时全量更新（而非增量），保证每个版本有对应清单。更新机制：依赖升级、构建配置变化时重新生成并覆盖，配合版本控制与签名。SCA 也可基于最新 SBOM 持续扫描。工程上把 SBOM 生成作为构建流水线的一步，与制品同步发布。

构建期生成 SBOM 能保证"清单与产物一致"，是准确性与可追溯性的最佳平衡，也是门禁化与防篡改的基础。

• SBOM 消费场景
• 供应链风险管理
• 落地

SBOM 的消费指下游系统读取 SBOM 用于风险管理：漏洞关联（SCA 工具消费 SBOM 扫描组件漏洞，漏洞公开时快速定位受影响产品）、许可证合规（审计许可证与分发义务）、依赖健康度（识别停止维护、弃用组件）、采购与供应商评估（评估引入软件的成分与风险）、事件响应（利用 SBOM 做资产清单快速响应）。工程上，建立 SBOM 消费管道（入库、解析、关联漏洞库、告警），并接入发布与告警系统，让 SBOM 成为持续风险管理的活数据。

SBOM 的价值在"消费"而非"生成"，通过漏洞关联、合规、依赖健康等消费场景把清单转化为风险决策。

• SBOM 层级
• 聚合与去重
• 完整供应链视图

SBOM 存在不同层级：应用级（应用依赖）、镜像级（容器镜像组件）、系统级（操作系统/平台组件）。聚合时需合并去重：因为镜像 SBOM 可能已包含应用组件，系统级 SBOM 可能包含镜像组件，直接拼接会重复。做法：按组件唯一标识（如 purl、SPDXID、包名+版本）去重，建立层级关系（应用 → 镜像 → 系统），用 relationship 表达嵌套，保留各层级的出处与属性。聚合后形成完整供应链视图，统一展示所有组件的漏洞与许可证。

多层级 SBOM 聚合需"按唯一标识去重 + 用关系表达层级"，才能得到无重复、可追溯的完整供应链视图。