2026年9月11日，你的产品线可能还在正常运行，但合规时钟已经归零。那天起，欧盟《网络韧性法案》（Cyber Resilience Act，CRA）第14条正式生效——比法案其他条款早15个月。发现漏洞后24小时内必须向国家CSIRT（计算机安全事件响应团队）和ENISA（欧盟网络安全局）同步提交预警，72小时内补交技术细节，14天内提交根因分析和修复方案。
这不是未来的事。如果你的产品届时仍在欧盟市场销售，哪怕六年前发布的旧版本，也被第69(3)条明确纳入管辖。没有例外。
第一层：SBOM——你连自己用了什么都不知道
CRA合规的底层逻辑很简单：找不到漏洞，就修不了漏洞，更报不了漏洞。Annex I, Part II把"识别并记录漏洞"列为首要义务，而实现这一点的前提是完整的软件物料清单（SBOM，Software Bill of Materials）。
SBOM不是Excel表格里的一列"依赖项"。它需要对每个组件的版本、来源、许可证、已知漏洞进行机器可读的标准化记录——SPDX或CycloneDX格式。当你的产品捆绑了第三方JSON解析器，而安全研究员六个月后报告该解析器存在内存损坏漏洞时，SBOM是你能在24小时内定位受影响产品版本的唯一依据。
现实情况是，大多数企业的SBOM建设停留在"有就行"的阶段。开发团队用不同工具生成片段，安全团队手动拼凑，版本更新后没人同步。CRA要求的不是静态快照，而是与CI/CD管道集成的持续生成机制。每次构建自动输出SBOM，每次发布自动归档关联。
ENISA正在制定SBOM的具体实施指南，但核心要求已经明确：必须覆盖所有"具有数字元素的产品"（product with digital elements），包括固件、驱动、容器镜像，以及你以为是"黑盒"的第三方闭源组件。
第二层：持续监控——从"等通报"到"主动嗅探"
有了库存，下一步是知道什么时候出问题。CRA的漏洞监控义务不是"有人报才查"，而是主动建立覆盖供应链的信号体系。
这包括三个输入源：公开漏洞数据库（NVD、GitHub Advisory Database、OSV）、供应商安全公告、以及你自己的漏洞赏金计划和 coordinated vulnerability disclosure（CVD，协调漏洞披露）渠道。Annex I, Part II明确要求建立CVD政策，给用户和研究员提供标准化的漏洞上报路径。
关键区分：CRA把"漏洞"和"事件"分开了。漏洞是产品本身的缺陷，事件是利用漏洞造成的实际影响。第14条的24小时倒计时从"发现主动利用"（actively exploited）开始触发——这意味着你需要能力区分"CVE公布了"和"有人在野利用"。
监控工具的选择直接影响合规效率。传统SCA（软件成分分析）工具能告诉你依赖项有CVE，但无法判断利用状态。需要叠加威胁情报源（如CISA KEV目录、Mandiant、Recorded Future）来标记在野利用指标。监控频率也有讲究：NVD数据延迟通常24-48小时，关键组件需要直接订阅供应商的RSS或API。
一个常被忽视的细节：CRA要求监控"包含在产品中的漏洞"，包括你间接依赖的传递依赖。如果你的SBOM只到直接依赖层，深层组件的漏洞可能直到被利用才被发现。
第三层：分级响应——24小时不是从开会开始算
监控触发警报后，真正的压力测试才开始。CRA的分级上报时间表是硬约束，不是"尽力而为"。
24小时早期预警的要求极低：确认产品受影响、漏洞正在被主动利用、初步影响评估。但这需要预先建立的响应机制——谁有权判定"主动利用"？谁有ENISA SRP（Single Reporting Platform）的账号？谁能在凌晨2点签字提交？
72小时详细通知需要技术深度：漏洞的CVSS评分、受影响版本、攻击向量、缓解措施。14天最终报告要求根因分析（为什么这个漏洞进入了产品）、纠正措施（怎么修的）、预防措施（怎么防止再发生）。
严重事件（影响可用性、真实性、完整性、机密性）的时间表相同，但最终报告窗口延长到30天。这里的陷阱是"严重"的定义——CRA采用NIS2指令的术语，比很多企业内部的事件分级更宽泛。一次导致服务中断的DDoS攻击，如果利用了产品漏洞，可能同时触发漏洞上报和事件上报两条线。
响应流程必须嵌入工程团队。安全运营中心（SOC）收到警报后，需要在预定义的时间盒内完成：SBOM查询定位受影响产品→工程确认漏洞存在→法务评估监管触发条件→指定人员提交SRP。每个环节的SLA（服务等级协议）都要倒推计算，留出容错缓冲。
ENISA的SRP目前处于测试阶段，最终提交格式尚未冻结。建议现在就开始跟踪SRP FAQ页面的更新，同时准备备用通道——部分成员国CSIRT可能接受临时邮件上报，但2026年9月后统一走SRP。
第四层：证据链——合规是过程，不是结果
CRA的执法逻辑基于审计可追溯性。你说24小时内上报了，需要日志证明；你说修复了，需要版本发布记录；你说进行了根因分析，需要文档留存。Annex I, Part II要求的"公开披露已修复漏洞"同样需要归档——披露了什么、什么时候、在哪里。
证据链的设计影响长期合规成本。建议建立统一的漏洞案例管理系统，整合：原始报告来源、内部工单号、SBOM查询记录、CVSS评估、上报时间戳、SRP回执、修复commit、发布说明、公开披露链接。每个案例的生命周期完整可审计。
一个实操建议：现在就开始模拟演练。选一个历史上的真实CVE，走一遍完整的CRA流程——从SBOM查询到SRP提交。计时。你会发现24小时里，真正的瓶颈往往不是技术，而是决策链：谁拍板"这是主动利用"？
CRA的罚款框架是营业额全球年收入的1.5%或750万欧元，取其高。但比罚款更隐蔽的风险是市场准入——不合规产品可能被成员国主管机关要求撤回或召回。对于SaaS产品，"撤回"意味着域名屏蔽或支付拦截。
距离2026年9月还有时间，但只够做一件事：把漏洞管理从"安全团队的专项"重构为"产品交付的默认配置"。你的下一个发布周期，能不能自动生成SBOM？你的on-call值班表，有没有覆盖SRP提交权限？这些问题的答案，决定了15个月后你是正常运营，还是凌晨三点找电话号码。
ENISA的SRP测试环境预计2025年下半年开放。你的第一个测试案例，准备好了吗？
热门跟贴