按照 ASPICE SPL.2 产品发布的要求，软件发布前要确认发布内容、完成发布批准、配套发布文档。站在 ISO26262 角度，安全相关软件发布前，必须评审安全目标是否达成、风险是否可控；站在 ISO/SAE21434 角度，发布前要核查网络安全漏洞是否闭环、防护机制是否生效。很多项目发布阶段只重点看功能测试通过率，安全评审只是签字走流程，没有实质核查安全相关内容，安全隐患跟着软件版本流入量产。

软件发布前安全评审落地经常出现合规短板。发布准入条件只定义功能测试通过，没有把功能安全、网络安全评审结论纳入发布准入条件。安全评审和功能发布脱节，安全问题没有闭环就批准发布。发布前只做抽样安全检查，不覆盖全部安全相关功能。安全评审记录单独存放，没有和发布包、发布审批绑定，ASPICE 评估和安全审核时拿不出发布前的安全评审证据。发布说明只写功能变更，不说明安全相关调整、已知安全风险、残余风险。

量产软件发布不能只做功能把关，要把功能安全、网络安全评审同步纳入发布管控流程，多维度安全检查通过之后才能批准发布。

发布策划阶段，明确定义发布准入条件。除功能测试结论之外，功能安全评审结论、网络安全评审结论必须同步纳入发布准入标准。安全相关问题没有全部闭环，不允许进入发布审批。安全评审覆盖全部安全相关组件，包含故障处理、降级机制、访问防护、异常检测等关键安全逻辑。

发布审批阶段，执行多维度联合评审。功能、功能安全、网络安全工程师共同参与发布评审，分别确认对应领域的风险状态。明确本次发布包含的安全相关变更，核对变更对应的安全验证是否完整，评估残余风险是否可接受。所有评审意见形成书面记录，和发布申请绑定归档。

输出 Release Note 的时候，除功能变更内容，同步补充安全相关说明、已知安全问题、残余风险、版本安全支持周期。发布包和对应版本的安全评审报告、安全验证记录成套归档，一套发布证据同时支撑 ASPICE 评估、ISO26262、ISO/SAE21434 审核。

内部预审环节，核查发布准入条件、安全评审记录、发布说明安全内容，确认发布前安全把关没有走形式。

量产软件发布是质量安全的最后关口，不能只看功能完成度。把安全评审嵌入发布管控流程，多维度联合把关，成套归档发布证据，才能够同时满足 ASPICE、ISO26262、ISO/SAE21434 的量产交付审核要求。