📚 课程目录第1章 SBOM基础概念

1. SBOM 基础概念：什么是 SBOM、组成要素与供应链角色

各位同学好，我是老周。在物联网安全这个行当摸爬滚打了十几年，今天咱们来聊聊 SBOM——软件物料清单。说实话，我第一次接触这个概念是在 2018 年，当时帮一家智能家居厂商做安全审计，发现他们的固件里用了三十多个开源组件，但没人能说清楚到底用了哪些、版本是多少。嗯，那场面，相当混乱。

从那以后，我就养成了一个习惯：不管做什么物联网设备，先把 SBOM 理清楚。你想想看，连自己用了什么都不知道，怎么谈安全？

1.1 什么是 SBOM？

SBOM，全称 Software Bill of Materials，直译过来就是“软件物料清单”。说白了，它就像你买家电时附带的零件清单——告诉你这台设备里用了哪些软件组件、什么版本、从哪里来的、有没有已知漏洞。

我习惯把它比作“软件成分表”。就像食品包装上会列出配料和营养成分，SBOM 把设备的软件成分一五一十地列出来。没有它，你根本不知道吃进去的是什么。

核心定义：SBOM 是一份结构化、机器可读的清单，详细记录了软件产品中所有组件的名称、版本、供应商、依赖关系以及许可证信息。

为什么物联网设备特别需要 SBOM？因为物联网设备不像 PC 或服务器，它们通常资源受限、更新困难、生命周期长。我见过不少设备出厂时固件没问题，但三年后里面的开源库爆出高危漏洞，厂商却连哪个组件受影响都查不出来。这就是没有 SBOM 的代价。

1.2 SBOM 的组成要素

一份完整的 SBOM 应该包含哪些东西？我根据多年实战经验，把它归纳为六个核心要素。记住这六点，你就能看懂任何一份 SBOM。

要素	说明	示例
组件名称	软件组件的官方名称	OpenSSL, libcurl, busybox
版本号	精确到补丁级别的版本标识	1.1.1w, 7.88.1, 1.35.0
供应商	组件的作者或维护组织	OpenSSL Foundation, curl project
依赖关系	组件之间的上下游依赖	A → B → C（A 依赖 B，B 依赖 C）
许可证	开源许可证类型	Apache 2.0, GPL v3, MIT
哈希值	用于验证组件完整性的校验码	SHA-256: a3f5b2c8...

这里我要特别强调一下版本号。我曾经遇到过一个案例：某智能门锁的固件里用了 OpenSSL 1.0.2，但 SBOM 里写的是 1.0.2a。你可能会觉得差不多，但 1.0.2a 修复了 Heartbleed 漏洞，而 1.0.2 没有。就这一个字母的差别，整个设备的安全等级完全不同。所以，版本号必须精确到补丁级别，不能含糊。

我的习惯：在生成 SBOM 时，我会强制要求包含每个组件的 SHA-256 哈希值。这样即使版本号被人为篡改，也能通过哈希校验发现异常。这个做法帮我堵过好几次供应链攻击。

1.3 SBOM 的格式标准

光有内容还不够，还得有统一的格式。目前业界主流的 SBOM 格式有三种，我简单介绍一下：

SPDX（Software Package Data Exchange）：由 Linux 基金会维护，最成熟，支持许可证管理。我个人偏爱这种格式，因为它对合规审计特别友好。
CycloneDX：由 OWASP 推动，专为安全场景设计，支持漏洞关联。如果你做安全分析，这个格式更顺手。
SWID（Software Identification）：ISO 标准，主要用于软件资产管理。在物联网场景下用得相对少一些。

下面是一个 SPDX 格式的 SBOM 片段，展示了一个物联网设备固件中的部分组件：

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: smart-lock-firmware-v2.1

## Package: OpenSSL
PackageName: OpenSSL
SPDXID: SPDXRef-Package-OpenSSL
PackageVersion: 1.1.1w
PackageSupplier: Organization: OpenSSL Foundation
PackageChecksum: SHA256: a3f5b2c8d9e1f0a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5
PackageLicenseConcluded: Apache-2.0

## Package: libcurl
PackageName: libcurl
SPDXID: SPDXRef-Package-libcurl
PackageVersion: 7.88.1
PackageSupplier: Person: Daniel Stenberg
PackageChecksum: SHA256: b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3
PackageLicenseConcluded: MIT

你看，每一行都很清晰。组件名、版本、供应商、哈希值、许可证，一目了然。这就是 SBOM 的价值——让软件供应链变得透明。

1.4 SBOM 在软件供应链中的角色

聊完了 SBOM 是什么，咱们再来说说它在软件供应链里到底扮演什么角色。我用一张图来展示：

从这张图你能看到，SBOM 处于供应链的中间位置。上游是各种开源组件、第三方 SDK 和自研代码，下游是漏洞管理、许可证合规和身份认证等安全能力。SBOM 就像一根“数据总线”，把上下游串联起来。

具体来说，SBOM 在供应链中承担了三个关键角色：

透明度提供者：让厂商和用户清楚知道设备里装了什么软件。我在做设备安全评估时，第一步就是要求客户提供 SBOM。没有它，我根本没法做有效的安全分析。
漏洞响应加速器：当新的 CVE 公布时，SBOM 能帮你快速判断自己是否受影响。我曾经帮一家客户处理 Log4j 漏洞，他们有 SBOM 的团队 2 小时内就完成了影响评估，而没有 SBOM 的团队花了整整两周。
信任链锚点：在物联网设备身份认证中，SBOM 可以作为设备指纹的一部分。通过比对设备的实际组件与 SBOM 记录，可以检测固件是否被篡改。这个应用场景，我们后面几章会详细展开。

注意：SBOM 不是一次性的工作。物联网设备的固件会升级，组件会更新，依赖关系会变化。我建议把 SBOM 生成集成到 CI/CD 流水线中，每次构建都自动生成新的 SBOM。否则，你手里的 SBOM 很快就会变成一张废纸。

1.5 为什么物联网设备身份认证需要 SBOM？

这个问题可能你已经猜到了。简单说：没有 SBOM，你无法确认设备里跑的是什么软件，也就无法建立真正的信任。

物联网设备身份认证的核心是“证明我是我”。传统做法是给设备烧录一个证书或密钥，但这只能证明硬件没被换，证明不了软件没被篡改。如果攻击者替换了固件里的某个组件，设备依然能用证书通过认证，但实际已经在执行恶意代码了。

SBOM 的出现改变了这个局面。通过将 SBOM 的哈希值绑定到设备身份中，认证服务器可以验证设备当前的软件组成是否与出厂时一致。任何组件的增删改都会导致哈希值变化，从而被认证系统发现。

嗯，这个思路我在 2020 年帮一家车联网公司实现过。当时他们的 T-Box（车载通信终端）经常被刷机篡改，我们就是在身份认证协议里嵌入了 SBOM 校验，效果非常好。具体怎么实现，后面几章我会手把手带大家做。