EU CRA 漏洞报告：24 小时预警与 72 小时通报

您的产品发现遭主动利用的漏洞时，能在 24 小时内提出早期预警吗？

欧盟《网络弹性法案》（Cyber Resilience Act, CRA）第 14 条报告义务，已自 2026 年 9 月 11 日起适用。即使是 2027 年 12 月 11 日前已投放欧盟市场的产品，只要符合通报条件，同样受到规范。

📌 CRA 漏洞通报四大重点

🔹 哪些情况需要通报？ 产品中遭主动利用的漏洞，以及对产品网络安全造成影响的严重事件。并非发现任何 CVE 都必须通报。
🔹 24 小时与 72 小时通报：
・24 小时内：提出早期预警，说明产品已在哪些成员国提供（如适用）；事件预警至少要说明是否疑似由非法或恶意行为造成。
・72 小时内：提交漏洞或事件通报，提供已知的一般信息（漏洞要说明漏洞及利用方式的性质；事件要说明事件性质与初步评估）、已采取及用户可采取的纠正或缓解措施，并视需要标明信息敏感程度。
两者均自制造商知悉符合通报条件的漏洞或事件起算，且应无不当延迟地通报。
🔹 最终报告期限：
・遭主动利用漏洞：纠正或缓解措施可用后 14 天内。
・严重网络安全事件：72 小时事件通报提交后 1 个月内。
🔹 通报与用户通知： 通过 ENISA 单一报告平台（SRP），同时向被指定为协调者的 CSIRT 与 ENISA 通报。协调者 CSIRT 原则上是欧盟主要营业场所所在国的 CSIRT；在欧盟没有营业场所的制造商，依授权代表、进口商、分销商所在国等顺序决定。同时须告知受影响用户（适当时为所有用户），必要时说明用户可采取的缓解及纠正措施。

🔍 您的企业是否面临这样的挑战？

假设某工控机（工业计算机，IPC）固件使用的开源组件遭攻击者主动利用，网络安全与研发团队需要迅速厘清：
✅ 哪些固件版本使用了该组件？
✅ 哪些产品机型受到影响？
✅ 这些产品已出货给哪些客户？
✅ 哪些功能或安全测试需要重新验证？
如果组件、固件版本、产品机型与客户数据分散在不同系统中，即使发现漏洞，也可能难以快速完成影响分析。网络通信设备与储能系统（ESS）同样面临这项挑战。

💡 企业可以如何提前准备？

1️⃣ 建立产品追溯关联： 建立“软件组件 → 固件版本 → 产品机型 → 出货客户”的对应关系。
2️⃣ 建立漏洞判断机制： 明确记录知悉时点、漏洞利用证据、受影响产品及判断依据。
3️⃣ 事先准备通报作业： 指定通报窗口（SRP 称为 Assigned Representative），并请其预先建立个人 EU Login 账号、启用 MFA；熟悉 SRP 通报流程，并确认适用的协调者 CSIRT。SRP 平台本身的注册与制造商验证，ENISA 建议在实际需要提交通报时再进行；已有 EU Login 账号时，注册只需几分钟。
⚠️ 不是每个 CVE 都要通报！符合通报条件时，24 小时内先提出早期预警，不必等到完整分析完成。

对制造商而言，CRA 通报不只是网络安全团队的工作，更涉及研发、产品管理、质量与客户服务之间的信息整合。通过 SBOM、产品版本管理与需求追溯机制，有助于企业更高效地分析漏洞影响范围，支持通报及后续修复作业。

👉 想评估贵公司的漏洞影响分析与产品追溯能力？

欢迎与安盛资讯联系。

📩 联系安盛资讯： sales@anselm.com.tw

延伸阅读：EU CRA 网络弹性法案系列文章｜上一篇：EU CRA SBOM：工控机要管理哪些软件与固件？｜下一篇：EU CRA 漏洞处理与支持期：上市后的持续责任

本文仅供一般信息参考，不构成法律意见。官方来源：Regulation (EU) 2024/2847（第 14、69、71 条）；ENISA Single Reporting Platform；ENISA SRP 常见问题（第 9、28 题）。