4、SBOM在固件安全中的应用：固件成分分析、已知漏洞关联、供应链风险识别
固件安全，说白了就是设备的第一道防线。我做了这么多年嵌入式安全，见过太多设备因为固件里的“小问题”被攻破。今天咱们就聊聊，SBOM 怎么帮我们把固件安全这件事做扎实。
你想想看，一个现代固件里有多少第三方库？RTOS、TCP/IP 协议栈、加密库、文件系统……少说几十个，多则上百。没有 SBOM，你根本不知道里面装了什么。这就像你买了一台二手车，却不知道发动机里换了什么零件——你敢开吗？
固件成分分析：把黑盒变成白盒
固件成分分析，就是给固件做一次彻底的“人口普查”。我习惯把它分成三个步骤：
- 二进制拆解：把固件镜像解包，识别文件系统、分区结构
- 组件识别：通过特征签名、哈希比对，找出每个组件的名称和版本
- 依赖关系梳理：理清组件之间的调用关系、版本约束
举个例子，我曾经处理过一个智能网关的固件。解包后发现里面用了 OpenSSL 1.0.2a，但厂商自己都不知道。为什么？因为 SDK 里自带的，开发人员直接拿来用了。这就是没有 SBOM 的典型后果。
核心要点：固件成分分析不是一次性的。每次固件更新，成分都会变。我建议把 SBOM 生成集成到 CI/CD 流水线里，每次构建自动生成一份新的。
这里有个常用的分析流程，我画了张图：
已知漏洞关联：SBOM 的灵魂所在
有了 SBOM，下一步就是关联已知漏洞。这一步才是 SBOM 真正发挥价值的地方。我见过太多团队，SBOM 生成了一堆，但从来不去查漏洞——那还不如不做。
具体怎么做？说白了就是三步：
- 获取 CVE 数据：从 NVD、GitHub Advisory Database 等源拉取最新漏洞信息
- 版本匹配：把 SBOM 里的组件版本和 CVE 影响版本范围做比对
- 风险评估：根据 CVSS 分数、攻击向量、设备暴露面，判断实际风险
注意：版本匹配不是简单的字符串比较。我曾经遇到过一个案例，某个库的版本号是 2.1.3，但 CVE 影响的是 2.1.x 系列。如果只做精确匹配，就会漏掉这个漏洞。所以一定要用“版本范围”做匹配，而不是“精确版本”。
这里我列一个常见的漏洞关联结果示例：
| 组件 | 版本 | CVE 编号 | CVSS 评分 | 影响 |
|---|---|---|---|---|
| OpenSSL | 1.0.2a | CVE-2014-0160 | 7.5 (High) | Heartbleed 漏洞，可泄露内存 |
| BusyBox | 1.30.0 | CVE-2021-28831 | 9.8 (Critical) | 远程代码执行 |
| Dropbear SSH | 2019.78 | CVE-2021-36369 | 7.1 (High) | 中间人攻击 |
我的经验：不要只看 CVSS 分数。一个 9.8 分的漏洞，如果攻击者需要物理接触设备才能利用，那实际风险可能比一个 6.5 分的远程利用漏洞要低。一定要结合设备的使用场景做判断。
供应链风险识别：从源头堵住漏洞
供应链风险，是这几年最头疼的问题。你想想看，一个固件里可能用了来自 20 家不同供应商的组件。其中任何一家出了问题，你的设备就跟着遭殃。
我习惯把供应链风险分成三类：
- 许可证风险：用了 GPL 的库，你的固件可能被迫开源
- 维护风险：组件已经停止维护，新漏洞没人修
- 来源风险：组件来自不可信的源，可能被植入后门
嗯，这里要特别说一下来源风险。我曾经接手过一个项目，固件里有个加密库是从某个论坛下载的。后来一查，那个库被人篡改过，加了一个硬编码的后门密钥。如果没有 SBOM，这种问题根本发现不了。
怎么识别供应链风险？我建议从这几个维度入手：
- 组件来源审计：每个组件从哪里来的？官方仓库还是第三方镜像？
- 维护状态检查：最后一次更新是什么时候？有没有安全公告？
- 依赖深度分析：组件本身又依赖了什么？有没有传递性风险？
- 许可证兼容性：所有组件的许可证是否与项目目标一致？
避坑指南：我曾经遇到过一个团队，他们只检查了直接依赖的许可证，忽略了间接依赖。结果一个 GPL 的库通过三层依赖被引入，差点导致整个产品被迫开源。所以，一定要做完整的依赖树分析。
最后，我想说一句：SBOM 不是终点，而是起点。有了 SBOM，你才能做成分分析、漏洞关联、风险识别。但更重要的是，你要把这些信息用起来——定期扫描、及时修复、持续监控。这才是 SBOM 在固件安全中的真正价值。