CRA 漏洞管理如何落地：从组件清单到可追溯的修复证据

准备CRA相关工作时，研发团队应先建立能随产品版本更新的证据链：用了什么、发现什么、由谁判断、如何修复，以及修复是否有效。是否适用CRA、采用哪种符合性评估路径，需要先按具体产品确定。本篇讨论工程材料的组织方法，报告日期与触发条件见CRA漏洞报告义务说明。

第一步：把清单关联到交付版本

CRA附件I第二部分要求识别并记录产品中的漏洞和组件，包括采用通用、机器可读格式编制SBOM，至少覆盖顶层依赖。项目应在每次发布时留存对应清单，而非只保存一个不断覆盖的“最新版本”。CRA附件I

工程上可记录产品版本、源码提交、构建配置、制品哈希、组件标识和依赖关系。供应商清单与检测结果不一致时，将差异交回确认；未识别的部分保留说明，不能自动归为自研或无风险。

第二步：让检测结果进入人工研判

SCA帮助识别组件及已知风险，SAST检查代码缺陷，二进制分析和模糊测试可用于相应交付物与测试场景。不同方法提供的证据不同。告警应关联到影响条件、复核意见和责任人，不能把“工具命中”直接等同于漏洞可被利用。

对暂不修复的问题，记录理由、缓解措施、批准人和复查日期。评估结论随配置、依赖或使用环境变化时，也要更新记录。

第三步：把修复做成可验证的变更

一条可复核的问题记录，应能找到受影响版本、修复提交、测试用例、回归结果和对外发布版本。补丁可用不等于用户已经安装；面向已交付产品，还应跟踪更新方式和必要的用户说明。研发与安全活动应进入既有生命周期流程，减少事后补材料。NIST SSDF

第四步：按用途组织材料

产品资料、风险评估、测试结果、漏洞处理与变更记录应能互相索引。工具输出是其中的一部分，不能替代产品范围判断、组织责任和完整技术文档。已有汽车安全体系或其他管理流程，可以逐项复用合适记录，仍需核查差距。

软安公开的SCA与SAST能力可支持组件分析和代码审查。实施时应先用代表性项目验证支持范围、集成方式与材料质量，再决定部署和流程安排，不以未经说明的误报率或降本比例作承诺。