按照 ASPICE 测试相关过程的要求，项目需要制定完整的验证策略，覆盖系统、软件各层级验证。站在 ISO26262 角度，安全相关功能需要开展故障注入、场景测试等专项安全验证；站在 ISO/SAE21434 角度，需要开展渗透测试、漏洞扫描、攻击场景验证等网络安全验证。很多项目两套验证分别由不同团队负责，各自制定计划，各自安排资源，验证范围有重叠也有盲区，时间和资源投入重复，还容易出现安全验证缺口。

安全验证策划落地经常出现合规短板。验证计划只覆盖功能测试，安全验证没有单独策划，散落在各个项目阶段。功能安全验证和网络安全验证分开制定计划，时间、资源、环境不共享，重复投入。安全验证范围不明确，哪些 ASIL 等级、哪些 CAL 等级需要做哪些验证，没有清晰定义。验证结果没有统一归档，ASPICE 评估和安全审核时要分别从不同团队调取证据。验证计划不跟随需求变更同步更新，新增安全需求没有对应补充验证安排。

安全验证不能各做各的，要把功能安全、网络安全验证统一纳入项目整体验证策划，统筹范围、资源、进度，提升效率同时避免验证盲区。

验证策划阶段，统一制定项目整体验证策略。把功能验证、功能安全验证、网络安全验证全部纳入整体验证计划，统筹安排验证环境、资源、时间节点。明确不同安全等级对应的验证范围和验证方法，ASIL 等级对应的故障注入测试要求，CAL 等级对应的渗透测试要求，一一对应到具体安全需求。

执行阶段，统筹共享验证环境和资源。HIL 台架、实车环境可以同时安排功能安全和网络安全相关测试，减少环境搭建重复投入。缺陷和问题统一录入项目问题管理体系，跟踪闭环，不用分开两套台账。验证结果统一归档，和对应的安全需求建立追溯关系。

需求发生变更时，同步更新验证计划。评估变更对安全验证范围的影响，补充对应的验证用例和资源安排，避免变更之后验证缺失。

所有验证计划、执行记录、测试报告统一归档，一套验证证据同时支撑 ASPICE 评估、ISO26262 审核、ISO/SAE21434 审核。内部预审环节，核查验证计划覆盖范围、安全验证对应关系、资源统筹情况，确认没有重复投入也没有验证盲区。

安全验证不是两套独立的工作，统一策划、资源共享、结果统存，才能够同时满足 ASPICE、ISO26262、ISO/SAE21434 的验证审核要求，提升验证效率，降低重复投入。