SBOM

本文约需 2 分钟阅读

SBOM (Software Bill of Materials) 是指将构成软件的所有组件 (库、框架、依赖包等) 列成清单的「物料清单」。它把制造业中 BOM (物料清单) 的概念应用到软件上，以机器可读的格式记录使用了哪个版本的哪个库。以 2021 年供应链攻击的激增和 Log4Shell 事件为契机，作为确保软件透明性的手段而在全球范围内日益受到关注。

历史背景与立法

SBOM 的概念本身从 2010 年代前期就开始被讨论，但成为转折点的是 2021 年 5 月美国拜登总统签署的第 14028 号行政命令 (Executive Order 14028)。该行政命令规定，向联邦政府交付的软件必须提供 SBOM，在国家层面要求软件供应链的透明性。同年 12 月曝光的 Log4Shell (CVE-2021-44228) 戏剧性地证明了这一方针的正确性。全球各组织紧急调查「自己的系统是否包含 Log4j」，已建立 SBOM 的组织能在数小时内确定影响范围，而未建立的组织则花费了数周时间。

两大格式

SPDX (Software Package Data Exchange)

由 Linux Foundation 管理。已作为 ISO/IEC 5962:2021 实现国际标准化。在描述许可证信息方面具有优势，适合开源的合规管理。支持 JSON、RDF、Tag-Value 格式。

CycloneDX

由 OWASP 管理。专为安全用途而设计，易于与漏洞信息以及 VEX (Vulnerability Exploitability eXchange) 集成。支持 JSON、XML、Protocol Buffers 格式。

选择哪一种取决于用途。如果以许可证合规为主要目的则适合 SPDX，如果以安全管理为主要目的则适合 CycloneDX。在实务中，同时生成两者并按用途区分使用的组织也在增加。

SBOM 的生成流程

源代码 / 容器镜像

用 Syft / Trivy 解析

输出 SPDX / CycloneDX

与漏洞数据库比对

风险判定与应对

自动生成工具

手动创建 SBOM 是不现实的。现代软件拥有数百到数千个依赖关系，因此利用自动生成工具成为前提。作为代表性工具，Anchore 公司的 Syft 能够从容器镜像和文件系统两方面生成 SBOM，且易于集成到 CI/CD 流水线中。Aqua Security 的 Trivy 能用一个工具同时执行漏洞扫描和 SBOM 生成，并可一气呵成地完成与CVE 数据库的比对。GitHub 的 Dependency Graph 和 GitLab 的 Dependency Scanning 也内置了 SBOM 生成功能，可按仓库单位进行管理。

常见误解

存在「制作了 SBOM 就安全」的误解，但 SBOM 终究只是用于可视化的工具，其本身并不会提升安全性。重要的是持续更新 SBOM，与新公开的漏洞进行比对，并连接到补丁管理的运维流程。此外，SBOM 不仅需要包含直接依赖关系，还需要包含传递依赖 (所依赖对象进一步依赖的库)。在 Log4Shell 的案例中，许多组织即使没有直接使用 Log4j，也因为所使用的框架在内部依赖 Log4j 而受到了影响。

现场使用案例

“Log4Shell 公开后的第二天早上，已建立 SBOM 的我们团队在 2 小时内确定了受影响的 12 个服务，并在上午完成了所有补丁应用。而未建立 SBOM 的部门则花了 2 周时间进行手动调查，在此期间一直暴露于风险之中。”

供应链安全的整体概貌在供应链攻击的文章中有详细讲解，开源软件的安全使用方法在开源安全审计的文章中进行了说明。在构建组织的安全基础方面，初创公司安全检查清单也很有参考价值。软件供应链安全相关书籍 (Amazon)也对实务有帮助。