车载项目大量使用跨项目复用的软件组件，部分场景需要对复用组件做局部修改，修复 bug 或者适配本项目硬件、业务逻辑。一旦改动发生，原有组件的复用评估结论、安全假设不再完全生效。从 ISO26262 角度，组件改动需要重新评估 ASIL 相关逻辑；从 ISO/SAE21434 角度，修改可能引入新的攻击面。很多团队的做法是直接修改源码，复用评估报告沿用旧版本，不区分哪些代码来自原始组件，哪些是新项目改动，验证只做整体功能测试，不对改动点做专项验证。等到 ASPICE 评估和安全审核，拿不出组件改动对应的分析与测试证据。

修改复用组件落地经常出现合规短板。复用组件发生局部修改，不触发 REU.2 复用适用性重新评估，直接沿用历史复用报告。不区分原生复用代码和本项目修改代码，需求、测试、变更记录混在一起。改动没有走 SUP.10 变更请求流程，缺少多维度影响分析，不评估改动对原有安全假设带来的冲击。只做整体集成测试，不对修改的代码单元开展专项验证。复用组件更新版本之后，SBOM 物料清单没有同步更新，漏洞分析沿用旧版本组件结论。组件修改相关的评估、分析、测试记录没有独立归档，和原始组件资产混杂在一起。

组件只要发生修改，就不再等同于原始可复用资产，不能直接继承全部历史评估结论，需要把改动纳入 ASPICE 完整变更与复用管控流程。

前期决策阶段，只要计划修改已有复用组件，就要重新开展 REU.2 复用适用性评估，明确改动范围，评估改动会不会破坏原始组件的安全假设，标记原生代码与新增修改代码边界。评估报告写明哪些部分继承原有证据，哪些部分需要重新产出证据。

变更阶段，组件修改作为正式变更，走 SUP.10 变更请求流程。除常规功能影响分析之外，叠加功能安全、网络安全研判，评估改动是否触碰安全路径，会不会引入新的攻击面。针对修改的代码单元，补充对应的单元验证，同时完成集成层面测试，不能只依赖系统级测试。

配置与归档阶段，修改后的组件作为新的资产版本纳入复用台账。SBOM 同步更新组件版本与改动说明，原生复用部分与本项目修改部分分开标记。复用适用性评估报告、变更单、专项验证报告成套归档，作为 ASPICE 评估、ISO26262、ISO/SAE21434 共用证据。如果后续该版本继续给其他项目复用，对外交付时完整附带本次改动产生的全套分析与测试产物。

内部预审环节，调取被修改复用组件的复用评估记录、变更影响分析、专项验证材料，检查是否直接沿用未更新的旧版复用报告。

复用组件局部修改不等于直接继承全部历史结论。做好改动识别、重新评估、边界划分与专项验证，才能够同时满足 ASPICE 评估、ISO26262、ISO/SAE21434 的审核要求。