一、什么是供应链安全 SBOM
SBOM（Software Bill of Materials，软件物料清单）是记录软件中所使用组件、依赖、版本、来源与许可等信息的结构化清单，被誉为「软件供应链的成分表」。它是软件供应链安全的核心基础设施，让企业能够快速识别受影响范围、追溯漏洞来源。在 Log4j（2021）、SolarWinds（2020）等重大软件供应链事件之后，SBOM 已成为全球监管与企业普遍采纳的安全治理工具，与 SCA、SLSA、Sigstore 等机制共同构成软件供应链安全的事实体系。SBOM 的核心价值是把「软件由什么组成」从隐性知识变为显性数据，让漏洞响应从天级缩短到小时级。
二、原理
1. 组件识别：在构建阶段通过 SCA 扫描制品，提取直接依赖与传递依赖的包名、版本、哈希 → 2. SBOM 生成：按 SPDX/CycloneDX 等标准格式输出结构化清单 → 3. 漏洞关联：将 SBOM 与 CVE、VEX 数据库匹配，自动识别受影响组件与可利用性 → 4. 签名与溯源：用 Sigstore/SLSA Provenance 等签名机制验证组件来源与构建过程可信 → 5. 持续监控：在 CI/CD 与运行时持续观察新增漏洞、许可证变更、组件过期 → 6. 响应处置：发现漏洞后快速定位影响范围，按 VEX 判定处置优先级并触发修复
三、信息卡片
| 中文名 | 供应链安全 SBOM |
| 英文名 | Software Bill of Materials |
| 缩写 | SBOM |
| 别名 | 软件物料清单、软件成分表、Software Supply Chain Security |
| 提出者 | 标准化推动：美国 NTIA（2018）、Linux Foundation、CycloneDX 项目（OWASP）、SPDX 项目（Linux Foundation） |
| 提出时间 | 2018 年（NTIA 启动 SBOM 标准化）；2021 年（美国 EO 14028 强制要求） |
| 所属类别 | 网络安全 > 应用安全 > 软件供应链安全 |
| 核心技术 | SBOM 格式（SPDX、CycloneDX、SWID）、SCA 工具、VEX 漏洞利用声明、签名验证（Sigstore/Cosign） |
| 主要应用 | 漏洞响应、合规披露、供应商治理、软件采购审计、DevSecOps 流水线集成 |
四、历史时间线
- 2018 年：美国 NTIA 启动 SBOM 标准化工作，发布多份框架文件
- 2019-2020 年：SPDX（Linux Foundation）与 CycloneDX（OWASP）成为主流 SBOM 格式标准
- 2020 年 12 月：SolarWinds 供应链攻击事件震动业界，凸显 SBOM 必要性
- 2021 年 5 月：美国总统签署行政令 EO 14028，要求联邦供应商提供 SBOM
- 2021 年 12 月：Log4Shell 漏洞（Log4j）爆发，SBOM 被证明是漏洞快速响应的关键
- 2023-2024 年：SBOM 与 SCA、SLSA、Sigstore 在 DevSecOps 流水线中深度融合，成为软件供应链安全事实标准
五、分类
按格式标准：SPDX（Linux Foundation）、CycloneDX（OWASP）、SWID（ISO/IEC 19770-2）
- 按生成阶段：构建时 SBOM vs 发布时 SBOM vs 运行时 SBOM
- 按覆盖范围：直接依赖 SBOM vs 全量依赖 SBOM（含传递依赖）vs 二进制 SBOM
- 按用途：漏洞响应型 SBOM、合规披露型 SBOM、供应链审计型 SBOM、许可管理型 SBOM
- 按生态工具：Syft、Trivy、Grype、CycloneDX CLI、SPDX Tools、Microsoft SBOM Tool
六、应用场景
- 漏洞快速响应：典型漏洞披露后，企业通过 SBOM 在小时内识别所有受影响组件与制品
- 监管合规披露：满足美国 EO 14028、欧盟 NIS2、医疗 FDA 等合规披露要求
- 供应商与采购治理：在软件采购合同中要求供应商提供 SBOM，作为供应商准入条件
- DevSecOps 流水线集成：在 CI/CD 中自动生成 SBOM、自动签名、自动阻断含已知漏洞组件
- 软件供应链审计：成为软件供应链审计与第三方安全评估的事实依据
七、优缺点
优点：漏洞响应提速：典型漏洞披露后，受影响组件识别从天级缩短至小时级；支撑合规披露：满足美国 EO 14028、欧盟 NIS2 等多国法规的 SBOM 强制披露；降低供应链风险：透明识别风险来源、传递依赖与许可证冲突；可机器消费：SPDX/CycloneDX 格式可被 SCA、SIEM 等系统自动处理
- 缺点：格式未完全统一：SPDX 与 CycloneDX 在字段、语义上存在差异，企业需做映射；运行时可见性弱：构建时 SBOM 无法覆盖运行时动态加载的依赖；隐私与泄露担忧：过度详细的 SBOM 可能暴露企业内部组件信息；生态治理不成熟：传递依赖深度可达 100+ 层，质量与维护性治理仍困难
八、常见误区
- SBOM = 软件成分分析（错：SBOM 是产物（清单），SCA 是生成与分析 SBOM 的过程）
- 有了 SBOM 就安全了（错：SBOM 只是清单，必须配合漏洞库、签名验证、运行时检测）
- SBOM 只是合规要求（错：SBOM 的核心价值是漏洞响应与供应链治理）
- SBOM 是大企业才需要（错：任何使用第三方开源组件的项目都需要 SBOM）
九、关联概念
- 父概念：DevSecOps、API安全、CI/CD · 持续集成与持续交付
- 子概念：DevSecOps、CI/CD · 持续集成与持续交付、云原生
- 兄弟概念：DevSecOps、API安全、零信任 Zero Trust、ATT&CK 框架、红蓝对抗
- 对比概念：DevSecOps、API安全、渗透测试 Penetration Testing，Pentest
- 应用相关：DevSecOps、CI/CD · 持续集成与持续交付、云原生、API安全、零信任 Zero Trust
