摘要

  • Barry O'Donovan 在 RIPE 93 讲清三种位置：个人为开源项目贡献代码，组织长期支撑项目，制造商把数字产品投入市场。欧盟《网络韧性法案》给这些角色安排不同义务。
  • 欧盟委员会列出的制造商漏洞报告义务已于 2026 年 9 月 11 日生效；开源软件 steward 的相关义务从 2027 年 12 月 11 日开始。角色不同，负责接收和处理漏洞的人仍须找得到。

一封邮件揭开组织结构

O'Donovan 面对的是运营网络的人。他在 RIPE 93 发言中，把 NIS2 对运营商的要求与 CRA 对软件产品的要求接了起来。运营商可以买设备，也会安装开源组件。设备出问题时，报障邮件不会自动找到有权限发布修复版本的人。

欧盟委员会的说明把开源 steward 定义为持续支持特定项目、确保其可用的法人组织；把产品投入市场的制造商承担另一套责任。公开代码、接受捐款、接收企业员工提交的补丁，本身都不足以决定身份。真正有分量的是谁在持续维持产品，以及谁对外提供产品。法规第 24 条要求 steward 留下可核查的安全政策，说明如何记录、处理、修复漏洞。

O'Donovan 提了一个比定义更响的例子：他的机构八个月前雇了一名开发者，后来这名开发者还得接收由 AI 辅助安全研究产生的漏洞报告。这是他的工作现场叙述。它揭示一件事：报告数量可以靠自动化迅速增加，能判断并修复问题的人却需要时间和预算。

官方时间表把制造商报告义务起点定在 2026 年 9 月 11 日，steward 则是 2027 年 12 月 11 日。报告平台向选定的国家 CSIRT 和 ENISA 传递信息。法规时钟与补丁时钟走法不同；用户只关心下一版何时能装。

灰区不能替人值班

会议问答中，Maria Matejka 问谁来判定一个组织究竟是 steward 还是制造商。O'Donovan 预计会出现法院争议。会议没有给任何具体机构作出法律分类。运营商现在可以先做一项简单检查：把关键依赖的漏洞联系人、版本维护者和通知渠道写在同一页，实际发一次测试邮件。收件箱有人，才有修复链条的起点。

资料：RIPE 93 发言记录；官方逐字稿；欧盟法规；欧盟委员会开源说明；报告时间表。