开源组件已经成为车载软件的重要组成部分，但是开源代码不受本企业研发流程管控。部分团队直接从公开仓库下载组件并入项目，没有做前置评估。等到项目临近发布，才梳理 SBOM 物料清单，此时发现许可证不满足商业使用约束，或者存在高危安全漏洞，整改成本已经很高。

开源组件管控常见几类合规短板。没有建立正式的组件准入评审，开发人员可以直接引入开源代码，不做许可证、漏洞、安全影响评估。开源组件版本不受基线管控，组件随意升级替换，版本变更不执行变更影响分析。漏洞只做一次性扫描，引入之后缺少持续跟踪机制，新披露漏洞无法及时感知。开源组件缺少对应的过程证据，无法证明组件满足 ASPICE、功能安全相关假设。SBOM 只在发布阶段生成，开发迭代过程中组件发生改动，物料信息没有同步更新。

开源组件管控不能只依赖发布前的 SBOM 输出，需要建立从准入、版本管理到漏洞闭环的完整生命周期流程。

组件引入阶段执行正式准入评审。提交组件准入申请，梳理组件版本、许可证协议、代码来源，扫描已知安全漏洞，评估该组件是否用于 ASIL 相关安全路径，评估漏洞风险与许可证兼容性。由开发、法务、网络安全、功能安全人员共同完成准入评审，不通过评审不允许并入项目基线。明确组件使用约束，记录使用假设，哪些部分代码直接使用，哪些部分做了修改，全部归档记录。

组件纳入配置管理，作为正式配置项进行基线管控。开源组件发生版本升级、补丁修改，必须走正式变更流程，开展影响分析，评估升级会不会破坏原有安全假设，完成回归验证之后再合入基线。组件修改的部分和上游原版做好区分记录。

组件在项目存续周期内持续跟踪公开漏洞。当组件披露新的安全漏洞，启动风险研判，判断漏洞是否会影响本项目的使用场景。根据风险等级，采取升级版本、打补丁、规避使用对应接口或者风险豁免的处置方式，所有研判、处置、评审记录完整归档。

SBOM 随基线迭代同步更新，每一个发布基线对应一份完整物料清单，清单记录开源组件版本、许可证、漏洞处置情况。如果开源组件用于安全相关路径，需要明确组件的使用假设，说明哪些安全能力由本项目自研代码来做补偿。

内部预审环节，核查开源组件准入记录、变更记录、漏洞处置材料，核对 SBOM 与基线内实际组件版本是否匹配。

开源组件可以带来研发效率提升，但不能放任自由引入。把好准入关口，做好版本管控与持续漏洞跟踪，完整留存各类研判记录，才能够同时满足 ASPICE、ISO26262、ISO/SAE21434 对于第三方组件的管控诉求。