AUTOSAR量产软件,主机厂该怎样盘清家底?

一辆车的ECU软件可能由主机厂、基础软件供应商、芯片平台方和应用供应商共同交付。漏洞公告出来后，团队最急着回答的往往不是“有没有软件清单”，而是：哪些车型、哪些控制器、哪些版本真正包含受影响组件？SBOM能把依赖关系整理成可检索数据，但它的价值取决于能否跟AUTOSAR配置、车型版本和OTA处置流程连起来。本文聚焦工程流程设计，不替代企业的法规适用性判定。

背景｜国标提出产品要求，工程团队还要把依赖关系管起来

工信部发布信息显示，GB 44495—2024《汽车整车信息安全技术要求》和GB 44496—2024《汽车软件升级通用技术要求》等三项强制性国家标准于2026年1月1日起实施。它们把整车信息安全与软件升级带入明确的中国市场合规框架，车企需要按适用标准和车型准入要求开展工作。

这项公开信息说明的是标准名称、发布与实施时间，并不等于标准条文直接要求企业使用某一种SBOM格式。美国CISA发布的软件物料清单最低要素指南也不是中国汽车法规。本文把SBOM作为供应链透明度和漏洞管理的工程方法讨论，具体合规判定仍要以正式标准文本、主管部门要求和企业法务意见为准。

AUTOSAR项目尤其容易出现“系统描述里看得到模块，交付包里却找不到依赖”的断层。ECUC配置、基础软件模块、MCAL、OS、通信栈、加密库、驱动、应用软件和编译工具都可能影响最终映像。主机厂如果只维护一个ECU名称与软件版本表，很难在漏洞发生时迅速圈定影响范围。

图1 供应商、OEM平台与车辆软件版本之间需要形成可追踪关系

字段｜SBOM不是一张Excel附件，而是可追踪的组件关系

软件物料清单的核心，是以结构化记录描述软件组件及其供应链关系。CISA最低要素资料中覆盖了组件名称、版本、供应方、唯一标识、依赖关系、作者或生成方以及时间等信息。对汽车项目而言，还需要把这些字段映射到ECU、车型、软件发布包和车辆软件版本集合，才能回答实际运营问题。

一份可用记录应能区分“软件包叫某某栈”和“最终镜像实际编入哪些组件”。静态链接库、预编译二进制、生成代码、芯片厂商驱动和开源依赖都可能进入最终ECU映像；配置禁用某模块是否真的没有进入二进制，也要有构建清单或扫描结果支持。源工程清单与量产产物清单最好能相互校验。

组件标识还要稳定到能比对。仅写“Crypto库”或“网络模块”无法自动关联漏洞公告；名称、供应方、版本、代码来源或哈希、依赖关系和构建时间能让匹配更可靠。如果供应商无法提供某项信息，记录缺口和原因，避免用猜测版本填满表格，制造“已经盘清”的假象。

SBOM可以采用CycloneDX、SPDX等机器可读格式，但企业要先选定内部交换约定并做好字段映射。格式相同不代表供应商对组件边界理解一致；试点时可抽取真实量产包，与二进制扫描结果和交付清单交叉核对。

图2 结构化SBOM把组件身份与依赖关系变成可查询信息

场景图 供应商、主机厂和售后团队围绕软件组件清单协作

构建｜从AUTOSAR工程产物汇总，别只靠供应商手填

在AUTOSAR Classic项目中，系统描述、ECU配置、BSWMD、生成器输入和组件交付包分别保存不同层次的信息。可把这些产物当作SBOM流水线的输入，再结合编译链接清单、软件组成扫描、供应商发布说明与最终镜像标识，形成“配置声明—构建结果—实车版本”的关联。Adaptive应用和容器化软件则还要记录进程、服务依赖及部署目标。

建议把物料清单绑定到不可变的构建基线：源代码提交、工具链版本、生成器版本、ECUC配置版本、供应商包校验值、编译选项和最终产物哈希。重新生成后若组件集合发生变化，流水线应能看见差异并要求审核。否则一份漂亮的SBOM可能只是某次开发样件的记录，无法证明量产刷写包是什么。

对于中国多车型平台，同一个基础软件包可能在不同车型裁剪出不同模块集合。平台级清单可以表达公共组件与候选依赖；车型和ECU级清单则要表达实际启用项、版本和产物。这样漏洞团队先用平台清单做广域检索，再用车辆配置与诊断回读确认具体影响，避免把“供应链中出现过”误判成“每辆车都装有”。

还要区分清单的生成视角：设计视角回答预期有哪些组件，构建视角回答本次编入了哪些对象，运行视角则回答车辆当前实际安装的版本。三种视角可以互相校验，但它们的更新时间和数据来源不同，最好在系统字段里清楚标明。

图3 从构建输入汇总到量产映像，发布基线应保持一致

响应｜漏洞响应要从命中组件走到车型处置

收到漏洞通告后，第一步是把通告中的产品、版本范围、代码分支和适用条件转换为组件匹配规则。第二步用SBOM及供应商确认结果筛出候选ECU，再通过构建记录、发布包校验值和车辆软件回读缩小到车型与批次。自动匹配能加快初筛，但误报和漏报仍需要人工核实组件是否启用、漏洞路径是否可达。

影响评估不能停在“命中了某库”。还要检查易受攻击的接口是否开放，相关功能在目标配置里是否编译启用，攻击者需要什么访问条件，安全机制是否能阻断利用，以及车辆在中国实际销售配置中是否具备该接口。评估结论、假设、供应商回复和决策责任都应进入事件记录，后续监管或质量复盘才能重建判断过程。

若需要修复，软件升级团队应把漏洞处置单连接到新旧软件版本、变更说明、回归测试、批准记录、发布活动和车辆回读结果。若短期不能升级，也要有风险接受、缓解措施和复核日期。GB 44496关注汽车软件升级通用要求；将其与组件清单工作流衔接，是主机厂可以建立的工程流程，不代表单凭SBOM就完成标准符合性。

图4 漏洞响应应连接组件命中、车型评估与修复验证

协同｜供应商接口要把“交什么、更新什么”说清楚

主机厂与供应商的采购技术协议可以约定清单格式、适用范围、更新触发条件、漏洞通知时限、版本生命周期和保密边界。对基础软件和芯片平台，还应明确一份清单覆盖源包、构建包还是最终交付二进制；对有客户专属裁剪的ECU，则要说明通用产品清单如何细化到客户变体。

仅在SOP节点收一次SBOM通常不够。组件可能因漏洞修复、工具升级、供应商补丁或车型功能变体而变化。每次正式发布都应生成新的清单并与上一版做差异比较；构建服务和供应商门户可以机器交换，人工只处理例外、未知组件和安全评估结论。变化规则清楚，才不会让信息安全团队追着工程团队反复要表格。

对于来源受限或无法充分披露的商业组件，可通过可信托管、受控查询、哈希标识、漏洞通知机制或第三方扫描报告补足。目标不是把所有源码都交给OEM，而是确保出现安全事件时有办法确定影响面、协调修复并验证交付。保密安排不能导致量产车辆的风险信息完全不可追溯。

场景图 软件物料信息沿供应链传递，并连接到量产车辆

试点｜先做一个车型闭环，再扩展到平台规模

落地可以从一个ECU和一个车型版本开始：选定软件包，抽取配置与依赖，核对最终二进制，生成机器可读清单，再模拟一条漏洞通告，验证能否在限定时间内找到受影响车型、联系组件责任方、形成升级或缓解决策。试点会暴露组件命名不统一、供应商版本不可复现和车辆回读不足等实际问题。

评价指标不应只是“有多少ECU提交了文件”。更实用的指标包括量产映像清单覆盖率、关键组件可识别率、漏洞匹配确认时间、未知组件关闭周期、清单与实车版本一致率，以及从通告到车辆处置的闭环时间。初始阶段先建立基线和责任人，再按风险逐步提高覆盖目标。

建议把不能自动识别的预编译组件纳入例外队列，要求供应商补齐身份信息或提供受控验证方式，并设置关闭期限。这样管理层看到的是可处理的缺口，而不是一张看似完整、实则把未知依赖藏起来的统计报表。

最终把清单生成放进AUTOSAR及整车软件发布流水线，明确每一轮构建由谁签发，谁负责漏洞响应，谁批准风险接受，谁验证车辆升级结果。SBOM本身不替代安全分析、法规评估或软件测试；它让这些工作能从真实组件关系出发，而不是在问题发生后临时翻邮件、压缩包和旧版配置。

参考资料

工业和信息化部：三项智能网联汽车强制性国家标准正式发布（2024）CISA：Minimum Elements for a Software Bill of Materials（2025）AUTOSAR Classic Platform（R25-11）

软件供应链透明度最终要支持真实车辆全生命周期的维护。