CRA合规始于代码库
内容提要
《网络弹性法案》要求数字产品制造商自2025年9月起上报被利用漏洞和严重事件，2027年12月起全面适用。合规关键不在政策或报告，而在软件交付系统能否持续产出可靠安全结果。建议将安全默认配置、变更审查、可追溯性、SBOM、CI检查、发布阻断阈值和负向测试嵌入开发流程，并按产品风险分级改进，使证据成为运营能力而非纸面工作。
延伸解读
合规的真正起点在代码库
文章指出，CRA常被当作政策或报告问题，但对构建数字产品的组织而言，实际影响更早体现在拉取请求、构建流水线、发布审批、依赖记录和测试套件中。如果无法回答哪些版本受影响、哪个组件引入暴露、安全控制是否被更改、发布能否复现、修复是否真正生效等基本工程问题，就无法可信地报告被利用漏洞或严重事件。因此，合规能力应内嵌于软件交付系统，而非依赖事后补救。
从政策到证据的落地差距
许多组织已有安全开发政策，但差距在于政策所述与代码库、流水线及发布证据所能证明的内容之间。文章建议按四个成熟度级别评估每项控制，并强调依赖单个知识型工程师、电子表格或发布前突击的控制尚不可靠。高风险失败不应依赖有人注意到，而应由交付系统阻止其推进。这要求将安全默认配置、变更审查、可追溯性、SBOM、CI检查、发布阻断阈值和负向测试嵌入日常开发流程。
证据是运营能力而非纸面工作
文章强调，证据不是文书工作，而是运营能力。构建记录、依赖清单、审查轨迹、测试结果和例外决策能缩短从发现问题到理解范围的时间，帮助团队在压力下做出更好的修复决策。组织应基于产品暴露面、受影响功能关键性、可利用性、数据敏感性、缓解措施可用性及受影响已发布版本数量等因素，制定风险加权行动计划，并定期重新评估，因为有效的控制会随系统、团队和交付实践变化而侵蚀。
AI生成代码加剧验证缺口
文章引用Sonar开发者调查指出，96%的开发者不完全信任AI生成的代码，但仅48%表示在提交前总会验证。这一验证缺口使得一致的控制措施至关重要：无论代码来自开发者还是代理，团队都需要自动化检查来识别敏感变更、验证安全控制并保留发布可追溯性。随着代理式开发加速代码创建，将安全默认、可追溯性、测试和发布控制集成到团队现有工作中，比偶尔访问的独立合规工作流更持久。
Q&A
CRA合规为什么说始于代码库？
因为CRA的实际影响发生在代码层面，如拉取请求、构建管道、发布审批、依赖记录和测试套件。组织若无法回答哪些版本受影响、哪个组件引入暴露、安全控制是否被更改、发布能否复现、修复是否有效等基本工程问题，就无法可信地报告被利用漏洞或严重事件。
CRA的关键时间节点是什么？
自2025年9月11日起，数字产品制造商必须通过欧盟报告流程上报被积极利用的漏洞和严重事件；更广泛的CRA义务从2027年12月开始适用。
如何将安全控制嵌入软件开发生命周期以满足CRA？
将安全默认配置、变更审查、可追溯性、SBOM、CI检查、发布阻断阈值和负向测试嵌入开发流程。具体包括：安全默认行为使更安全的配置成为初始配置；对认证、授权、加密等高风险变更进行额外审查；连接发布产物与源修订、构建输入和依赖；在拉取请求和CI中运行适用检查；定义基于产品风险评级的发布阻断阈值；将负向测试作为一等工程活动。
CRA合规中证据为什么是运营能力而非纸面工作？
证据是运营能力，因为构建记录、依赖清单、审查轨迹、测试结果和例外决策能缩短发现问题与理解范围之间的时间，帮助团队在压力下做出更好的修复决策。它们不是文书工作，而是支持快速、可辩护的事实获取。
CRA合规如何按产品风险分级改进？
根据产品暴露程度、受影响功能的关键性、可利用性、数据敏感性、缓解措施的可用性以及受影响发布版本数量等因素，对控制措施进行风险加权。例如，面向互联网产品的安全默认缺失可能需要立即处理，而低风险内部组件的预合并自动化缺口可能重要但不紧急。
CRA合规与AI生成代码的验证有什么关系？
随着代理式开发加速代码创建，验证差距使一致的控制至关重要。调查显示96%的开发者不完全信任AI生成代码，但只有48%表示总是在提交前验证。因此，无论代码来自开发者还是代理，团队都需要自动化检查来识别敏感变更、验证安全控制并保留发布可追溯性。
