1. SBOM基础概念

大家好，我是老周。在固件安全这个坑里摸爬滚打了十几年，今天咱们来聊聊 SBOM——软件物料清单。这玩意儿这几年特别火，但很多人其实没搞明白它到底能干啥。

说白了，SBOM 就是一份软件的「成分表」。就像食品包装袋上会列出用了哪些原料、添加剂一样，SBOM 会告诉你一个软件产品里用了哪些组件、什么版本、来自哪里。嗯，就是这么简单。

1.1 什么是 SBOM

SBOM 的全称是 Software Bill of Materials。我习惯把它理解成「软件供应链的身份证」。一份标准的 SBOM 至少包含以下信息：

• 组件名称——用了哪个开源库或商业组件
• 版本号——具体是哪个版本，比如 OpenSSL 1.1.1t
• 供应商——谁开发的这个组件
• 依赖关系——这个组件又依赖了哪些其他组件
• 许可证信息——GPL、MIT 还是 Apache 2.0
• 哈希值——用于校验组件完整性的指纹

举个例子。你买了一个智能路由器，里面跑的是 OpenWrt 系统。如果没有 SBOM，你根本不知道它用了哪个版本的 Linux 内核、哪个版本的 BusyBox、有没有打过安全补丁。有了 SBOM，这些信息一目了然。

1.2 SBOM 的起源与演进

SBOM 这个概念其实不新。我记得最早是在 2000 年代初，一些大型企业做软件资产管理时就开始用了。但真正让它火起来的，是 2021 年的 SolarWinds 供应链攻击事件。

那次事件之后，美国白宫发布了行政令，要求所有向联邦政府销售的软件必须提供 SBOM。嗯，政策一推，行业就动起来了。

SBOM 的演进大致经历了三个阶段：

阶段	时间	特点
萌芽期	2000s - 2015	企业内部自用，格式不统一，手工维护为主
标准化期	2015 - 2021	SPDX、CycloneDX 等标准出现，工具链开始成熟
强制化期	2021 至今	政策驱动，SBOM 成为软件供应链安全的标配

现在主流的 SBOM 格式有三种：SPDX、CycloneDX 和 SWID。我个人比较推荐 CycloneDX，它在安全领域支持得更全面，尤其是漏洞关联这块。

1.3 SBOM 的核心价值

你可能会问：搞这么复杂，到底图啥？我总结了四个核心价值：

1. 漏洞管理——知道用了什么，才能知道哪些组件有漏洞。CVE 出来之后，SBOM 能帮你快速定位受影响的产品。
2. 许可证合规——GPL 的代码不能混进商业固件里。SBOM 能自动检查许可证冲突。
3. 供应链透明度——你的供应商用了什么组件？他们的组件又依赖了什么？SBOM 能把这个链条理清楚。
4. 应急响应——Log4j 漏洞爆发时，有 SBOM 的企业几小时内就能排查完所有受影响系统。没有的？嗯，加班吧。

我在项目中遇到过一家做工业网关的客户。他们的固件里用了 200 多个开源组件，但没有任何记录。Log4j 漏洞出来后，他们花了整整两周才排查完。后来他们导入了 SBOM 流程，再遇到类似事件，半天就搞定了。

1.4 为什么固件需要 SBOM

这个问题我经常被问到。很多人觉得 SBOM 是给服务器软件用的，嵌入式固件没必要。其实恰恰相反——固件比普通软件更需要 SBOM。

为什么？原因有三：

• 固件更新困难——很多嵌入式设备部署在偏远地区，或者有严格的认证流程。固件一旦发布，想打补丁成本极高。所以必须在发布前就把组件风险搞清楚。
• 固件组件复杂——一个典型的 IoT 固件可能包含：Bootloader、Linux 内核、文件系统、各种驱动、第三方库、应用层代码。每个环节都可能引入漏洞。
• 固件供应链长——芯片厂商提供 BSP，ODM 厂商做硬件设计，软件团队写应用层，最后集成商打包发布。每个环节都可能被植入恶意代码。

所以我的观点很明确：固件安全，从 SBOM 开始。没有 SBOM，你连自己固件里有什么都不知道，谈何安全？

1.5 固件 SBOM 的知识体系

下面这张图是我自己整理的固件 SBOM 知识体系，帮你快速建立全局视角：

这张图把本章的知识点串起来了。你想想看，从定义到价值，再到为什么固件需要它，其实是一条逻辑链：先知道是什么，再了解怎么来的，然后明白有什么用，最后落到固件这个具体场景里。

好了，这一章就到这里。记住一句话：SBOM 不是锦上添花，而是雪中送炭。尤其是固件领域，没有 SBOM，你连自己手里有什么牌都不知道，怎么打？