1. 概述
现代软件都是组装的而非纯自研。随着开源组件在数字化应用中的使用比例越来越高，混源开发已成为当前业内主流开发方式。开源组件的引入虽然加快了软件开发效率，但同时将开源安全问题引入了整个软件供应链。软件组成成分的透明性成为软件供应链安全保障的基础，SBOM（Software Bill of Materials，软件物料清单）作为软件供应链安全治理的重要抓手，其在行业的应用实践速度明显加快。
2. 软件供应链安全治理
2.1 供应链安全概述
供应链（Supply Chain）指生产及流通过程中，涉及将产品或服务提供给最终用户活动的上游与下游企业所形成的网链结构，即将产品从商家送到消费者手中整个链条。供应链的活动是指将自然原材料不断组装成消费者需要的成品的过程，描绘了产品供给关系。整个供应链系统涉及到人员、组织、材料、数据等。
软件供应链的定义由传统供应链概念扩展而来，指软件生命周期中从需求、设计、开发、构建、打包、发布、采购、部署、运维、下线到销毁整个链路，通常涉及软件生产者（供应商/上游）、软件使用者（消费者/下游）以及软件运营者（公司或者企业）三个方面。
软件供应链安全则是和针对软件供应链的攻击有关。攻击者通过网络工具、下载投毒、代码污染、漏洞利用、授权流氓等手段在软件供应链各个活动环节中，对企业业务系统进行破坏性操作。近几年比较严重的软件供应链安全事件有SolarWinds（太阳风暴）攻击、Realtek WiFi SDK漏洞、Apache Log4j2漏洞等。
2.2 风险治理重点
软件供应链过程风险治理，主要包括软件来源管理、软件安全合规性管理、软件资产管理、服务支持及安全应急响应，目的是提升软件供应链可追溯性和透视性。其中重点的治理内容，包括软件资产的第三方组件威胁审查、软件安全合规性管理。
为了帮助企业有效解决软件供应链安全问题，SBOM作为软件供应链安全关键的技术工具之一，能够达到统一描绘软件资产信息格式、协助对采购软件和自研软件风险评估、形成软件供应链活动中传递的软件信息接口标准。
3. SBOM介绍
SBOM（Software Bill of Materials） 是软件成分的结构化清单，详细记录应用程序中包含的所有组件、库及其依赖关系，包括组件名称、版本、许可证、供应商信息和依赖层级。类比于制造业的“物料清单”，SBOM旨在提升软件供应链透明度，解决开源与第三方组件引发的安全与合规风险。
核心价值体现：
- 供应链可见性：97%的代码库含开源组件，81%存在已知漏洞，SBOM可快速定位风险组件。
- 漏洞响应加速：结合漏洞数据库（如NVD），识别受影响组件并优先修复，缩短暴露窗口期（如Log4Shell事件）。
- 许可证合规：避免法律风险，如GPL传染性条款可能导致的商业纠纷。
- 软件质量优化：识别过时组件（85%代码库含4年未更新的开源库），推动升级维护。
4. SBOM最小集定义
美国国家电信和信息管理局(National Telecommunications and Information Administration)发布SBOM最小集的定义： 数据字段是关于必须捕获和维护每个组件的基础数据，以便在整个软件供应链中跟踪组件，并基于此扩展License和漏洞库等其他数据字段。
| 数据字段 | 描述 |
|---|---|
| 供应商名称 | 创建、定义和标识组件的实体的名称。 |
| 组件名称 | 分配给原始供应商定义的软件单元的名称。 |
| 组件的版本 | 组件版本号、供应商用来指定软件从先前标识的版本发生变化的标识符。 |
| 其它唯一标识符 | 用于标识组件或用作相关数据库的查找键的其他标识符。 |
| 依赖关系 | 软件依赖关系、表征上游组件 X 包含在软件 Y 中的关系 |
| SBOM数据的作者 | 为此组件创建SBOM数据的实体的名称。 |
| 时间戳 | 记录SBOM数据组装的日期和时间。 |
| 推荐的数据 | |
| 组件的哈希 | 组件的唯一哈希，以帮助允许列表或拒绝列表。 |
| 生命周期阶段 | SDLC 中捕获 SBOM 数据的获取的阶段。 |
5. SBOM的格式
目前SBOM主要通过三种格式来进行实施：
5.1 SPDX（Linux 基金会标准）
SPDX是一种国际开放标准（ISO/IEC 5962:2021）格式，包含与软件包相关的组件、许可证、版权和安全参考信息。SPDX标准由Linux基金会主办的草根开源项目开发，目前维护到最新2.3版本，特点是对许可证的详细信息支持较好，主要输出文件格式包括RDF、XLS、SPDX、YAML、JSON。
特点：机器可读，支持嵌套依赖关系。
适用场景：大型企业、复杂供应链管理。
5.2 CycloneDX（OWASP 主导）
CycloneDX专为安全环境和供应链组件分析而构建，是一种轻量级SBOM标准，可用于应用程序安全上下文和供应链组件分析。CycloneDX源于OWASP社区的开源项目，由提供战略方向和标准维护的核心团队指导。目前最新维护到1.4版本，可扩展格式并集成SPDX许可证ID、pURL和其他外部标识符，主要输出格式包括XML、JSON。
特点：轻量化，专注安全风险。
适用场景：DevOps集成、开源项目审计。
5.3 SWID（ISO 标准）
SWID是一个标准化的XML格式，可以识别软件产品的组成部分并将其与上下文结合，记录有关软件组件的唯一信息，如产品名称、版本详细信息等。SWID标签在SDLC发布后添加作为软件产品的一部分，在软件安装时将标签信息添加到系统终端，并在产品卸载后自动删除。
特点：嵌入式元数据，适合二进制文件。
- 适用场景：国内企业实战化应用。
6.SBOM的实施流程与技术工具栈
6.1 生成阶段
(1)自动化工具集成CI/CD：
- Syft：开源CLI工具，扫描容器/代码库生成CycloneDX或SPDX格式SBOM。
- Microsoft sbom-tool：企业级工具，支持SPDX 2.2，集成Azure DevOps。
(2)签名验证：
使用非对称加密签名SBOM文件（如CycloneDX CLI），确保未被篡改。
示例（通过Syft为nginx镜像生成sbom文件）：
1 2 3 4 5 6 7 8 |
|
6.2 开源存储与管理平台(OWASP Dependency-Track)
开源SBOM分析平台，支持API集成，可视化漏洞影响（下图为其架构）：
7. 政策合规与国际实践
(1)美国：强制性要求
EO 14028行政令：联邦采购软件需提供SBOM，CISA制定后续指南。
NTIA最低要素：明确数据字段、格式与实践规范。
(2)亚太地区进展
日本：经济产业省（METI）发布《SBOM导入指南》，分三阶段实施（环境搭建→生成→管理）。
澳大利亚：网络安全中心（ACSC）要求厂商提供SBOM，纳入“安全设计”原则。
(3)行业标准延伸
SAFECode：发布《SBOM推荐实践》，强调风险评分与生命周期管理。
ISO/IEC 27001:2022：将SBOM纳入软件供应链安全控制项（A.8.31）。