1. 固件依赖与漏洞风险治理导论

固件是嵌入在硬件设备中、负责初始化硬件并向上层软件提供运行基础的一类特殊软件。它通常存放在 Flash、EEPROM、ROM 或 eMMC 等非易失存储介质中，在设备上电后最先运行。与普通应用软件不同，固件与硬件耦合紧密、生命周期长、升级困难，一旦存在漏洞，往往影响面广且修复代价高。理解固件的定义与依赖构成，是开展漏洞风险治理的起点。

一、固件是什么：从启动链看固件边界

从设备上电到操作系统运行，固件承担了关键的引导与初始化职责。以典型的嵌入式 Linux 设备为例，其启动链大致为：BootROM → 一级引导（SPL/Preloader）→ 二级引导（U-Boot）→ 内核（Kernel）→ 根文件系统（RootFS）→ 应用。其中 BootROM 固化在芯片内部，SPL、U-Boot、设备树、内核镜像、根文件系统以及各类驱动模块，都属于广义固件的范畴。

固件并非单一程序，而是由多个组件按启动顺序协作构成的集合。它既包含芯片厂商提供的闭源二进制，也包含开源引导程序、内核与驱动，还可能包含第三方库和配置文件。这种“多来源、多层级”的构成，正是固件依赖复杂、漏洞风险难以收敛的根本原因。

二、依赖构成：固件里的“隐形供应链”

固件的依赖可以分为几个层次。第一层是芯片与硬件抽象层，包括 BootROM、时钟、电源、DDR 初始化等，通常由芯片原厂提供，可修改空间极小。第二层是引导与内核层，如 U-Boot、Linux 内核、设备树，往往基于开源项目裁剪而来。第三层是根文件系统与用户态组件，包括 BusyBox、OpenSSL、Dropbear、curl、libc 等大量第三方库。第四层是厂商自研的应用与配置，如设备管理服务、升级模块、通信协议栈。

这些组件之间存在复杂的依赖关系。例如，一个升级服务可能依赖 libcurl 进行 HTTPS 下载，libcurl 又依赖 OpenSSL 提供 TLS 能力，OpenSSL 再依赖 libc。当 OpenSSL 出现高危漏洞时，风险会沿着依赖链向上传导到升级服务，甚至影响设备远程升级通道的安全性。因此，固件漏洞治理不能只看单个组件，而要沿着依赖链识别传播路径。

三、漏洞风险特征：为什么固件比应用更难治

固件漏洞风险具有几个鲜明特征。其一是隐蔽性：固件通常不暴露在常规软件资产扫描范围内，很多设备连资产台账都不完整，更谈不上组件级清单。其二是传导性：一个底层库的漏洞会沿依赖链影响多个上层服务，如 OpenSSL 的 Heartbleed 类漏洞可同时波及 HTTPS、SSH、VPN 等多个功能。其三是修复困难：固件升级需要重新烧录或 OTA，涉及签名校验、回滚保护、断电风险，很多现场设备甚至无法远程升级。其四是生命周期长：工业、医疗、车载设备往往服役十年以上，而其中的开源组件版本可能早已停止维护。

这些特征决定了固件漏洞治理不能照搬传统 IT 漏洞管理流程。传统扫描—打补丁的模式在固件场景下往往失效，需要从“组件可见”开始，逐步建立版本追踪、风险评估、补丁验证与持续监测的闭环。

四、治理目标与课程路线图

本课程的治理目标可以概括为三个词：可视、可控、可修复。可视，是指能够说清一台固件里到底有哪些组件、什么版本、来自哪里；可控，是指能够评估这些组件的漏洞风险并排定优先级；可修复，是指能够安全地完成补丁验证、构建、签名与升级，并验证修复效果。

围绕这一目标，课程将按以下路线展开：先建立固件依赖与 SBOM 的基础认知，再学习依赖识别与清单生成方法；随后进入漏洞情报匹配、风险评分与优先级排序；接着覆盖补丁获取、构建集成、签名与 OTA 升级的工程实践；最后落到持续监测、应急响应与治理度量。每一章都会结合真实对象、示例参数与可操作的方法，帮助读者把治理目标转化为可执行的动作。

固件依赖与漏洞风险治理，本质上是一场关于“看得见、管得住、修得了”的工程实践。它既需要工具与方法，也需要对固件启动链、依赖关系和升级机制的理解。接下来的章节将逐层展开这些内容。