摘要
UN R155与ISO 21434法规持续推动汽车供应链SBOM强制化，本文深入解析为何整车厂要求Tier1/Tier2供应商提交软件物料清单，以及Mend.io如何帮助汽车零部件企业自动生成标准化SBOM、集成CI/CD持续检测、聚合固件与应用层SBOM，满足车企审核要求。
随着汽车产业进入智能化、软件定义汽车（Software Defined Vehicle）时代，车辆已经不再只是机械产品，而成为由大量软件、开源组件和第三方代码共同构成的复杂软件系统。
与此同时，汽车网络安全监管正在快速升级。 ISO/SAE 21434《道路车辆—网络安全工程》和 UN R155 网络安全法规，正在推动整车厂建立覆盖研发、生产、运营全生命周期的网络安全管理体系，并进一步将安全要求传递至全球供应链。
对于中国汽车零部件供应商而言，软件安全能力正在成为进入国际车企供应链的重要门槛。其中，SBOM（Software Bill of Materials，软件物料清单）正成为企业证明软件透明度、管理供应链风险的重要基础能力。企业不仅需要知道：
- 软件中包含哪些开源组件？
- 这些组件是否存在已知漏洞？
- 哪些产品版本受到影响？
- 如何证明已经完成风险评估和处置？
更需要能够向整车厂提供持续、可追溯、可审计的软件安全证明。
法规推动：SBOM 正成为汽车软件安全的重要基础
ISO/SAE 21434：从风险分析到组件级透明
ISO/SAE 21434 是汽车行业网络安全工程的重要标准，覆盖车辆开发、生产、运营和退役全过程。其中，核心要求之一是建立：资产 → 威胁 → 风险 → 安全控制的可追溯关系。
对于软件系统而言，首先需要明确：软件由哪些组件组成？这些组件是否存在安全风险？
这正是 SBOM 的价值所在。SBOM 提供软件组成透明度，使企业能够：
- 识别软件组件来源；
- 关联组件漏洞信息；
- 支撑 TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估）；
- 在漏洞出现后快速定位受影响产品。
如果缺少完整的软件组件清单，企业很难回答：
- “某个 ECU 中运行了哪些软件组件？”
- “某个 CVE 是否影响当前车型？”
- “风险是否已经完成评估？”
UN R155：供应链安全要求向下传递
UN R155 要求汽车制造商建立 CSMS（Cyber Security Management System），并证明车辆具备全生命周期网络安全管理能力。虽然法规并未直接规定”必须提交 SBOM”，但在实际供应链管理中，整车厂越来越依赖 SBOM 来验证供应商的软件安全能力。因此：
- Tier 1 供应商需要提供软件组成信息；
- Tier 2 供应商也逐渐被纳入 SBOM 管理体系；
- SBOM 正成为汽车软件交付过程中的重要安全证明材料。
对于希望进入国际车企供应链的中国零部件企业而言，建立 SBOM 管理能力已经成为趋势。
2026 年汽车行业对 SBOM 提出了哪些新要求？
过去，企业可能只需要提供一份软件组件列表。但随着汽车软件复杂度提升，整车厂对 SBOM 的要求正在升级。
从人工整理到自动生成
整车厂越来越关注：供应商是否能够在软件开发过程中持续生成 SBOM？
因此，SBOM 需要融入 CI/CD 流程：代码提交 → 自动扫描 → 生成 SBOM → 发布交付，而不是在项目结束后人工补充。
从应用软件扩展到完整软件栈
现代汽车包含大量 ECU（电子控制单元），涉及：
- AUTOSAR
- Linux
- RTOS
- Android Automotive
- 固件组件
- 第三方软件包
因此，SBOM 不能只覆盖应用代码，还需要覆盖：
- 源码组件；
- 容器镜像；
- 操作系统组件；
- 固件软件。
只有完整的软件组成视图，才能真正支撑供应链风险管理。
从一次性交付到持续维护
汽车生命周期通常长达十年以上。
因此，SBOM 需要支持：
- 历史版本追踪；
- OTA 更新管理；
- 新漏洞影响分析；
- 长周期安全维护。
例如，当某个开源组件出现新的 CVE 时，企业需要快速回答：
- “哪些车型受到影响？”
- “哪些 ECU 需要更新？”
- “是否需要发布补丁？”
Mend.io 如何帮助汽车供应商建立 SBOM 能力？
作为企业级应用安全平台，Mend.io（原 WhiteSource）提供覆盖软件开发生命周期的安全能力，包括 SCA、SAST、容器安全和 AI 安全。
在 SBOM 管理方面，Mend.io 可以帮助企业实现：
自动生成标准化 SBOM
Mend SCA 支持 200+ 编程语言和包管理器（包括 npm、pip、Maven、NuGet、Go、Rust 等），自动解析直接依赖和传递依赖，生成源码层 SBOM。SBOM 统一输出 CycloneDX 和 SPDX 双格式，满足不同整车厂的格式要求。
2026 年 6 月的版本更新中，Mend SCA 新增了对 SPDX 和 CycloneDX 标准的源文件级 SBOM 导出和导入支持，使 SBOM 粒度从包级细化到文件级，满足深度审计需求。
Mend.io 生成的 SBOM 包含 CISA 要求的最小字段集（组件供应商、名称、版本、唯一标识符、依赖关系、SBOM 作者、生成时间戳），并额外提供组件哈希、许可证信息、CVE 上下文等扩展字段。
集成 CI/CD，实现持续安全检测
Mend.io 可以接入开发流程，实现”建构即生成 SBOM”。
| 阶段 | 能力 |
|---|---|
| 开发阶段 | IDE 插件实时发现风险 |
| 代码提交 | 代码仓库自动扫描 |
| 构建阶段 | CI/CD 集成生成 SBOM |
| 发布阶段 | 策略门禁控制风险版本 |
关键在于”持续监测”：即使代码未变更，当新漏洞被披露时，Mend.io 会重新评估已有项目的风险状态并通知安全团队，满足 ISO 21434 对持续合规的要求。
通过风险分析降低告警噪声
SBOM 的价值不仅是”列清单”，更重要的是判断风险。
Mend.io 的可达性分析（Reachability Analysis）追踪应用代码到漏洞函数的完整调用路径：
- 如果漏洞函数从未被应用触达，标记为不可达，降低优先级
- 结合 CVSS 严重性评级和 EPSS 利用概率评分，创建风险调整后的待办列表
- 生成 VEX（Vulnerability Exploitability eXchange）声明，明确每个 CVE 在当前部署环境中的可利用性
VEX 声明可以减少 60%-80% 的 SCA 告警噪声。对于需要向整车厂提交合规证据的供应商，VEX 是证明”已评估风险但无需修复”的关键文档，避免不必要的补丁工作和审计沟通成本。
聚合多来源 SBOM，形成完整产品视图
对于汽车行业，固件层的 SBOM 通常由专用工具（如 ONEKEY 固件分析平台）通过二进制逆向分析生成。Mend.io 支持导入第三方 SBOM（含文件级组件），并触发异步匹配以识别源库和未匹配文件。
这意味着供应商可以将多个来源的SBOM统一聚合到 Mend.io 平台管理：
- 固件层：ONEKEY 等工具生成的二进制 SBOM（CycloneDX/SPDX 格式）
- 应用层：Mend SCA 生成的源码层 SBOM
多个SBOM 聚合后形成产品级完整 SBOM 视图，消除多源数据割裂，满足整车厂对”全可执行层覆盖”的要求。
汽车零部件企业如何落地 SBOM？
分层接入策略
对于同时涉及固件和应用软件的汽车零部件供应商，建议采用分层接入：
- 应用层优先：接入 Mend SCA，覆盖源码和容器镜像，建立 CI/CD 自动化扫描流水线
- 固件层补充：使用 ONEKEY 等专用工具生成固件层 SBOM，导入 Mend.io 平台聚合
SBOM 交付流水线设计
将 SBOM 生成嵌入 CI/CD 流水线，实现”编译同步生成”：
- 每次 build 自动触发 SCA 扫描，生成版本化 SBOM
- SBOM 与制品版本绑定，支持按版本回溯
- 策略门禁阻断包含严重可达漏洞的版本进入生产
- OTA 差分更新时自动生成差分 SBOM，标注组件变更
持续运营机制
- 配置零日漏洞响应工作流，新漏洞披露后自动评估影响范围
- 定期向整车厂提交 SBOM 更新和安全状态报告
- 建立内部 SBOM 审查流程，确保许可证和组件信息准确
- 利用 VEX 声明减少无效告警，聚焦真正需要修复的风险
结语
汽车行业的软件供应链安全正在进入新的阶段。未来，SBOM 不只是一个软件清单，而是连接软件透明度、漏洞管理、合规审计、供应链信任的重要基础设施。
对于希望进入全球汽车供应链的中国零部件企业而言，提前建立 SBOM 生成、管理和持续监控能力，将成为提升竞争力的重要一步。
