CRA报告：先分清漏洞与严重事件
一条客户报告了某款联网设备异常，安全团队还没有确认攻击范围。该等修复完成再处理，还是立即走欧盟《网络韧性法案》（CRA）的报告程序？答案取决于产品是否在适用范围、制造商是否已知悉“被主动利用的漏洞”或影响产品安全的严重事件。两种情形都可能启动24小时预警与72小时通知，但最终报告的期限不同。先判断触发条件，再保留产品版本与时间证据。
截至2026年10月4日，依据 Regulation (EU) 2024/2847 第14、16、71条及欧盟委员会CRA报告说明核对。第14条制造商报告义务自2026年9月11日起适用；CRA其他一般义务的适用时间另行区分。
谁来报告，报告什么
第14条的强制报告主体是制造商，针对已在欧盟市场提供的带数字元素产品。是否属于这类产品，要按法规关于软件、硬件及其远程数据处理方案的定义和预期或可合理预见连接关系判断；“有数字组件”并不自动足够。开放源代码软件管理者另有第24条第3款及较晚的适用时间，也不能直接套用制造商口径。
制造商以自己的名称或商标将产品投放市场，通常不能把对外报告义务全部转交给代工厂。进口商、分销商也有各自的CRA义务，但不应在本文中被一概写成第14条报告主体。合同可约定上游发现线索后如何通知品牌方，却不能代替品牌方判断本产品、版本和事件是否触发报告。
先判两条触发路径
第一条是制造商知悉产品中“被主动利用的漏洞”。仅有理论漏洞、尚无主动利用证据，不能直接等同于这一强制报告触发点；但应继续调查并履行适用的漏洞处理义务。第二条是制造商知悉“影响产品安全的严重事件”。严重程度需要对照第14条第5款的定义判断，不能把任何客服投诉或普通故障都叫作严重安全事件。
初始工单时间值得保存，但并非每一条模糊线索都自动成为法定知悉时点。记录收到什么、何时核验、何时形成被主动利用或严重事件的判断及其理由，才能解释24小时和72小时从哪一刻计算。不要因证据尚不完整而把可能触发的事项一直留在普通工单里。
同样的前两段时限，不同的最终报告
第14条要求在知悉后无不当迟延、最迟24小时提交早期预警；随后无不当迟延、最迟72小时提交漏洞或事件通知。72小时是从知悉起算，并非在24小时预警之后重新起算。初报与后报的信息范围不同，后者需补充已有的产品、性质、影响及措施信息；不能把“尚未查清全部细节”当作无限延迟初报的理由。
最终报告要分开排期：被主动利用漏洞，在纠正或缓解措施可用后最迟14天；严重事件，在72小时事件通知提交后一个月内。两种时钟不能合并成一个“后续再报”的模糊节点。若已有信息此前已经提供，法规也允许避免重复提供相应内容。
把报告接回具体产品版本
设想安全公告只写“某组件存在漏洞”，却没有说明哪一固件版本、哪批在欧盟提供的产品受到影响。即使平台提交成功，客服、补丁发布与客户通知仍可能指向不同范围。制造商应将产品型号、软件或固件版本、市场范围、首个可信线索、判断依据、每次平台提交回执以及纠正措施版本关联起来；这是便于复核的实务记录方式，并非第14条另设的一张固定表。
CRA单一报告平台（SRP）是提交渠道。报告指向制造商主要营业地对应的协调CSIRT，并依规则向ENISA提供；不应写成向所有成员国主管机关逐一手工提交。提交记录也不能代替必要的安全修复、用户沟通或其他适用法律下的义务。
现在可以做的一次核对
选一款在欧盟销售的联网产品，沿“品牌主体—受影响版本—首次可信线索—触发判断—24小时预警—72小时通知—分支最终报告—修复版本”走一遍。若任一环节无法指向责任人或原始证据，先补齐内部升级路径，并按欧盟委员会与ENISA的现行SRP指引核对实际提交字段。本文是法规条文与官方说明的适用解读，不替代具体事件的法律和技术判断。
绿色方舟（深圳）认证有限公司｜邮箱：sui@greenark-sz.com｜官网：www.greenark-sz.com｜电话：18407559004
