2. 固件供应链安全现状
大家好，我是老周。今天咱们聊聊固件供应链的安全现状。说实话，这个领域我摸爬滚打了十几年，踩过的坑比走过的路还多。固件供应链的复杂程度，远超大多数人的想象。
你想想看，一个现代设备的固件，可能来自十几个不同的供应商。芯片厂商提供底层驱动，开源社区贡献协议栈，第三方库处理加密算法，ODM/OEM负责集成打包。这中间任何一环出问题，整个设备就变成了定时炸弹。
固件供应链的复杂性
我习惯把固件供应链比作一个洋葱。你剥开一层，还有一层。每一层都有不同的参与者、不同的代码来源、不同的交付方式。
- 芯片级：SoC厂商提供Boot ROM、安全启动代码、硬件抽象层。这部分通常是闭源的，你拿不到源码，只能信任厂商的二进制文件。
- 板级支持包：BSP包含内核驱动、设备树、初始化脚本。不同厂商的BSP质量参差不齐，我见过直接把调试接口留在生产固件里的案例。
- 开源组件：U-Boot、Linux内核、OpenSSL、BusyBox……这些是固件的基石。但开源不等于安全，Log4j事件就是最好的反面教材。
- 第三方库：加密库、协议栈、文件系统。很多库已经停止维护，但厂商还在用。
- 自研代码：业务逻辑、管理接口、OTA升级模块。这部分往往是漏洞的高发区。
关键洞察：固件供应链的每个环节都可能引入漏洞。你无法控制所有环节，但你可以通过SBOM来管理它们。
我在一次物联网设备审计中遇到过这样的情况：设备用了五年前的OpenSSL版本，厂商说他们只改了配置没改代码。结果呢？Heartbleed漏洞直接可用。这就是供应链管理失控的典型表现。
常见固件安全威胁
固件安全威胁，说白了就是攻击者怎么搞你的设备。我总结了几类最常见的，你看看你的设备中了几枪。
| 威胁类型 | 攻击方式 | 典型案例 |
|---|---|---|
| 固件逆向 | 提取固件镜像，反汇编分析，寻找硬编码密钥或后门 | 路由器固件泄露WiFi密码 |
| 固件篡改 | 修改固件中的代码或配置，植入恶意功能 | 摄像头固件被植入挖矿程序 |
| 供应链投毒 | 在开发或构建阶段注入恶意代码 | SolarWinds事件（虽然主要是软件，但固件同理） |
| 已知漏洞利用 | 利用未修复的CVE漏洞进行攻击 | Log4j、Heartbleed、Dirty Pipe |
| 后门/硬编码凭证 | 厂商留下的调试接口或默认密码 | 某品牌NAS设备存在硬编码root账户 |
嗯，这里要注意。固件逆向这个威胁，很多人觉得离自己很远。我曾经帮一家做智能门锁的厂商做安全评估，他们信誓旦旦说固件加了壳，没人能逆向。结果我用binwalk一把梭，直接解出了文件系统，里面还有硬编码的管理员密码。所以啊，别太自信。
Log4j事件对固件的影响
2021年底的Log4j漏洞（CVE-2021-44228），圈内人都知道。但很多人以为这只是Java应用的事，跟固件没关系。大错特错。
为什么？因为很多固件的管理后台、云平台接口、日志收集服务都是用Java写的。Log4j作为日志组件，被广泛集成在这些服务中。你设备里的固件可能不直接跑Java，但它依赖的后端服务可能跑。
避坑指南：我曾经审计过一个工业控制设备的固件，发现它的OTA升级服务依赖一个用Java写的后端。那个后端用了Log4j 2.14.1。攻击者只需要发一个特制的HTTP请求，就能在服务器上执行任意代码。然后呢？通过OTA通道，恶意固件就能被推送到所有设备上。
Log4j事件给固件供应链的教训是什么？
- 间接依赖也是依赖：你的固件可能不直接依赖Log4j，但你的构建工具、测试框架、管理平台可能依赖。SBOM要覆盖整个生态系统。
- 漏洞响应要快：Log4j漏洞披露后，很多厂商花了几周甚至几个月才更新。这段时间足够攻击者把设备翻个底朝天。
- 版本管理要精确：很多厂商只知道用了Log4j，但不知道具体版本。没有SBOM，你连受影响的范围都确定不了。
法规合规要求
这两年，各国政府开始对软件供应链安全下手了。美国走在了前面，咱们得跟上。
EO 14028（美国行政令）
2021年5月，拜登签署了第14028号行政令《改善国家网络安全》。核心要求就几条：
- 向政府出售的软件必须提供SBOM
- 软件供应商要公开漏洞信息
- 建立安全开发实践标准
- 加强供应链安全审查
说白了，以后你想把产品卖给美国政府，就得把家底交代清楚。你的固件用了哪些组件、什么版本、从哪里来的，都得写在SBOM里。
NTIA的SBOM框架
NTIA（美国国家电信和信息管理局）给出了SBOM的具体落地指南。我建议你直接去看他们的文档，但核心要点我帮你提炼出来了。
| SBOM要素 | 说明 | 我的建议 |
|---|---|---|
| 供应商名称 | 组件的原始作者或维护者 | 别只写公司名，要写具体的团队或仓库地址 |
| 组件名称 | 库、工具或模块的名称 | 用官方名称，别自己起别名 |
| 版本字符串 | 精确的版本号 | 别只写"最新版"，要写"2.3.1-rc2"这种 |
| 依赖关系 | 组件之间的依赖树 | 包括传递依赖，别只写直接依赖 |
| 哈希值 | 组件的完整性校验 | 用SHA-256或更高，别用MD5 |
| 许可证信息 | 开源许可证类型 | GPL、MIT、Apache……别搞混了 |
个人经验：我在帮客户落地SBOM时，发现最大的坑不是技术，而是流程。开发团队不知道哪些组件被用了，采购部门不知道供应商提供了什么，安全团队不知道漏洞在哪里。SBOM不是一张纸，而是一个贯穿开发、采购、运维的协作机制。
下面这张图，是我自己总结的固件供应链安全知识体系。你看一眼，心里就有数了。
这张图把固件供应链安全的四个维度串起来了。你看，供应链复杂性是基础，常见威胁是攻击面，Log4j事件是现实教训，法规合规是驱动力。而SBOM，就是把这些维度串起来的那根线。
我个人习惯把SBOM看作固件的"成分表"。就像食品包装上会列出配料和营养信息一样，SBOM告诉你的设备里到底有什么。没有它，你连自己用了什么都不知道，还谈什么安全？