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，如果以安全管理为主要目的则适合 CycloneDX。在实务中，同时生成两者并按用途区分使用的组织也在增加。

SBOM 的生成流程

自动生成工具

手动创建 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 而受到了影响。

漏洞公开时能否立即作答

漏洞公开之后，立刻需要的往往只是一个问题的答案：正在运行的自有软件中，是否包含该组件的相应版本。如果部件清单已保持在最新状态，回答这个问题就只是比对记录的工作。如果没有，就会变成逐一排查代码仓库和运行环境的调查，所需时间会随着待查对象的数量成比例增长。改变的不只是时间，还有结果的可信度。在人工排查中，「没有找到」并不能证明「不包含」，因此无法有根据地作出「不受影响」的判断。在无法区分需要处置的范围与不需要处置的范围时，往往只能对较大的范围采取预防性措施。此外，漏洞公开的时点并非由自己选择。若在公开之后才开始编制部件清单，编制本身的工作量就与人工调查相当，无法成为赶上时限的材料。平时就准备好可直接比对的状态，与公开之后暴露时间的长短是直接相关的。

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