1. 固件安全CI/CD全景
固件是嵌入在硬件设备中、负责最底层硬件初始化与运行控制的软件集合。它通常烧录在Flash、eMMC、ROM等非易失存储介质中，在设备上电后最先执行，承担引导加载、外设驱动、安全启动、运行时服务等职责。与普通应用软件相比，固件具有生命周期长、升级困难、与硬件强耦合、失效后果严重等特点。理解这些特性，是构建固件安全CI/CD流水线的前提。
固件的定义与分类
从工程视角看，固件可以按运行层级和功能划分为几类：最底层是BootROM与一级引导程序（如BL1），它们固化在芯片内部，负责最基础的时钟、内存初始化并加载下一阶段；中间层是二级引导程序（如U-Boot SPL、TF-A BL2/BL31），负责DDR初始化、镜像校验与跳转；上层是操作系统内核与根文件系统镜像；再往上则是运行在设备上的应用固件，如MCU上的RTOS任务、BMC固件、路由器固件等。按部署形态，又可分为单镜像固件、A/B双分区固件、差分升级固件和容器化固件。
不同类别的固件，其安全关注点差异明显。BootROM关注不可篡改的信任根；引导程序关注签名校验与回滚保护；内核与文件系统关注完整性度量与最小化裁剪；应用固件关注运行时隔离与安全更新。CI/CD流水线需要针对这些差异设计不同的构建、签名与验证阶段。
固件安全威胁模型
固件安全威胁模型通常围绕信任边界展开。攻击者可能位于供应链上游（恶意代码注入、依赖投毒）、构建环境（构建服务器被入侵、签名密钥泄露）、分发通道（镜像被替换、降级攻击）或设备运行时（物理访问、调试接口滥用、故障注入）。典型的威胁包括：未签名固件被刷入、签名校验被绕过、安全版本被回滚到存在漏洞的旧版本、调试口未关闭导致内存读取、以及OTA更新过程中的中间人篡改。
为应对这些威胁，需要建立“信任根—信任链—信任域”的层次模型。信任根由芯片内不可修改的BootROM和公钥哈希构成；信任链通过逐级签名校验将信任从BootROM传递到引导程序、内核和根文件系统；信任域则通过安全隔离机制（如TrustZone、TEE）保护密钥与敏感操作。CI/CD流水线的作用，就是在每次构建中自动执行签名、校验、版本防回滚检查和产物完整性记录，使信任链在交付前就得到验证。
CI/CD在固件开发中的角色
传统固件开发常依赖手工编译、人工签名和本地烧录，容易引入版本不一致、密钥管理混乱和产物不可追溯等问题。CI/CD的引入，把固件交付从“个人经验驱动”转变为“流水线驱动”。在固件场景中，CI/CD至少承担四项职责：第一，保证构建可复现，通过固定工具链版本、锁定依赖哈希、记录编译参数，使同一commit在任何时间都能产出相同二进制；第二，自动执行安全门禁，包括静态代码扫描、密钥硬编码检查、依赖漏洞扫描和签名校验；第三，隔离签名密钥，构建节点只接触待签名摘要，私钥保存在HSM或独立签名服务中；第四，生成可追溯的产物清单，记录每个镜像的哈希、签名、SBOM和构建日志。
需要强调的是，固件CI/CD不是把应用软件的流水线照搬过来。固件构建往往涉及交叉编译工具链、芯片厂商SDK、分区表配置和烧录镜像格式，流水线需要为这些环节提供专用步骤。同时，固件一旦发布就难以召回，因此发布前的验证强度应高于普通软件，必要时引入硬件在环测试（HIL）和签名回滚演练。
课程项目仓库初始化
本课程以一个虚构的嵌入式Linux设备固件项目为贯穿案例，项目代号“fw-sec-lab”。仓库采用单仓多模块结构，便于统一管理构建脚本、签名配置和流水线定义。初始化时建议建立如下目录骨架：
fw-sec-lab/
├── .gitlab-ci.yml # 流水线定义
├── ci/
│ ├── build.sh # 交叉编译入口
│ ├── sign.sh # 镜像签名脚本
│ └── verify.sh # 签名与版本校验
├── configs/
│ ├── toolchain.env # 工具链版本锁定
│ └── partitions.json # 分区表配置
├── src/
│ ├── bootloader/ # 引导程序源码
│ ├── kernel/ # 内核配置与补丁
│ └── rootfs/ # 根文件系统构建
├── keys/
│ └── README.md # 密钥管理说明（不存放私钥）
└── docs/
└── threat-model.md # 威胁模型记录
初始化完成后，执行以下命令建立基线并打上首个标签，作为后续流水线验证的起点：
git init
git add .
git commit -m "chore: 初始化固件安全CI/CD项目骨架"
git tag -a v0.1.0-secure -m "安全基线：工具链锁定与目录结构就绪"