拯救开源:《网络韧性法案》即将带来的悲剧

TLDR（如果觉得本文太长者，可以只看摘要）

包括开源软件在内的软件正在受到全世界的监管。这篇冗长的博文解释了欧盟《网络韧性法案》的背景、优点、缺陷以及对开源软件可能产生的负面影响。此外，它还解释了该法案在欧盟系统中的复杂流程，以帮助人们了解时间表和如何推动改变。

如果您需要更多的口头介绍，Eclipse 的 Mike Milinkovich 提供了一个非常新颖、清晰的演示，涵盖了相同的内容。如果您更喜欢简短的行动呼吁，那么不妨试试 GitHub、CNLL（法语内容）、Linux 基金会或更广泛的行业响应。

背景

虽然与其他大型行业和部门相比，IT 行业的规模还很小，但在过去的几十年里，它已成为社会的关键。现在，在新闻中经常可以看到软件和 IT 行业的大型事件。而且，更常见的是由某种灾难引发的故事：配置错误、漏洞或显然太容易 "进入" 的犯罪分子和国家行为。现在，不良的 IT 实践也影响到了主要行业，从能源运输、制造业到金融业，再到民主进程和治理良好的政府。

正因为如此，社会和各种管理机构当然也注意到了这一点，因此，世界各地都在制定各种软件管理条例和立法。

历史

以工程史为例，这种监管是再正常不过的结果。19 世纪末，机械行业取得了惊人的发展，这在一定程度上要归功于蒸汽机的发明。但随着这一行业的发展，蒸汽锅炉爆炸事故也随之增多。这些事故通常会夷平半个城镇。

1865 年，蒸汽船 Sultana 号发生爆炸，造成 1,167 人丧生。因此，美国锅炉制造商协会（以下简称 ABMA）成立，开始对该行业进行自律。经过数百次此类爆炸，以及 1905 年在波士顿一家鞋厂发生的一次代价特别高昂的爆炸，政府才开始采取干预政策。

有趣的是，应对 1905 年灾难的并不是 ABMA，而是由五名工程师组成的小组，他们是美国机械工程师协会的成员，这是一个由个人而非公司组成的专业组织。这些人撰写了第一版《锅炉规范》，随后不久便得到了马萨诸塞州立法机构的认可。

从很多方面来说，这些工程师、这些个人志愿者 "自救" 来解决问题；就像我们今天在 ASF 的开源以及 IETF（互联网工程任务组）在制定互联网标准中所做的一样。是专业团体解决了问题：而不是他们的雇主、行业或美国锅炉制造商协会。

现状

目前，世界各地几乎都有大量立法正在进行中；美国和欧盟稍稍领先（各国决策者之间也进行了大量协调）。

在这篇博文中，我们暂时只关注其中一项：欧盟的《CRA - 网络复原力法案》，因为从时间轴的角度来看，这是 "先行者"。

这绝不是最重要的立法。在 ASF，我们认为欧盟的《PLD - 产品责任指令 Product Liability Directive》（引入了对软件 "严格课责" 的规范）、美国的第 14028 号行政命令 "提高国家网络安全”和 "2023 年开源软件安全法案"（美国）可能会产生更大的影响。

这一点可能尤为正确，因为美国立法可以通过国家标准与技术研究院（NIST）为本国制定标准，而国家标准与技术研究院制定标准的速度通常快于欧盟制定标准的速度（因此很可能制定出全球标准）。

这种事情能做吗？

在日常实践中，软件开发人员很少需要考虑监管问题（除非 TA 们从事某些特定领域的工作，如医疗、航空航天、金融或核能）。开源许可证（在我们的下游）和提交者许可证协议（在我们的上游）往往有范围广泛的免责声明。我们通常将代码等同于编撰成文的知识或言论。

但在实际操作中，事情并非如此简单。例如，在 ASF，我们多年来一直需要提交一些文件，让美国工业与安全局（BIS）知道我们提供下载的加密代码的确切位置 [https://infra.apache.org/crypto.html]。由 ASF 发布的代码不能出口（或再出口）到特定目的地或特定名单上的人。

网络韧性法案

在欧盟，《CRA - 网络韧性法案》目前正在法律制定过程中（将于 2023 年 7 月 19 日进行关键投票）。该法案将适用于欧盟的大量软件（以及带有嵌入式软件的硬件）。该法规的初衷是好的（也可以说是早该如此）：使软件更加安全。

| 译者注：欧盟《网络韧性法案》，已经投票通过，但是引发了许多反对意见，后续发展值得观察。

该法案试图通过多种方式来实现这一目标。最重要的是，CRA 将要求市场在设计、构建、发行和维护软件时对安全性采用行业良好实践。在最基本的层面上，CRA 正式确定了ASF 现行的基本政策：管理您的错误，接受、分流并修复安全漏洞。这也是通过将其与良好的治理或实践相结合来实现的；例如，在适当的时候注册 CVE（Common Vulnerability and Exposures 常见漏洞和风险）、编写发行版说明和进行适当的版本管理（平心而论，其中一些我们应该进一步正规化和改进）。

CRA 还将试图确保欧洲市场上的所有软件都能达到某种最低的安全级别，具体做法是在 CE 符合性声明中进行相当简单的自我认证。或者，对于更关键的软件，如防火墙或安全加密密钥飞地，由外部、受监管的指定机构进行实际的 "真正 "认证和审计。CRA 还将定义一系列流程，以监控市场的合规性。

| 译者注：

• “CE” 标志是一种产品安全认证标志（即只限于产品不危及人类、动物和货品的安全方面的基本安全要求，而不是一般质量要求），被视为制造商打开并进入欧洲市场的护照。CE 代表欧洲统一（CONFORMITE EUROPEENNE）。

• 安全加密密钥飞地：是指硬件的处理器和内存的受保护部分。

欧盟政策制定者认识到，这些 "行业最佳实践" 还没有得到很好的定义（在整个行业内，ASF 的安全实践是例外，而不是一体适用的规则）-- 许多 CRA 都依赖于国际标准组织来制定标准，人们可以用这些标准来审核自己的项目（自我认证），或者外部审核人员也可以使用这些标准。

此外，人们还期望重大漏洞能得到特殊处理，并尽早报告。稍后再详述。

对开源的影响

如果你关注过各种博客和公开信，开源基金会一直在关注如何帮助完善 CRA 的现有措辞，使开源软件获得 "豁免"；也就是说，只有当代码离开了开源公域（译者注：Commons 亦可翻译为公共资源）时，CRA 才适用；然后继续适用于整个商业供应链。同时，当某些东西（如安全修复）再次进入公域时，《CRA - 网络韧性法案》也不再适用。

总的来说，这些开源基金会或是社区的努力并不成功。《CRA - 网络韧性法案》历次迭代的文件版本都有很大变化，但不是围绕着以上所述开源基金会或是社区关切的具体政策问题。

为了了解原因，ASF 的代表（连同 OpenSSL）于 7 月 7 日直接与欧盟进行了对话，这是我们第一次真正能够与立法者进行有意义的互动。

从这次谈话中，我们了解到，政策制定者非常清楚，开源对 IT 行业至关重要，无论是对 "生产 "还是创新都是如此。正因为如此，他们希望避免杀鸡取卵。

另一方面，欧盟立法者也意识到，开源通常占典型欧洲中小企业（SME）运营或获得许可的软件堆栈的 95% 或更多。而中小型企业作为将其推向市场的一方，要对整个软件栈负责。

据我们了解，政策制定者认为这些流程改进（和（自我）认证）的成本很高；大约会增加 25% 的管理费用。这是基于最近在医疗领域引入的类似法规和 CRA 影响评估（任何欧盟法律提案都需要将其可能产生的经济影响记录在案）。

因此，从中小型企业的整个堆栈（即 95% 的开源代码和 5% 的私家秘方）来看，对于大多数欧洲中小型企业来说，在全部 100% 的代码上额外付出的努力将是其工程努力的数倍，因此是不可行的。而欧盟的想法是，认证他们在开源堆栈基础上构建的 5% 或 10% 的代码要容易得多。

因此，政策制定者 (1) 向 ASF 明确表示，他们打算将 CRA 适用于开源基金会。目前，开放源代码的例外情况要么是纯粹的业余爱好者，要么是不在现实生活中使用的代码，要么是诸如镜像和软件包仓库（如 NPM 或 Maven Central）之类的东西。他们的做法是，如果软件在商业环境中的任何地方使用，就推定其具有商业意图。

欧盟流程和 CRA 的现状

欧盟的一项立法通常由欧盟委员会起草（该委员会还负责准备 ”影响研究” 等工作）。然后在议会进行讨论。讨论一般在较小的委员会中进行。这些委员会编写报告，最终立法提交议会全体会议表决(2)。

CRA 的主要委员会是 LIBE、IMCO 和 ITRE。

第一个委员会是公民自由、司法和内政委员会（LIBE），负责讨论 "言论自由 "等问题，但该委员会拒绝提交报告。接下来，内部市场和消费者保护委员会（IMCO）研究了什么对消费者和内部市场是重要的。该委员会编写了一份报告，并提交给了工业、研究和能源委员会（ITRE）。

此后，工业、研究和能源委员会（ITRE）编制了一份协商一致的文件，预计将于20230717 这一周进行公开讨论，并获得委员会的最终批准（在获得同意的情况下，委员会一般不进行表决）。

一旦这项工作完成，提案将提交欧洲议会表决。根据当时的争议或共识程度，可能会、也可能不会进行讨论和自由表决。

与此同时，欧盟的第三方--即欧盟理事会--也在准备其版本的法案。主要由各国的相关部长从本国的角度进行审议。然后，三个版本（欧盟委员会、议会和理事会）将在 "三方合议庭"（Trialogues）中进行闭门讨论，最后产生成为法律的最终版本。

比赛状况

目前，据说立法过程中的所有各方都已达成了大致的共识--其中有两方与 ASF 分享了他们的观点，即不存在争议。此外，各种共识文件的副本也已泄露--因此我们知道它们之间的差距并不大，现在我们也可以开始对它们进行分析了。

CRA 给行业带来的问题

目前的定义(3) 规定，《反垄断法》适用于 ASF、及其所有（志愿）开发人员以及我们的所有产出。而且，根据 ASF 与政策制定者的会谈了解，这是有意为之。

对 CRA 的忧虑有很多，但对 ASF 社区来说，以下几个问题可能是最重要的。

公域的概念与商业市场并无区别，它是一种全押模式：第一个问题是，《反垄断法》采取的是全有或全无的二分法。要么加入，要么退出。当你加入时，对你适用的基本上就是需要适用于出售给消费者的全套商业产品的内容。

虽然开放源码可能与此相近（如 Apache Netbeans 或 Apache Zeppelin，尽管没有实际商业产品出售），但开放源码一般不属于商业环境。相反，它可以作为共享知识或公共资源来管理。就像学术论文或参考蓝图一样。CRA 并不承认这一点--因此，CRA 完全适用于开源软件"（而不是仅仅适用 CRA 中在这种情况下可能有意义的要素--如良好的漏洞处理、版本控制和 “软件物料清单-SBOM”）。

除非开源项目具有 "完全分散的开发模式"，否则 CRA 将对其进行监管。然而，"公司" 雇员拥有贡献提交（commit）权的项目将不会被豁免（无论上游开源合作是否与其雇主的商业产品有任何或是毫无关系）。有些项目，如古老的 OpenSSL 项目，其模式甚至更为复杂。

这颠覆了开源的双赢原则。如果禁止企业维护者，企业可能会放弃让其员工维护项目，从而损害开源创新生态系统，具有讽刺意味的是，这将破坏其韧性及其对经济/增长的巨大推动作用（根据欧盟影响评估，每年 90 亿欧元）。

这也让人很难看出 ASF 社区中有谁会去做 ASF 可能被要求需要做的额外的（自我）认证工作。

这样做的净效果实际上相当广泛。举一个 "序言(4)，10a "中的例子（这样的例子还有很多）：

同样，如果自由和开源项目的主要贡献者是受雇于商业实体的开发人员，而且这些开发人员或雇主可以控制代码库中接受哪些修改，则该项目一般应被视为具有商业性质。

在这里，这些贡献者与商业雇主之间缺乏交易关系的联结是个问题。例如，开发者可以是受雇于商业航空公司（即商业实体）的飞行员，利用业余时间为开源做出贡献：这部分政策将使这种贡献具有 "商业性"。此外，在 ASF，主要贡献者（提交者）当然可以对进入代码库的内容进行一定程度的控制(5)。

| 译者注：意即与开源没有半毛钱关系的雇主航空公司也将遭受池鱼之殃，而被列入监管范围内。

更糟糕的是，受影响最严重的开源组织类型也正是那些如今往往拥有非常成熟的安全流程的组织，它们负责任地分流、修复和披露漏洞，并提供与之相匹配的 CVE（常见漏洞和风险）。一般来说，CRA 需要在下游，即将产品投放到市场上的公司中推动重大改进。而现在却有可能出现相反的情况。

CRA 影响了完全由志愿者领导和驱动的项目（如 ASF），在这些独立自主的 ASF 项目中，没有任何公司能对产品的操作和发布有任何影响。而 CRA 将对任何商业实体的员工拥有贡献提交（Commit）权的项目都会受到影响。

这就带来了一个问题：无论是商业公司还是开源项目，都需要对哪些提交者可以修改代码、接受哪些资助以及接受哪些补丁等问题更加谨慎。

在 CRA 认证中，有一个很强的假设，即模块的（自我）认证是 "传递性" 的；也就是说，如果你用经过认证的模块构建了一些东西，你只需要认证你所做的 "额外 "的一些事情。不幸的是，这在一般情况下是不正确的；认证通常在很大程度上是要表明你（作为最终承担责任的组织）是如何确保所交付的东西适合你在客户的特定环境下交付的目的的。开源组织在自我认证其构建的软件模块时，并无法提供 "上游” 信息。

认证的核心是确保所发布的信息对其预期目的具有适当的安全性。具体地说，就是在设计时就考虑到安全问题，规划出威胁行为者、载体和风险。然后根据风险做出合理的工程妥协。

遗憾的是，在开源领域，我们往往不知道我们的软件会被如何使用。而且，正如我们在过去十年中学到的（困而知之），对于我们良好治理共享资源来说，关键是我们不能在许可证中（译者注：对如何使用开源软件）进行歧视或限制（事实上，这也是开源定义的一部分）。

| 译者注：开源定义 Open Source Definition 是 OSI 制定关于开源许可协议的 10 条基本原则。违反这些原则的许可协议，不得自称为 ”开源” 许可协议。

有些义务几乎是不可能履行的：例如，有一项义务是 "提供没有已知可利用漏洞的产品"。这几乎是一个不可能设定的标准；尤其是开源软件的作者既不知道也无法控制他们的代码是如何被整合到下游的。

下一个问题与标准有关。CRA 提到了大量 "待编写 "的国际标准（一般认为由 CEN-CENELEC 制定）。一般来说，IT 行业，尤其是开源，在与这些标准机构合作方面并没有很好的记录（也包含了 ASF），部分原因是几乎所有关键的互联网标准都由 IETF 和 W3C 维护。事实上，这些标准组织的章程不允许开源组织以有意义的方式成为其成员的情况并不少见。

CRA 要求在漏洞修复前，以小时为单位的时限内向 ENISA（欧盟机构）披露严重的未修补漏洞和被利用漏洞。这与行业最佳实践--负责任地披露修复和（变通的）解决办法--背道而驰。

而且，这种过早的报道不仅会分散发布修复信息的注意力，对于国际社会来说，还很容易触犯其他国家坚持要相同信息的规定，或者更糟糕的是，禁止分享此类信息。这就破坏了开源所依赖的公平公正的报告的文化核心。

而且，只有当这些信息被广泛共享时，才会对 ENISA 有用--因此，各组织理应选择谨慎、全球 "公平 "的方案，采取简单易行的方法：确保永远不会听说这些问题。或者，反其道而行之，在（第一个）报告截止日期结束之前，即在问题得到解决之前，将问题公之于众。

| 译者注：意即在问题解决前，不对外公布；或是一有问题，立即全球公布。而不是优先将问题只通知某些特定机构，如欧盟的 ENISA。

因此，这又是一个例子，说明 CRA 虽然用心良苦，但最终可能适得其反。

一个有效的 CRA

纵观欧洲目前的 IT 行业，我们可以发现，造成 IT 行业安全状况不佳的根本原因通常并不是开源（尤其是来自 ASF 这样的组织）。事实上恰恰相反。

与此相反，欧洲的大多数中小型企业很少更新他们所依赖的系统，通常也不擅长处理安全问题报告。而 ASF 的（定期）更新为他们带来了更多的（重新）认证工作，可能会使他们更慢地接受我们的更新和安全修复。

不过，CRA 中也有很多可行的方法，而且我们知道这些方法很可能会有效；在开源组织（如 ASF）层面也是如此。

事实上，我们今天已经做到了大部分，例如对漏洞报告进行良好的分流、负责任的披露、注册 CVE（常见漏洞和风险）以及谨慎使用版本号。在此基础上，我们还实行了良好的治理，各项目都要向董事会报告，偶尔也会有项目在时机成熟时被转移到阁楼上（译者注：束之高阁，意即项目进入退役或退休状态）。

问题更多的在于，CRA 还提出了一系列要求，这些要求要么威胁到开源贡献或我们的公有（或共享）领域非常脆弱的 "双赢 "局面，要么违背行业良好实践，要么根本不可能实现，也就是说，它试图将开源公有领域与商业领域等同对待。

事实上，美国似乎已经意识到了这一点，并正在与美国国家标准与技术研究院（NIST）合作，与业界一起记录这些现有的良好实践。

在某种程度上，美国似乎更接近于历史上由工程师和个人主导的 ACME 程序，该程序产生了锅炉规范；而欧盟似乎更倾向于询问制造商，而不是专家。

互联网如此绕开这样的问题

"互联网将审查制度这一运转良好的机制（就如同房间里的一头大象确实存在）视为故障，并绕开它"（约翰-佩里-巴洛）。

| 译者注：房间里还有一头大象：意指 “一个问题因太过于庞大或麻烦，导致没有人愿意去碰”

上世纪 90 年代，当美国试图对加密软件进行监管时，我们看到了这一机制的作用。只有 "达到出口规范要求” 的加密软件技术才能离开美国。这导致大量加密行业和人员从物理上和法律上离开美国，并将该行业从美国转移到欧洲。在那里，公司只需将其代码输入美国，或从欧洲将其运往世界各地，不受美国出口管理局（BXA: The Bureau of Export Administration）规则的限制。二十多年后，这种情况才得以正常化（我们在 ASF 中仍然可以看到这种情况的残余）。

因此，ASF 还需要考虑到我们的社区可能会因 CRA 而分裂的风险。尤其是当我们散布在欧洲各国的 ASF 项目社区不能调动足够的能力和实力来在 ASF 项目上实施 CRA。

行动时间表

2023 年 7 月 17 日这一周将举行工业、研究和能源委员会（ITRE）投票。这是一个向欧洲议会成员建议如何投票的议会委员会。投票结束后，2023 年夏季休会后可能将开始三方讨论（Trialogues：欧洲议会、欧盟理事会、欧盟委员会）。如果三巨头达成共识（目前看来如此），这一进程最早可能在 12 月结束。

因此，在很短的时间内，人们可以联系工业、研究和环境部的欧洲议会议员。一般来说，如果这些信息是礼貌性的，由具有一定政治或经济地位的一方（如中小型企业组织的首席执行官）发送，并且符合当地的环境，如用当地语言发送给本国的议员，并注意他们所代表的政党的政治立场，则会有所帮助。由于对开源的监管是有意为之，而且《CRA：网络韧性法案》中也有很多具备常识性的良好（开源）实践：目前的期望值是，我们（开源社区）已经有所斩获并且已经过了要求全面例外的阶段。

ASF 将专注于欧盟理事会版本（因为其文本通常在三方讨论中 "胜出"，而且现在比 ITRE 的共识文本更好一些）。为此，我们需要您的帮助：特别是，如果您能帮助我们让贵国较具规模的中小企业高管参与进来，并愿意在国家层面解释 CRA 将造成的负面影响（请联系 ASF 公共事务副总裁；dirkx@apache@org）。

| 译者注：最后的几个段落的诉求看起来比较隐晦，其实就是说 ”开源尚未成功，同志仍需努力”！

原文链接：

https://news.apache.org/foundation/entry/save-open-source-the-impending-tragedy-of-the-cyber-resilience-act

作者：Dirk-Willem van Gulik，Apache 软件基金会公共事务副总裁

译者：刘天栋 Ted

如果您有新的想法，欢迎加入开源雨林交流群，一起探讨。

小助手微信：osrainforest（添加时请备注“交流群”）

开源雨林围绕开源通识、开源使用、开源贡献三大方面构建知识体系，愿把长期积累的经验系统化分享给企业，在团队、机制、项目三方面提供合作，推动各企业更高效地使用开源、贡献开源，提升全行业开源技术与应用水平。 

开源雨林的内容已开源，并托管在 https://github.com/opensource-rainforest/osr ，欢迎通过 Pull Request 的形式贡献内容，通过 Issue 的形式展开讨论，共同维护开源雨林的内容。