01 · 为什么需要SBOM：从“找不到”到“查得准”
SBOM（Software Bill of Materials，软件物料清单）回答一个朴素但致命的问题：“这个软件里到底有什么？”在没有成分清单的时代，一次Log4Shell级别的组件漏洞意味着组织只能在恐慌中全文搜索依赖树；而持有准确SBOM的组织可以分钟级定位受影响制品、按暴露面排序修复。NTIA在2021年7月12日发布的《The Minimum Elements For a Software Bill of Materials》将SBOM的价值场景归纳为四类：
- 漏洞响应：给定组件名+版本，秒级反查受影响制品与版本（Log4Shell应急的行业共识做法）；
- 许可合规：识别GPL等传染性许可证成分，避免知识产权风险；
- 采购决策：以成分为基础评估供应商交付物的透明度与维护质量；
- 政策合规：满足美国EO 14028联邦采购要求、欧盟CRA义务及中国GB/T 43698-2024的过程性要求。
核心认知：SBOM不是一次性“填表产物”，而是与制品同生命周期的动态伴随数据——每次构建重新生成、随发布分发给下游、并支持机器自动消费。NTIA最低要素明确将“随构建生成、与制品关联分发”列为实践要求；静态手绘SBOM在依赖更新后立即失真，属于反模式。
02 · 两大格式规范深度对比：SPDX 与 CycloneDX
2.1 规范谱系
| 维度 | SPDX | CycloneDX |
|---|---|---|
| 治理方 | Linux基金会SPDX项目；ISO/IEC 5962:2021采纳为国际标准；SPDX 3.0于2024年4月发布 | OWASP基金会项目；v1.6于2024年6月被ECMA国际采纳为ECMA-424标准，v1.7于2025年10月发布、2025年12月被采纳为ECMA-424第2版 |
| 设计重心 | 许可证与知识产权合规见长，同时覆盖组件与文件级信息，向后兼容其2.x系列 | 安全与供应链场景见长，原生支持VEX、服务（SaaSBOM）、制造（ML/硬件）等扩展模型 |
| 序列化 | JSON、YAML、RDF/XML、tag-value（.spdx）、spreadsheet（xlsx，2.x） | JSON、XML、Protocol Buffers |
| 粒度 | 文档—包—文件—片段（snippet）四级 | 组件—服务两级，依赖关系以graph表达 |
| 生态工具 | SPDX工具（Java）、spdx-sbom-generator、ORT（OSS Review Toolkit） | cdxgen、Trivy、OWASP Dependency-Track（消费端旗舰） |
| 典型场景 | 跨企业许可证审计、法规要求的组件披露 | 漏洞影响面分析、K8s集群SBOM、VEX管道、SaaSBOM |
2.2 NTIA最低要素（2021年7月12日发布）
NTIA最低要素是美国EO 14028要求的操作性落地，分三大部分：
| 部分 | 要素 | 说明 |
|---|---|---|
| Data Fields 数据字段 | 供应商名称、组件名称、组件版本、唯一标识符（如PURL）、依赖关系、SBOM作者与时间戳 | “最小可回答成分问题”的字段集合；PURL（Package URL）作为跨生态统一标识 |
| Automation Support 自动化支持 | 机器可读格式（SPDX/CycloneDX/SWID）、数据格式一致性、可验证的完整性 | 保证工具链可互操作、可自动比对 |
| Practices and Processes 实践与流程 | 频率（新构建即生成）、深度（组件级起步）、已知未知项标注、分发与交付（随制品）、访问控制与容错 | 明确“谁、何时、如何生成与分发”的运营规则 |
注：SPDX与CycloneDX均完整覆盖NTIA最低要素，行业主流实践为“双格式并行”或按消费方要求转换；SWID（ISO/IEC 19770-2）在终端资产管理场景仍广泛使用，与SBOM互补而非替代。
03 · VEX：把“漏洞清单”变成“行动清单”
SBOM解决了“有什么”，VEX（Vulnerability Exploitability eXchange）解决“哪个真的需要修”。传统扫描对含上千组件的制品报出数百条CVE，其中绝大多数在特定配置下不可利用或不存在于制品中（如仅测试依赖引入、代码路径不可达）。VEX以机器可读声明告知消费方：
- NOT_AFFECTED：该组件存在于制品但漏洞不可利用（附理由：不可达代码/缓解措施）；
- AFFECTED：存在影响，附修复动作建议；
- FIXED：已通过更新修复；
- UNDER_INVESTIGATION：评估中。
| VEX载体 | 维护方 | 特点 |
|---|---|---|
| CycloneDX VEX | OWASP | 与CycloneDX SBOM同文档内嵌，支持analysis状态机与justification理由码 |
| OpenVEX | OpenSSF生态 | 极简独立格式，便于轻量生成器嵌入 |
| CSAF（VEX Profile） | OASIS标准（ISO/IEC 29147配套的CSAF 2.0） | 供应商安全公告的机器可读标准化载体，适合厂商向客户批量发布 |
| OSV Schema | Google OSV.dev | 以“漏洞为中心”的开源格式，OpenSSF漏洞情报交换的事实底座之一 |
实践要点：VEX声明必须由具备评估责任的主体（上游厂商、安全团队或可信评估服务）签名发布，消费侧（如Dependency-Track、Grype）按签名验证后再采纳；未经验证的“自查无影响”声明不可作为豁免依据——这与其证明（attestation）属性一脉相承（见第5页签名体系）。
04 · 生成工具链与流水线集成
4.1 生成端：从制品反推成分（后置式生成）
| 工具 | 出品方/生态 | 输入对象 | 输出格式 |
|---|---|---|---|
| Syft | Anchore（开源） | 容器镜像、文件系统、压缩包、语言依赖 | SPDX / CycloneDX / Syft JSON |
| cdxgen | OWASP CycloneDX官方生成器 | 多语言项目目录、容器、云环境 | CycloneDX（JSON/XML） |
| Trivy | Aqua（开源） | 镜像/文件系统扫描，兼SBOM生成 | CycloneDX / SPDX / SPDX-JSON |
| ORT（OSS Review Toolkit） | Linux基金会/SPDX生态 | 构建级依赖解析+许可审计 | SPDX为主，结论报告+评估 |
注：镜像类生成器依赖包管理器元数据，对distroless镜像（无shell、无包数据库）与静态编译二进制覆盖率有限——这是“生成器覆盖度”需要显式评估的已知局限，而非工具缺陷。
4.2 消费端：查询、比对与持续监测
- OWASP Dependency-Track：以CycloneDX SBOM为输入的持续漏洞监测平台，支持VEX消费、策略引擎与多项目组合视图，是开源消费端事实标准；
- GUAC（Graph for Understanding Artifact Composition）：Google主导的图谱化方案，将SBOM、provenance、VEX、签名证明统一为知识图谱，支撑跨供应链关系推理（OpenSSF项目，2022年10月预览发布）；
- Grype + Syft：与OSV/GitHub Advisory等漏洞源联动的轻量扫描消费链，支持VEX过滤降低误报；
- 云厂商集成：AWS S3/ECR、Azure、GCP及国内阿里云ACR、华为云SWR均提供镜像扫描与SBOM导出能力，可作为存量环境的第一落点。
4.3 流水线集成范式
05 · 中国国家标准与实践要求
| 标准 | 关键要求（与本页相关） |
|---|---|
| GB/T 43698-2024《网络安全技术 软件供应链安全要求》 2024-04-25发布，2024-11-01实施；中国信息安全测评中心牵头制定 | 规定软件供应链各环节（开发、交付、使用）的安全要求，包括软件成分识别、供应商管理与供应链安全风险处置，为组织建立SBOM能力提供国标依据 |
| GB/T 43848-2024《网络安全技术 软件产品开源代码安全评价方法》 2024-04-25发布，2024-11-01实施 | 给出开源代码安全评价指标体系，成分清单（开源代码识别）为评价输入，与SBOM数据直接衔接 |
| GB/T 36637-2018《信息安全技术 ICT供应链安全风险管理指南》 2019-05-01实施 | ICT供应链风险管理过程框架，SBOM属其中“供应链资产与成分可见性”的技术落地手段 |
| TC260相关实践指南 | 全国网络安全标准化技术委员会持续发布软件供应链与SBOM构建应用方向的实践指南类文件，作为标准落地操作参照（以TC260官网最新版本为准） |
合规提示：GB/T 43698-2024已于2024年11月1日实施，涉及关基运营者、重点行业软件采购与自研软件发布的组织，应评估其供应链安全要求与自身SBOM/成分管理能力的差距；SBOM数据本身可能包含实现细节，其对内对外的分发范围与留存应纳入数据安全管理。
06 · 常见误区与质量检查清单
| 误区 | 质量检查清单（上线前必查） |
|---|---|
| “SBOM=依赖锁文件” | 锁文件（package-lock等）只覆盖直接依赖树且带生态局限；SBOM需覆盖全成分（含OS层）并携带PURL等跨生态标识——用锁文件代替SBOM会导致跨语言与OS成分不可见 |
| “生成器输出即权威” | 抽样核对：对关键镜像用两种生成器交叉比对成分清单，差异率超阈值时人工核查包管理器元数据完整性 |
| “SBOM里不能有漏洞信息” | SBOM可含（CycloneDX vulnerabilities字段）但不必须；漏洞状态由VEX独立声明并单独签名，与成分清单解耦更利于维护 |
| “给采购方一份Excel就算交付” | NTIA最低要素要求机器可读格式+自动化支持；Excel仅作人类阅读附件，正式交付物应为SPDX/CycloneDX机器可读文件并随版本更新 |
本节参考来源（第3页）
NTIA《The Minimum Elements For a Software Bill of Materials (SBOM)》（2021年7月12日）：ntia.gov。
SPDX规范（ISO/IEC 5962:2021）官方站点：spdx.dev。
OWASP CycloneDX规范与ECMA-424标准信息：cyclonedx.org、ecma-international.org。
OASIS CSAF 2.0标准（含VEX profile）：docs.oasis-open.org/csaf；OpenVEX：openvex.dev。
OWASP Dependency-Track文档：docs.dependencytrack.org；GUAC项目：guac.sh。
Anchore Syft、Aqua Trivy、OWASP cdxgen官方文档：github.com/anchore/syft、trivy.dev、github.com/CycloneDX/cdxgen。
GB/T 43698-2024、GB/T 43848-2024、GB/T 36637-2018——国家标准全文公开系统：openstd.samr.gov.cn。
SWID标准（ISO/IEC 19770-2）与PURL规范：iso.org、github.com/package-url/purl-spec。