1. SBOM 基础概念：从一份清单说起
大家好，我是你们这堂课的老朋友。今天咱们聊聊 SBOM——软件物料清单。说实话，我第一次接触这个词的时候，脑子里蹦出来的是“这跟超市购物清单有啥区别？”后来干得多了才发现，还真有点像。
SBOM，全称 Software Bill of Materials。说白了，就是把你软件里用了哪些组件、什么版本、从哪里来的，清清楚楚列出来。就像你买了个组装电脑，得知道 CPU 是 Intel 还是 AMD，内存是哪个牌子，对吧？软件也一样。
什么是 SBOM
SBOM 是一份结构化的清单。它记录了软件构建过程中使用的所有组件、库、依赖关系，以及它们的元数据。我习惯把它理解成“软件的 DNA 档案”。
举个例子。你开发一个 Web 应用，用了 Spring Boot、Log4j、Jackson 这些库。SBOM 就会告诉你：Spring Boot 版本是 2.6.3，Log4j 是 2.17.1，Jackson 是 2.13.0。而且它还会列出这些库之间的依赖关系——比如 Log4j 又依赖了哪些子组件。
核心要点：SBOM 不是一份简单的列表，它是可机读、可交换、可审计的标准化数据。格式上常见的有 SPDX 和 CycloneDX 两种。
我记得有一次帮客户做安全审计，对方说“我们软件很安全，没用什么第三方库”。结果我一扫，好家伙，光一个 npm 项目就引了 800 多个间接依赖。没有 SBOM，你根本不知道自己在用什么。
SBOM 的组成要素
一份完整的 SBOM，至少得包含下面这些要素。我列个表，大家看得更清楚：
| 要素 | 说明 | 示例 |
|---|---|---|
| 组件名称 | 组件的唯一标识 | log4j-core |
| 版本号 | 精确到 patch 版本 | 2.17.1 |
| 供应商 | 组件作者或组织 | Apache Software Foundation |
| 依赖关系 | 组件之间的依赖树 | log4j-core → log4j-api |
| 许可证 | 开源许可证类型 | Apache 2.0 |
| 哈希值 | 组件文件的校验和 | SHA256: a3f5b... |
| 来源信息 | 下载地址或仓库 URL | https://github.com/apache/logging-log4j2 |
嗯，这里要注意。版本号一定要精确。我曾经遇到过一家公司，SBOM 里只写了“log4j 2.x”，结果 Log4Shell 漏洞爆发时，他们根本不知道自己的 2.14.1 版本是不是受影响。你说这多危险？
SBOM 在供应链安全中的角色
现在软件供应链攻击越来越多。你想想看，一个恶意组件被植入到你的依赖里，你根本不知道。SBOM 就是帮你“看清”供应链的那双眼睛。
它的角色可以概括为三点：
- 可见性：让你知道软件里到底有什么。没有 SBOM，你的软件就是个黑盒子。
- 可追溯性：出了问题能追根溯源。比如发现某个漏洞，SBOM 能告诉你哪些组件受影响。
- 可审计性：合规检查、安全审计时，SBOM 是硬通货。没有它，审计师根本没法干活。
我的经验：在做设备身份安全审计时，SBOM 是第一步。没有它，后面所有的工作都是空中楼阁。我建议每个项目从第一天就开始维护 SBOM，别等到上线了再补。
下面这张图，是我自己画的一个 SBOM 在供应链安全中的核心逻辑。大家看看：
从这张图你能看到，SBOM 贯穿了软件从开发到部署再到审计的全过程。开发阶段用它做组件识别和依赖分析，部署阶段用它做版本校验和漏洞扫描，最后安全审计阶段，SBOM 就是你的“证据链”。
避坑指南：我曾经见过一个团队，SBOM 做得漂漂亮亮，但从来没更新过。项目上线半年后，依赖库都升级了好几轮，SBOM 还是老版本。这比没有 SBOM 更可怕——因为它给你一种虚假的安全感。记住，SBOM 是活的，不是一次性的。
好了，这一章的内容就到这里。SBOM 的概念其实不复杂，但它是整个供应链安全的基础。后面我们会一步步深入，看看怎么用 SBOM 来做设备身份的安全审计。你先把这些基础概念消化掉，后面就好办了。