4. 供应链安全基础
在 OTA（Over-The-Air）可信发布体系中，软件供应链是贯穿需求、开发、构建、签名、分发、安装与运行全过程的“生命线”。OTA 更新包从代码提交到最终写入车端 ECU，中间会经过代码托管、CI/CD 流水线、制品仓库、签名服务、CDN 分发、TSP 平台、车端下载与校验等多个环节。任何一个环节被污染或篡改，都可能让攻击者绕过功能安全与信息安全防线，把恶意固件推送到量产车辆上。因此，理解软件供应链的定义、威胁模型、攻击面与治理框架，是构建 OTA 可信发布能力的第一块基石。
一、软件供应链的定义与范围
软件供应链（Software Supply Chain）是指软件从源代码产生到最终交付、部署和运行所涉及的全部人员、流程、工具、制品、依赖与基础设施的集合。它既包括“上游”的第三方组件、开源库、编译器、构建工具，也包括“下游”的制品仓库、签名系统、分发网络和终端设备。对 OTA 场景而言，供应链的终点不是“软件被下载”，而是“软件被车端可信执行”。
软件供应链的核心对象可以概括为四类：代码与依赖（源码、开源组件、二进制库）、构建与签名（CI Runner、编译环境、密钥、证书）、制品与元数据（固件包、清单、SBOM、哈希、签名）、分发与执行（CDN、TSP、车端 Bootloader、OTA Agent）。这四类对象之间的信任传递关系，构成了 OTA 可信发布的信任链。
二、威胁模型：攻击者想做什么
供应链威胁模型通常从攻击者能力、攻击路径和攻击目标三个维度描述。在 OTA 场景中，常见威胁包括：
- 源代码污染：攻击者向开源仓库或内部代码库提交恶意代码，或利用依赖混淆（Dependency Confusion）让构建系统拉取恶意包。
- 构建环境劫持：篡改 CI Runner、注入恶意构建脚本、替换编译器或签名工具，使“合法构建”产出被污染的固件。
- 签名密钥泄露：窃取代码签名私钥或 HSM 访问凭证，直接对恶意固件签名，绕过完整性校验。
- 制品仓库投毒：在制品仓库中替换 OTA 包、回滚到含漏洞版本，或篡改元数据中的版本号与目标车型。
- 分发链路劫持：在 CDN、TSP 或车端下载通道中实施中间人攻击，替换更新包或降级签名算法。
- 车端降级与重放：利用回滚保护缺失，把已修复的旧版本重新刷入，或重放历史合法更新包。
这些威胁并非孤立存在，而是可以组合成攻击链。例如，攻击者先通过依赖混淆进入构建环境，再窃取签名服务凭证，最后通过 CDN 分发恶意固件。威胁模型的价值在于帮助团队识别“高价值资产”和“关键信任边界”，从而把有限的安全资源投入到最需要防护的环节。
三、攻击面：从代码到车端的暴露点
攻击面是攻击者可以尝试进入或影响系统的所有入口与接口。OTA 供应链的攻击面可以按阶段划分，下图展示了从代码提交到车端安装的主要攻击面与信任边界。
从图中可以看到，攻击面并不只存在于“外部网络”，内部构建环境、签名服务和制品仓库同样是高价值目标。信任边界之间的每一次跨越，都需要有明确的验证机制，例如代码评审、构建证明、签名验签、TLS 双向认证和安全启动。
四、典型事件与复盘启示
近年来多起供应链安全事件为 OTA 可信发布提供了深刻教训。SolarWinds 事件中，攻击者入侵构建环境，在合法更新包中植入后门，并通过官方分发渠道推送给大量客户，说明“合法签名”并不等于“内容可信”。Log4j2 漏洞则暴露了开源依赖的广泛传播性，一个组件漏洞可以影响成千上万个下游产品。Codecov 脚本篡改事件中，攻击者修改了 CI 上传脚本，长期窃取环境变量中的凭证，说明构建脚本本身也是攻击面。
这些事件的共同启示是：供应链攻击往往具有隐蔽性强、影响面广、信任滥用三个特征。攻击者不直接攻击最终目标，而是攻击“被信任的中间环节”。因此，治理思路必须从“边界防护”转向“零信任 + 可验证 + 可追溯”。
五、安全治理框架与落地清单
业界常用的治理框架包括 NIST SSDF、SLSA、ISO/SAE 21434 以及国内的车联网网络安全相关标准。它们共同强调：最小权限、制品签名、可追溯性、持续监控和快速响应。下表给出 OTA 供应链安全治理的关键控制点与落地建议。
| 治理域 | 关键控制点 | OTA 落地建议 |
|---|---|---|
| 代码与依赖 | SBOM、依赖锁定、代码评审 | 每次构建生成 SBOM，禁止动态拉取未锁定版本 |
| 构建与签名 | 可复现构建、环境隔离、密钥保护 | 签名私钥存入 HSM，构建产物生成 provenance 证明 |
| 制品管理 | 完整性校验、版本不可变、访问控制 | 制品仓库开启不可变存储，哈希与签名一并入库 |
| 分发与传输 | 加密通道、防重放、防降级 | 使用 TLS 1.3 + 包签名，车端校验版本单调递增 |
| 车端执行 | 安全启动、回滚保护、运行时度量 | Bootloader 验签后才写入，记录更新审计日志 |
| 监控与响应 | 异常检测、漏洞预警、应急撤回 | 建立 OTA 包撤回机制与供应链事件响应预案 |
六、常见误区与复盘要点
- 误区一：有签名就安全。签名只能证明“谁签的”，不能证明“内容没被污染”。必须结合构建证明、SBOM 和运行时度量。
- 误区二：只防外部攻击。内部构建环境、第三方运维账号、CI 凭证同样是高价值攻击面。
- 误区三：忽略回滚保护。攻击者可能重放旧版本利用已知漏洞，车端必须维护版本单调递增与防重放策略。
- 误区四：治理只靠工具。工具能发现部分问题，但流程、职责分离、双人复核和应急响应同样关键。
复盘时应重点回答三个问题：攻击者从哪个信任边界进入？哪些控制点失效或缺失？如何把这次事件转化为可执行的检测规则与发布门禁？只有把供应链安全嵌入 OTA 发布流程的每一个环节，才能真正实现“可信发布”。