《网络韧性法》漏洞报告：2026 年 9 月的 24 小时执行手册
自 2026 年 9 月 11 日起，制造商一旦知悉带数字元素产品中的漏洞正被积极利用，就必须通过 ENISA 单一报告平台分阶段报告：24 小时内发出早期预警，72 小时内提交漏洞通知，并在补救措施可用后提交最终报告。
本文是工程执行指南，不构成法律意见。它把报告义务转化为产品、安全、支持、法务与沟通团队可以演练的流程。
2026 年 9 月 11 日会发生什么变化？
| 节点 | 触发条件 | 工程动作 |
|---|---|---|
| 24 小时 | 知悉漏洞被积极利用后的早期预警 | 创建同一事件记录，保存知悉时间、市场和初始严重性 |
| 72 小时 | 漏洞通知 | 补充技术评估、利用证据、缓解措施和受影响版本 |
| 最终报告 | 补救措施可用后最迟 14 天 | 记录根因、修复、发布和用户沟通 |
谁负责报告时钟？
由一名事件指挥官负责时钟，但证据来自产品、安全、支持、法务和沟通团队。知悉是业务事件，不是 CVE 编号出现的时刻。应明确谁有权确认知悉，并写入不可追加修改的时间线。
- 把研究员、客户、CSIRT、漏洞赏金、监控和供应商报告汇入一个队列。
- 以结构化字段保存产品、版本、国家、利用迹象和首次观察时间。
- 24 小时、72 小时和最终报告使用同一内部事件 ID。
报告架构应包含什么？
建设证据流水线，而不是临时填表。平台适配器应读取可长期保留的事件记录。区分已确认事实与假设，为每个未知项指定负责人，并保存提交回执。
- 带 UTC 时间和操作者身份的防篡改时间线。
- 连接 SBOM、发布与支持期的产品版本清单。
- 披露决策日志、客户通知草稿和脱敏证据包。
- 使用模拟积极利用场景定期演练。
如何避免漏报与过度报告？
使用两道门：问题是否影响范围内产品，以及可靠信息是否表明积极利用或严重事件。不确定性不会停止时钟，应升级处理并记录判断依据。
- 不要等待完美归因、公开 CVE 或完整根因分析。
- 不要在广泛可见的渠道暴露不必要的漏洞细节。
- 测试周末、休假、供应商通知与监控失效场景。
六周实施计划
- 第 1 周：盘点产品、角色、市场、支持期和负责人。
- 第 2 周：定义知悉、严重性、积极利用和决策权限。
- 第 3 周：建设事件模式、证据库、权限和审计轨迹。
- 第 4 周：连接漏洞入口、资产、发布和客户沟通。
- 第 5 周：演练 24 小时与 72 小时交接。
- 第 6 周：关闭差距并安排季度演练。
构建产品，而不只是 backlog
如果这篇文章对应的是一个真实产品决策，Wavect 可以用高级创始人级判断帮你界定范围、构建、加固或领导软件工作。
可选服务路径：
CRA 报告常见问题
报告义务何时开始？
第 14 条报告义务自 2026 年 9 月 11 日适用。大部分其他 CRA 义务自 2027 年 12 月 11 日适用。
24 小时报告需要完成根因分析吗？
不需要，它是早期预警。保存事实、标记不确定性，并在后续节点更新同一报告。
在哪里提交？
ENISA 运营 CRA 单一报告平台。制造商应提前准备账号、角色和内部证据流程。
漏洞扫描器够用吗？
不够。范围、利用、知悉、市场影响、修复和沟通都需要可问责流程。
最终思考
把 24 小时期限当作架构约束。经过演练的证据流水线和明确决策权，比最后一刻的报告模板更可靠。
主要来源
- 欧盟委员会 CRA 报告页面. 官方日期和阶段
- ENISA 单一报告平台. 官方平台信息
- 欧盟委员会最终 CRA 指南. 最新实施支持