欧盟《网络韧性法案》（Cyber Resilience Act，CRA）的制造商报告义务已从2026年9月11日起适用。工业设备厂商收到一条漏洞通告后，关键问题是：它是否涉及自己的适用产品，是否已经达到“已被主动利用的漏洞”或“影响产品安全的严重事件”的条件，以及何时可以认定企业已经获知。仅知道组件有漏洞，与获知本产品存在应报告事项，是不同状态。
欧盟网络安全局（ENISA）已于9月11日宣布CRA单一报告平台启用。截至2026年10月21日，制造商报告义务已经生效；2027年12月11日主要产品要求全面适用，并不意味着报告工作可以推迟到那时。
先确定是哪项产品、谁承担制造商角色
CRA对应法规编号为（EU）2024/2847。欧盟委员会法规概要说明，其范围涉及在商业活动中进入欧盟市场、具有数字要素的硬件、软件及单独投放市场的组件，且预定用途或可合理预见的使用包含与设备或网络直接、间接的数据连接；特定产品另有排除规定。生产地在中国，不会据此自动排除面向欧盟市场的产品义务。
收到安全线索时，企业应先把交付对象对上：是整机、控制器、单独销售的软件，还是集成在其中的组件；以谁的名称或商标投放市场。带通信功能的可编程逻辑控制器（PLC）可以作为核对产品范围的例子，但产品名称本身不足以完成法规分类。整机与外购控制器的产品身份、版本和制造商责任，需要分别识别。
漏洞编号、可利用性与实际利用不是同一件事
ENISA报告平台常见问题说明，“已被主动利用”需要有可靠证据表明恶意行为者未经系统所有者许可利用了漏洞。内部发现一个缺陷、看到已公开的漏洞编号，或者知道技术上可能被利用，均不能单独证明已经发生主动利用。
对于外购组件，欧委会2026年7月27日CRA实施指导文件第218段进一步区分：如果产品包含源于第三方组件的已被主动利用漏洞，该产品制造商应报告；如果漏洞在本产品中无法被利用，例如相关代码不可达，或者并未在本产品中被利用，则不构成该制造商针对本产品的这类强制报告事项。
这个区别要求判断落到实际产品，而不能止于组件名称。某个软件库被多个设备型号使用，可能有不同的功能调用和配置。供应商通告可以启动核查，但它不能替代对本产品版本、相关功能及已知利用证据的分析。暂时没拿到证据，也不等于已经证明没有受到影响。
| 收到线索后的状态 | 应怎样理解 |
|---|---|
| 知道某组件存在漏洞，尚不清楚本产品是否受影响 | 立即开展初步评估，核对产品版本和相关证据；目前的信息不足以直接作出触发或排除结论 |
| 分析确认该漏洞在本产品不可利用，或未在本产品中被利用 | 按指导文件第218段，不属于该制造商针对本产品的已被主动利用漏洞报告事项；仍需分别判断其他事件或处理义务 |
| 有合理确定性认定本产品中的漏洞已被主动利用 | 进入已被主动利用漏洞报告路径，按获知时间计算早期预警及通知时限 |
| 发生了达到条件的产品严重安全事件 | 按严重事件路径判断与报告，不以是否已经获得漏洞编号为前提 |
严重事件是一条独立路径。斯洛伐克国家安全局的CRA报告官方指引援引第14条说明，判断包括：事件是否影响或可能影响产品保护敏感、重要数据或功能的可用性、真实性、完整性或保密性的能力；或者是否已经或可能导致恶意代码进入、运行于产品或用户系统。单看设备是否停机，无法完成这个判断。
计时从“获知”开始，不从调查全部结束开始
欧委会指导文件第213—214段说明，制造商检测到可疑事件，或收到客户、研究人员等第三方线索后，应立即初步评估。当企业据此具有合理程度的确定性，认定产品存在已被主动利用的漏洞，或发生了影响产品安全的严重事件，就应视为已经获知。某些情况从一开始就很清楚；另一些情况需要核对产品是否受影响。初步评估应及时进行，不能用等待完整调查结果来推迟报告。
以下是说明性的工业设备情形，并非真实案例：某厂收到网关软件组件的安全通告，先确认两个交付型号是否包含相关版本。若其中一个型号没有调用该易受影响功能，技术分析确认相关代码不可达，它与另一个已经出现可靠利用证据的型号会得到不同判断。对后者，完整根因调查或最终补丁尚未完成，并不妨碍先提交早期预警。
建议企业分别保留首次收到线索、完成初步判断及作出该判断所依据的记录。这样既能说明为什么某条通告尚需核查，也能说明何时已经达到报告条件。记录是为了还原判断过程，不能通过内部晚登记或晚批准来重新设定法定起算时间。
两类事项都有24小时和72小时节点，最终报告各自起算
根据欧委会报告义务说明及指导文件第215段，两类事项均须在获知后无不当延误地报告，最迟24小时提交早期预警、72小时提交通知；随后随调查进展补充信息。
| 报告事项 | 早期预警与通知 | 最终报告 |
|---|---|---|
| 产品中已被主动利用的漏洞 | 获知后24小时内预警，72小时内提交通知 | 纠正或缓解措施可用后不晚于14天 |
| 影响产品安全的严重事件 | 获知后24小时内预警，72小时内提交通知 | 72小时通知提交后1个月内 |
漏洞路径的最终报告不能只等正式补丁发布：纠正或缓解措施已经可用，也涉及起算。严重事件的最终报告，则从72小时通知提交时起算，不随补丁时间移动。缺少修复措施不会暂停前面的24小时、72小时要求。
ENISA平台字段说明将产品名称、版本、已知事实和事项类型，与后续影响分析、纠正或缓解措施等信息分阶段组织。企业需要把已确认事实与仍在调查的判断分开；初报信息有限，不代表可以用未经验证的推测填满报告。实际应填字段随事项类型和报告阶段核对。
历史交付产品也要判断，但不是把所有旧漏洞重新报一遍
指导文件第210段说明，报告义务覆盖适用产品，包括2027年12月11日前已投放市场的产品，产品结束支持后仍适用报告义务。因此，收到新线索时，核查范围不能只限于在售型号。第217段同时说明：如果制造商在2026年9月11日前已经获知某漏洞被主动利用，不要求对此作追溯报告；此前只知道漏洞存在、之后才获知主动利用的，则需要按新的获知情况判断报告义务。
报告通过单一报告平台（Single Reporting Platform，SRP）提交，提供给相应计算机安全事件响应团队（CSIRT）及ENISA。该报告与向客户沟通并非同一件事。指导文件第219—220段还解释了向受影响用户提供信息的责任，以及按风险和产品环境决定信息范围；向有关用户说明风险，不等于向所有人公开敏感技术细节。
制造商当前最需要形成的能力，是把一条外部线索及时关联到产品、证据与报告阶段。产品版本关系决定要查什么，初步评估决定是否已到报告起点，后续调查决定怎样逐步补充。本文讨论制造商；开源软件管理机构的相关报告义务另从2027年12月11日起适用。
评论留言
暂时没有留言！