《网络弹性法案》对开源意味着什么

《网络弹性法案》（Cyber Resilience Act，CRA）即将生效。这项影响广泛的法规将引入针对开发商、零售商和设备制造商的新要求和制衡措施；而许多亟待满足的需求在开源社区并没有得到很好的解决。 

在本篇博客中，笔者将探讨 CRA 对开源的影响，分享一些专家的见解，说明该法案在哪些方面有着积极的影响以及在哪些方面存在灰色地带，并向大家介绍在使用或创建开源的情况下应该为法案的推行做好哪些准备。

为何制定《网络弹性法案》？

首先大致介绍一下，CRA 是欧盟即将出台的一项法规，旨在通过对欧盟 IT 行业实施更严格的网络安全、文档和漏洞报告要求，提高设备安全性。这项法规将适用于硬件、设备、软件、应用程序和其他“带有数字连接元素的产品”的开发商、分销商、制造商和零售商。

最近，笔者深入研读了公司网站上一篇提交至福布斯技术委员会的早期文章，其中探讨了该项法规及其对有意在欧盟销售数字产品的群体意味着什么。若想进一步了解该法案及其目标、宗旨和针对开发人员与制造商的新要求，建议阅读笔者发表的文章。

笔者之前发表的文章归总而言即 CRA 有着远大的监管目标。它承诺：

• 针对具有数字组件的产品或软件的上市制定统一规则；
• 制定可以约束此类产品规划、设计、开发和维护的网络安全要求框架，并明确价值链每个阶段需要履行的义务；
• 规定在此类产品的整个生命周期内的谨慎注意义务。

在某种程度上，该法案是对物联网和设备市场的直接回应。从历史上看，在任何科技行业，监管举措都是在市场扩张曲线出现之后很久才推出的。新发明、新平台、新服务蓬勃涌现，整个行业充满生机——数年之后，监管机构随之推出大量严厉的法律法规。 

物联网和设备市场也不例外。在早期，随着设备变得更小、更强大、更加互联，制造商和设备开发商陷入了新市场的“淘金热潮”。大家竞相角逐第一；与所有率先面市的推动举措一样，安全性、稳健设计和安全性可能会被忽视。 

只要看看有关数据泄露和设备故障的科技新闻头条，就能轻易看出 CRA 出现的原因。毕竟，有关物联网设备的争议每隔一天就会出现在新闻中：物联网烤架遭到攻击，将食物烤得酥脆；具有公共访问接口的门铃摄像头；打印机暴露 IP 地址；以及路由器带有公开列出的访问凭证或恶意固件更新漏洞。

从全球范围来看，CRA 只是推动落实更严格要求以确保更安全系统的广泛法规之一。无论是美国关于网络安全的行政命令，或是欧盟取代了 NIS 指令的 NIS2 指令，亦或是英国的类似网络安全法规，CRA 都与之一样，只是全球共同转向于保护全球市场上可用设备安全的又一例证。 

CRA 有何可取之处

该项法规的出发点是正确的。其核心目的是保护免费开源软件或非商业性开发活动免受繁重的监管负担：

这是好事；我们需要更安全的设备，同时也需要这样一个市场：其中销售的产品不会出现故障，不会丢失我们所有的个人数据，也不会向攻击者开放我们的网络。 

同样值得称赞的是，根据社区反馈，CRA 创建了一个开源管理员角色。这个新角色可以在某种程度上作为 CRA 责任豁免，但仅限于特定情况（后文将进行讨论）。如此一来，那些仅为推动创新而对开源感兴趣的群体可以继续这样做，不必承担 CRA 规定的责任。捐赠者和基金会也能够继续在开源生态系统中发挥重要作用。

此外，协作是不可或缺的一环，同时还听取了来自开源专家和整个社区的意见和指导。该法案初稿的众多最受批评之处都已在最终版本中进行了整纳，同时删除或修正了最令人痛苦的条款。例如，其中大幅缩小了“商业活动”的范围，并删除了用于监管接受商业组织或其雇员捐款的项目的条款。经过协商，该法案修改为排除在市场上销售开源软件但将所有收入再投资于非营利性活动的非营利组织。

CRA 面临的批评及其未达预期之处

无论如何，该法案的术语中存在许多不确定性以及与一般开源商业机制之间的潜在冲突。在该法案制定过程中，与开源社区之间在许多因素方面都未达成一致意见，其中就包括其通用术语和相互冲突的定义等。下面我们来看看开源社区做出的反应。

开源社区对《网络弹性法案》的反应

整个开源社区对《网络弹性法案》存在着各种各样的反应。

许多人对新法规中有利于改善网络安全的部分表示赞同。该法案的支持者认为，长期以来，急于上市的开发思路和缺乏对网络安全基础知识的关注，导致全球因为易受攻击、仓促构建或设计不良的设备而存在严重的漏洞和数据泄露风险。GitHub 关于 CRA 的公开声明中指出：“网络安全改革非常有必要。产品往往在交付时不具备足够的安全性，并且在新漏洞出现时不进行维护。我们很多人都因此而直接深受其害。”

然而，《网络弹性法案》的繁重要求和不确定术语让开源社区的大部分人都感到失望。GitHub、Linux Foundation 以及开源社区中的许多其他领导者已经注意到，该法案的措辞宽泛，且制定了针对开源或非营利开发商的严苛要求。面临的批评主要与该法案对开源缺乏精准定义有关，缺乏精准定义意味着许多开源项目实际上可能属于“商业活动”范畴。这些问题将在接下来的部分逐一讨论。

除此以外，甚至还有人担心这可能意味着开源的终结。

CRA 如何对企业使用开源或开源社区的能力产生负面影响

CRA 的目标广泛，内容冗长，对想要利用开源软件的企业会产生相当大的影响。 

总得有人为开源负责

CRA 的核心在于其标志着制造商、供应商、零售商和开发商不再对其产品承担安全责任。大多数遵从性要求，就如新出台的 CRA，在您的供应链中发挥作用的常见方式是应用于您的供应商。例如，CRA 中要求发布的软件不能存在已知被利用漏洞：作为产品供应商，我通常会在与我的供应商签订合同时纳入这一点。

但如果和大多数企业组织一样使用开源会怎么样呢？Synopsys 在 2023 年的一项研究表明，超过 90% 的商业应用程序都包含开源代码。谁来承担开源组件的安全责任呢？如果您的产品受 CRA 约束，那么制造商则有义务遵循针对其所有数字组件的规定。如果您使用的是愿意主动承担起 CRA 所规定责任的商业实体所提供的开放源代码，则非常好。但是，如果是社区主导的项目且不愿意承担遵循 CRA 要求的责任呢？又或者是出于造福世界的目的而发布开源项目但对承担 CRA 所规定的工作负担或责任不感兴趣的商业实体呢？您将需要在自行承担该项责任和另寻软件使用之间做出艰难的抉择。 

更多文件和繁琐程序

以 CRA 为基准意味着您将更加忙于处理文档和透明度方面的工作。 

依照 CRA 的规定，您需要了解并与您的整个软件供应链保持沟通。您需要拥有关于构成项目的组件和堆栈的详尽文档。您需要跟踪漏洞，并在产品的整个生命周期内推送安全更新。另外，您还需要以机器和人类可读的格式提供大量这样的信息，使之可以免费且容易获取。 

为了做到以上几点，您需要强有力的开发和网络安全新标准，包括关于监控和报告漏洞的明确政策和流程。 

对下游的责任

CRA 向我们保证，90% 的设备将属于最低的非关键类别，其合规性或认证要求也是最低（或没有要求）。但不要松一口气，因为 CRA 的其他部分对漏洞的描述很宽泛，其中指出：“在特定情况下，集成或连接到更大电子信息系统的所有具有数字元素的产品都可能作为恶意行为者的攻击媒介”

虽然该法案的变更内容使得开源项目不再受直接监管，但该法案仍将影响使用了该开源软件的每一个欧盟商业产品。毫无疑问，这将促使开源项目优先帮助下游产品进入市场。 

更重要的是，通用技术或库的使用方式几乎不可预测，因此开发商将面临额外的压力，以确保他们的产品合规且适用于更广泛的用例。

非营利性开源项目的监管

开源开发是一个艰难的领域，原因通常在于它不会直接产生金钱回报。早期版本的 CRA 对任何因自身软件而接受捐赠、资助或其他金钱收益者都进行约束。但现在已经发生了变更，其对商业活动的定义更加有理有据，并且扩大了“商业活动”的评估范围，不仅仅包括企业组织的经济模式，同时也包括其使命和活动：

不过，其当前版本仍将影响到许多的开源项目，原因就在于这些项目的融资模式。在下列情形下，非盈利组织模式仍有可能受 CRA 约束：

• 与产品或服务相关的所有收入或收益都不会再投资到项目中
• 他们的软件是免费的，但软件支持服务不是
• 他们的软件是开源的，但在一个可以将其他服务货币化的平台上提供
• 他们的软件是免费的，但他们从软件产生的数据等当中获得经济利益
• 他们不收取产品费用，但他们确有从支持或开源咨询服务中获得经济利益

协调漏洞披露的风险

CRA 旨在通过要求所有开发商在发现漏洞后 24 小时内向欧盟网络安全（ENISA）报告，来解决当前上下游安全修复模式中的缺陷。通常，修复程序正在创建中或者多个供应商之间正在进行协调时，会出于充分的理由选择不发布漏洞。对当前漏洞修复处理方式的这一重大变更可能会使开源项目面临更大的风险；其还可能迫使开发商通过频繁微更新来解决个别漏洞，而不是通过深度补丁更好地提高设备的整体安全性。频繁快速的代码更改实际上给系统带来的风险会比正在修复的风险更多。 

繁琐程序越多可能意味着开源更少

2009 年，在美国儿童玩具中发现铅含量超标，这引发了人们对安全性的恐慌。不出所料，法规和检测要求很快就颁布成为法律。其目的是防止含铅玩具落入儿童手中。在某种程度上，更严格的检测要求减少了事件数量；但这导致了一个意想不到的结果，那就是对小型企业和当地玩具生产商造成了极其严重的影响。虽然大型制造商和大规模进口商业实体能够轻松承受这种额外成本的冲击（通过夺取无法承受冲击的公司在以前所持有的市场份额来支付），但小型企业却发现自身处于劣势。 

关于监管举措的最大风险和误解之一是，监管举措并不能保证取得积极的结果，更糟糕的是，它们可能对小型企业和创新造成致命性和破坏性的影响。有人担心更高的进入壁垒，加重的下游用户软件合规性就绪状态优化压力，以及繁重的一致性评估、文档和披露要求将阻碍和抑制小规模的开发和创新，并且只会巩固大规模专有和商业软件的统治地位，这样的担心不无道理。

Canonical 承诺遵守 CRA

在 Canonical，我们有信心向所有人确保开源安全性，并让企业能够依赖开源。CRA 将给开发商、制造商和无数从事技术工作的人员带来新的压力，以满足严格的新要求，我们正致力于在我们的整个产品和服务范围内尽可能简单地落实这些要求。为此，我们选择正面应对 CRA 的挑战和要求，使所有通过我们来使用开源软件的客户能够从我们对 CRA 的遵守中受益，并专注于构建他们自身的产品，从而不必自己承担额外的责任。接受这些要求之后，我们将努力确保采用了开源技术的产品对每个人都更加安全。 

无论争论走向如何，监管环境正在发生变化

不管喜不喜欢，CRA 已然出台。从长远来看，网络安全合规和严格的开发协议是有益的。开源社区在添加管理员角色之后取得了一些优势。通过这项新举措，开源开发商将有机会获得高质量的指导和资源，开发出更安全的设备和产品，客户和最终用户可以信任地将其网络和数据交由这些设备和产品。 然而，其中仍然存在一些灰色地带，笔者认为在创建和使用开源的过程中肯定会出现摩擦。CRA 的出现也是在呼吁所有开源社区发声并加入各种活跃的工作组，比如 Eclipse Foundation 组建的 CRA 专项工作组，参与制定这些法规和指南并确保开源技术能够继续蓬勃发展。