SUP.8 配置管理是 ASPICE 重要支持过程，软件基线是一组经过评审、冻结的配置项集合。从 ISO26262 角度，安全相关软件的每一个版本，都要有对应的完整基线，用来回溯安全分析、测试证据；从 ISO/SAE21434 角度，基线需要记录软件全部组件版本，支撑漏洞溯源、SBOM 物料清单生成。很多项目混淆开发工作副本和正式基线，开发阶段随意修改基线内文件，变更完成不重建基线，发布包找不到与之对应的基线，ASPICE 评估和安全审核调取证据时，无法从二进制软件包反向追溯全套研发产物。

软件基线管控落地经常出现不少合规短板。分不清开发工作副本与正式基线，直接在基线版本上面修改文件，不走变更流程。基线包含的配置项不全，只纳入源代码，漏掉需求、设计、测试报告、标定、SBOM 等配套产物。软件发生变更，只修改代码，不执行重建基线，继续沿用旧基线编号。基线没有明确基线目的，分不清开发基线、集成基线、发布基线。安全相关分析报告、漏洞处置记录没有绑定对应软件基线。对外发布软件包，无法反向匹配内部哪一套 ASPICE 基线。

软件基线不是简单打版本标签，基线需要把代码、文档、测试、安全相关产物成套锁定，变更发生之后要按照流程重建基线，同时承接 ASPICE、ISO26262、ISO/SAE21434 的证据诉求。

策划阶段明确基线策略，定义不同类型基线用途：开发基线、集成基线、发布基线，明确每一类基线包含哪些配置项。源代码、需求、架构、详细设计、测试报告、标定数据、安全分析文档、SBOM 物料清单全部纳入配置管理，作为基线组成部分。

基线创建必须经过对应评审，只有评审通过的配置项才可以纳入正式基线。禁止直接修改基线内文件，如果需要改动，必须走 SUP.10 变更请求流程，变更闭环之后重新生成新版本基线，旧版本基线完整保留，不允许覆盖旧基线。每一条基线记录基线用途、生成时间、包含配置项清单。

对外软件发布，发布包必须来源于正式发布基线，建立发布版本号和内部基线的绑定关系。每一条发布基线同步归档配套的功能安全、网络安全相关工作产物。当要核查某一个发布版本，可以快速调取该基线全套 ASPICE 工作产物以及安全分析记录。

内部预审环节，核查基线策略、基线配置项清单、变更后重建基线记录，核对发布包与内部基线的对应关系。

做好 ASPICE SUP.8 软件基线全生命周期管控，区分工作副本和正式基线，变更后重建基线，成套归档配置项，才能够同时满足 ASPICE 评估、ISO26262、ISO/SAE21434 的审核要求。