SUP.10 变更请求管理是 ASPICE 重要的支持过程，任何软件、需求、标定、架构的改动都需要纳入该流程。普通功能性变更只需要分析上下游软件模块，一旦变更触碰安全相关逻辑，就需要叠加功能安全、网络安全层面的研判。不少项目处理安全相关变更，只看被直接修改的代码，不去评估间接关联的安全机制。影响分析做得单薄，回归测试范围裁剪没有合理理由，ASPICE 评估抽取变更单的时候，会指出影响分析不充分。同时 ISO26262 要求评估变更对安全目标的影响，ISO/SAE21434 需要评估改动带来的新增攻击面。

安全相关变更落地经常出现几类合规短板。变更影响分析只做代码层面分析，缺少功能安全、网络安全维度的研判。改动 ASIL 相关逻辑，没有复核原有安全目标、故障处理机制是否依旧成立；修改报文、鉴权逻辑，不去评估网络安全风险。影响分析没有写明回归测试的选择与裁剪理由，直接复用旧版本全部测试或者大幅缩减测试。变更闭环只确认缺陷修复完成，不核对安全相关的复核活动有没有做完。安全相关变更的全套分析、评审、测试记录没有和变更单绑定归档，ASPICE 评估和安全审核找不到对应证据。

安全相关变更不能只做代码层面的影响分析，要把功能安全、网络安全纳入 ASPICE SUP.10 变更请求管理的标准环节。

提交变更请求之后，除常规的软件上下游、需求、文档影响分析之外，额外开展两个维度研判。功能安全维度，判断本次改动是否触碰 ASIL 相关组件、故障检测、降级机制，评估是否会冲击已有的安全目标，判断是否需要更新 HARA 相关结论。网络安全维度，分析改动会不会修改鉴权、报文处理、数据存储逻辑，有没有引入新的攻击面，TARA 分析结论是否需要更新。

基于完整多维度影响分析，确定回归测试范围。如果改动涉及安全机制，除基础功能复测之外，需要补充故障注入、安全防护专项测试。测试范围如果做裁剪，必须书面写明裁剪依据，经过功能安全、网络安全工程师共同评审。

变更全部闭环前做复核检查，确认安全维度的分析、评审、专项验证活动全部完成。变更请求、多维度影响分析报告、评审记录、回归测试报告统一绑定基线归档，作为 ASPICE 评估、ISO26262、ISO/SAE21434 共用证据。

内部预审抽样调取安全类变更单，核查多维度影响分析完整度，检查回归范围裁剪的评审记录。

依托 SUP.10 变更请求管理，把安全维度研判固化到变更流程当中，就可以在处理软件改动的时候，兼顾 ASPICE 评估取证和两套安全标准的审核要求。