本文内容
《网络韧性法案》报告:24/72 小时操作指南
截至 2026 年 10 月 5 日,CRA 制造商报告义务已经生效。对于被积极利用的漏洞和严重事件,应自知悉起 24 小时内预警、72 小时内报告。最终期限不同:漏洞须在纠正措施可用后最迟 14 天内提交最终报告;严重事件则须在 72 小时报告提交后一个月内完成。
制造商报告义务已于 2026 年 9 月 11 日开始适用。本技术指南关注实际运行,而不是为未来生效日期做准备。它不构成法律意见:产品范围、经济运营者角色及报告触发条件须由合格专业人员确认。以下实施建议不代表额外的法定义务。
每一类报告应按哪个起点计时?
| 节点 | 起点与期限 | 操作证据 |
|---|---|---|
| 预警:两类均适用 | 自知悉起 24 小时内 | 保存知悉时间、类别、初步事实与提交回执。 |
| 正式报告:两类均适用 | 自知悉起 72 小时内,而非预警后再加 72 小时 | 补充受影响产品、评估及现有措施。 |
| 最终报告:被积极利用的漏洞 | 纠正措施可用后最迟 14 天内 | 记录措施可用时间、修复内容与最终提交。 |
| 最终报告:严重事件 | 自 72 小时报告提交起一个月内 | 保留该提交时间、按日历月计算的截止日与最终事件评估。 |
谁负责知悉时间与升级处理?
指定事件负责人及可联系的替补。不能人为把知悉时间推迟到管理者批准工单或 CVE 发布之时。记录谁在何时掌握了什么信息;对法律触发条件有疑问时及时升级,不要等待完美的攻击归因。
- 把研究人员、客户、供应商、CSIRT 和监控告警统一接入同一受理流程。
- 区分首次观测、组织知悉、内部升级和每次外部提交。保存 UTC 时间戳及对应证据。
- 分开评估适用范围和触发条件:扫描发现并不自动等于积极利用或严重事件。记录决定及责任人。
事件记录需要哪些内容?
所有分阶段报告沿用一个持久事件编号。将已确认事实与假设分开,并为关键未知项指定责任人。以下字段是建议的技术控制,不表示外部表单依法必须包含每一项。
- 记录产品及受影响版本、制造商角色、国家、类别、利用或严重性证据、知悉时间及两个初始截止点。
- 漏洞记录纠正措施可用时间;严重事件记录 72 小时报告提交时间。分别用正确字段计算最终期限。
- 保存原始证据、评估修订、责任人、缓解与发布决定、沟通记录、已提交内容和回执。
- 限制敏感漏洞利用细节及个人数据的访问。明确权限、适度保留期限及用于协作的脱敏视图。
在哪里提交,如何演练?
ENISA 的统一报告平台已于 2026 年 9 月 11 日投入运行。使用官方接入和操作指南,不要假设存在公开的提交 API。现在就准备授权访问与替补,并使内部证据记录独立于外部表单。
- 依据官方指南核对访问权限、责任及适用的 CSIRT 路径。
- 内部演练两个场景:被利用的漏洞和严重事件。不要向正式报告渠道提交虚构演练事件。
- 测试周末与缺勤覆盖、访问权限丢失、供应商延迟以及回执保存。
现在应完成的操作检查
- 确认适用产品、制造商责任、事件负责人及替补。
- 验证官方平台访问,并在事件手册中维护最新提交说明。
- 实现知悉时间记录,以及独立的 24 小时、72 小时和按类别计算的最终期限跟踪。
- 将受理流程连接至产品、版本与修复记录;测试访问控制及证据检索。
- 演练两类场景,关闭发现的缺口并定期复测。整改项目不会暂停法定报告时限。
构建产品,而不只是 backlog
如果这篇文章对应的是一个真实产品决策,Wavect 可以用高级创始人级判断帮你界定范围、构建、加固或领导软件工作。
可选服务路径:
CRA 报告常见问题
制造商报告义务是否已开始适用?
24 小时和 72 小时是否依次累加?
所有最终报告都必须在 14 天内提交吗?
开源软件管理者的开始日期相同吗?
预警是否需要完整的根因分析?
这是否是一份法律合规认证?
最终思考
当前重点是可靠执行:统一证据记录、明确负责人及替补,并为两类报告设置不同的最终期限。报告、修复及客户沟通应相互连接,而不必等待完美的复盘报告。
一手资料
- 欧盟委员会:CRA 报告义务. 制造商与开源软件管理者的日期,以及报告类别和期限
- ENISA:统一报告平台. 官方接入、操作指南与报告资源
- 欧盟委员会:CRA 适用指南. 适用范围及实施说明;参阅最新报告章节
