CRA 漏洞报告怎么做：中国联网产品出口企业的 24 小时响应清单
2026 年 9 月 11 日起，CRA 报告义务已经开始。本文把触发判断、24/72 小时时限、ENISA 提交与供应链证据交接拆成一套可演练流程。
自 2026 年 9 月 11 日起，向欧盟市场提供带数字元素产品的制造商，需要通过 ENISA 的 CRA 单一报告平台报告两类事件：被主动利用的漏洞，以及影响产品安全的严重事件。不是所有普通漏洞都自动触发报告。确认触发后，应在知悉后 24 小时内提交预警、72 小时内提交较完整通知；被主动利用漏洞的最终报告最迟在纠正措施可用后 14 天提交，严重事件的最终报告则在 72 小时通知后一个月内提交。企业现在最需要的不是一份泛化“合规证书”，而是一套能在 24 小时内完成事实判断、责任升级和证据留存的工作流。[1][2][3]
报告义务已经开始，2027 年不是第一道截止线
《欧盟网络弹性法案》（Regulation (EU) 2024/2847，CRA）的大部分产品要求从 2027 年 12 月 11 日适用，但第 14 条制造商报告义务已从 2026 年 9 月 11 日开始适用。ENISA 同日启用单一报告平台。本文按 2026 年 9 月 14 日可核验的欧盟官方资料整理，重点解决中国制造商、品牌方和欧盟合作方如何在真实告警发生时协同。[1][2][4]
“发现 CVE”“收到研究员邮件”和“触发 CRA 报告”不是同一件事。主动利用漏洞需要有恶意行为者在未经系统所有者许可的情况下实际利用的可靠证据；严重事件则需要影响或可能影响产品对数据或功能的可用性、真实性、完整性或机密性的保护能力。团队应保存判断依据，也要记录为什么暂不报告。[4]
本文聚焦报告决定、计时、证据字段和供应链交接，不承诺认证通过，也不替代主管机关、CSIRT 或法律顾问对具体事件的判断。
先判断产品、事件和责任主体是否落入报告范围
先按具体产品、投放方式、品牌和事件事实判断。公司注册地不在欧盟并不会自动排除义务；同一漏洞在不同产品版本中的可利用性也可能不同。
| 判断项 | 现在该做什么 | 别误解成 |
|---|---|---|
| 中国企业以自有品牌向欧盟销售联网硬件或软件 | 建立欧盟联系人、产品版本清单和 24 小时升级链；确认谁以制造商身份进入单一报告平台。 | 等到 2027 年做 CE 文件时再处理报告流程。 |
| 中国 OEM/ODM 为欧盟品牌生产带数字元素产品 | 用合同和责任矩阵确认谁是 CRA 制造商；工厂仍需按约定及时提供版本、组件、日志和缓解证据。 | 品牌方负责上报，所以供应商可以不保留漏洞证据。 |
| 欧盟进口商或分销商发现产品安全事件 | 立即按约定通知制造商并保全证据；若以自己的名称销售或作出重大修改，应重新判断角色。 | 只要自己不是开发者，就不需要参与响应。 |
| 开源组件出现在商业联网产品中 | 产品制造商仍应判断组件漏洞是否存在于自己的可交付产品且被主动利用；保留 SBOM、版本和可利用性结论。 | 上游开源项目没有报告，所以整机制造商也无需判断。 |
| 仅有扫描器告警或公开 CVE | 先核对组件是否存在、代码路径是否可达、版本是否受影响以及是否有可靠的主动利用证据。 | CVSS 高或扫描器标红就自动等于 CRA 强制报告。 |
报告计时点不是“邮件进入公共邮箱”或“漏洞修完”的机械日期，而是制造商知悉并对触发事实达到合理确定程度的时间。应记录首次信号、分派、复核、决定与提交时间；不要人为拖延确认，也不要在没有事实的情况下把每条告警都当成已触发事件。[1][3][4]
24 小时、72 小时与最终报告分别交什么
- 制造商报告义务开始
主动利用漏洞和影响产品安全的严重事件，应通过 CRA 单一报告平台提交。其他主要产品义务仍按后续适用日期管理。[1][2]
- 提交早期预警
给出当前已知的触发类型、产品、恶意或非法行为迹象及已知受影响成员国；信息可以不完整，但不能省略已知的关键事实。[1][4]
- 补充漏洞或事件通知
提交产品识别、事件或利用性质、初步影响、已采取和建议用户采取的缓解措施，并标明敏感信息。[1][4]
- 主动利用漏洞最终报告
补齐根因、严重性、补救或缓解措施及实施状态。14 天从纠正措施可用时计算，不等于可以无限期推迟修复。[1][4]
- 严重事件最终报告
补充事件说明、根因或可能根因、缓解和纠正措施，以及可能的跨境影响。[1][4]
- CRA 主要产品义务全面适用
网络安全基本要求、合格评定、技术文档和漏洞处理等主要框架进入适用期；不要把这一日期误当作报告义务起点。[5]
报告前必须随时可取的七类证据
以下资料不是为了“堆文件”，而是为了让值班人员在时限内回答：哪个产品、哪个版本、发生了什么、谁负责决定、已经采取什么措施。
产品与版本身份表
记录商品名、型号、硬件版本、固件或软件版本、序列号范围、销售国家、生命周期与制造商主体。
验证：从一条告警能在 10 分钟内定位到受影响的在售版本和欧盟市场。SBOM 与依赖来源
保存直接和关键传递依赖、版本、来源、构建时间和产品映射；重大版本发布后同步更新。
验证：随机抽取一个组件，可追到哪些产品版本使用、由谁评估和何时替换。漏洞与事件接收记录
统一登记研究员、客户、监控、CERT、供应商和内部测试信号，并保留原始时间戳与附件哈希。
验证：模拟外部报告，确认值班、升级、回执和保密渠道都能运行。触发条件判断单
分别记录主动利用证据、可利用性、受影响产品、安全属性和严重事件标准，不用单一风险分数代替法律触发判断。
验证：复核者能看懂报告与不报告决定，并找到支持事实。24/72 小时字段包
预先准备公司、产品、欧盟联系人、成员国、事件类型、初步影响和缓解措施等稳定字段，动态事实留给事件发生后填写。
验证：桌面演练中，24 小时预警不依赖临时找合同或型号负责人。修复与用户沟通证据
记录补丁、配置缓解、发布渠道、覆盖版本、用户通知、回滚和剩余风险。
验证：用户建议与实际可用修复一致，不出现尚未发布的补丁链接。责任与提交留痕
保存制造商、授权代表、进口商、CSIRT 联系路径、批准人、平台回执和每次补充报告版本。
验证：换班或人员离职后，仍能还原谁在什么时间基于什么证据作出决定。把一次安全告警变成可审计的报告决定
- 1
登记首次信号并保全原始证据
记录最早可证实时间、来源、产品标识和原始材料，不在公共工单泄露可利用细节。
交付：带时区的事件编号、原始证据哈希、访问权限与保全人。 - 2
锁定受影响产品与制造商主体
把组件、版本、销售国家和品牌关系映射到具体产品，确认负责提交的制造商及欧盟联系人。
交付：产品范围表、角色矩阵、无法确认项和负责补证人员。 - 3
分别判断两个法定触发器
一条路径判断是否存在主动利用的可靠证据，另一条判断是否发生影响产品安全的严重事件；不要混成一个“高危”标签。
交付：触发判断单、支持和反对证据、复核人、决定时间。 - 4
在 24 小时内提交可核验预警
先提交已知事实与合理限制，不等根因、补丁和完整影响评估全部完成。
交付：平台回执、提交时间、字段快照和下一次更新责任人。 - 5
在 72 小时内补齐产品与处置事实
更新受影响版本、利用或事件性质、初步影响、缓解措施和用户可执行建议，并标记敏感性。
交付：72 小时通知副本、变更记录、受影响范围与用户建议核验。 - 6
发布修复并验证真实覆盖
测试补丁或缓解措施，确认发布渠道、签名、回滚和用户可达性；不能只记录“已通知研发”。
交付：测试结果、发布记录、版本覆盖、失败回滚和剩余风险。 - 7
提交最终报告并复盘流程
按事件类型在相应期限内补齐根因、措施和状态；将遗漏字段、延迟和供应商响应问题转成下一轮改进。
交付：最终报告回执、完整时间线、复盘行动和关闭批准。
本文是运营和证据准备框架，不构成法律意见、网络安全评估、合格评定或向主管机关提交的正式判断。是否触发报告取决于具体产品、事件、利用证据和角色；高 CVSS、公开 CVE 或扫描告警本身不能替代 CRA 第 14 条判断。报告内容涉及漏洞细节、个人数据或客户系统时，应按最小披露和适用法律处理。[1][3][4]
六个会让响应失控的常见错误
以为全部义务都到 2027 年才开始
制造商报告义务已于 2026 年 9 月 11 日适用；等待产品合格评定项目启动会错过事件响应准备。
把每个高危 CVE 都当成必须上报
应分别核对产品是否受影响、是否可利用、是否有主动利用证据，以及是否构成严重事件。过度报告也会制造噪声和泄密风险。
等根因和补丁完整后才报告
24 小时预警允许信息逐步完善。等待所有结论会直接挤压法定时间窗。
把提交外包后就不再承担责任
顾问或欧盟联系人可以协助，但制造商仍需掌握事实、批准内容并保存平台回执与后续更新。
没有统一产品版本和组件映射
同一商品名可能对应多个硬件、固件和依赖版本。范围不清会让影响判断、用户通知和修复覆盖全部失真。
在多人群聊里传播漏洞细节
报告协作需要最小权限、可审计渠道和敏感字段标记；公开扩散利用方法可能增加用户风险。
中国出口团队最常问的六个问题
2026 年 9 月 11 日开始的是 CRA 全部要求吗？
不是。这个日期开始的是制造商对主动利用漏洞和严重安全事件的报告义务。CRA 大部分产品网络安全要求从 2027 年 12 月 11 日适用，两者要分开排期。[1][5]
产品出现高危漏洞就必须在 24 小时内报告吗？
不一定。24 小时预警针对被主动利用的漏洞或影响产品安全的严重事件。先确认产品是否受影响，并分别判断主动利用证据和严重事件标准；风险分数不能单独决定是否触发。[1][4]
中国制造商没有欧盟公司，怎么进入报告流程？
先确认 CRA 制造商主体和欧盟市场关系，再在 ENISA 单一报告平台按要求建立代表与联系路径。平台使用 EU Login，并提供 Assigned Representative 入口。具体角色和授权应结合实际交易与官方平台说明核对。[2][3]
24 小时内还不知道根因，能先提交吗？
应提交已知且可核验的早期预警，并在 72 小时通知和最终报告中继续补充。不要为赶时限猜测根因，也不要因信息不完整而完全不报。[1]
使用开源组件，漏洞责任是否全部由开源项目承担？
不是。商业产品制造商仍要判断组件漏洞是否存在于自己的产品、是否可利用以及是否触发报告。开源软件管理者的特定报告义务适用时间与制造商不同，不能用它替代产品制造商的判断。[3][4]
提交一次 24 小时预警后就结束了吗？
没有。通常还需要 72 小时通知和相应最终报告，并持续更新修复、用户缓解、范围和根因。应把每次提交的回执与版本纳入事件记录。[1][4]
先用一个真实产品演练 24 小时流程
发布需求时说明产品类型、是否联网、欧盟销售国家、品牌与制造商主体、固件或软件版本、漏洞接收渠道和欧盟联系人。初次沟通只提交脱敏材料，不要公开漏洞利用细节、客户系统信息、密钥或未授权的个人数据。
官方资料
各项资料的核对日期列于下方。政策与平台功能会更新，执行前请回到对应原始来源复核。
- Cyber Resilience Act - Reporting obligations ↗European Commission · 2026-09-14
- Single Reporting Platform (SRP) ↗ENISA · 2026-09-14
- CRA Single Reporting Platform - Frequently Asked Questions ↗ENISA · 2026-09-14
- Regulation (EU) 2024/2847 - consolidated text ↗EUR-Lex · 2026-09-14
- The Cyber Resilience Act - Summary of the legislative text ↗European Commission · 2026-09-14
- Commission publishes guidance to support implementation of the Cyber Resilience Act ↗European Commission · 2026-09-14
本文为面向中国联网产品出口团队的 CRA 报告准备建议，依据欧盟委员会、EUR-Lex 与 ENISA 官方资料于 2026 年 9 月 14 日核对。法规解释、平台字段和主管机关流程可能更新，执行前请回到原始来源并结合具体事件复核。本文不构成法律意见、网络安全鉴定、认证结论或报告触发决定。配图为 AI 生成的产品安全响应场景示意，不是真实漏洞、客户系统、报告页面或案例。