CRA（网络弹性法案）与开源无关The CRA is not about open source

在二月份的 FOSDEM 以及上周的联合国开源周上，每当有人问及政府在开源安全方面采取了哪些措施时，《网络弹性法案》（CRA）都是给出的标准答案，而展示该法案的基金会和企业倡导者将其描绘为对开源的利好消息。这是欧盟通过的最大一项软件立法，开源社区花了两年时间对其文本进行游说，其主要义务将于 2027 年 12 月生效。

但它与开源无关。在法案文本中，开源出现的地方都是作为豁免项、组件风险、合规联系人或书面记录。

CRA 是一项属于 CE 标志体系的产品安全法，该体系已经涵盖了玩具、无线电设备和机械：即制造商在欧盟销售产品前必须满足的规则，最终会获得一个合格标志。CRA 将其适用范围扩展到了任何包含软件的产品。在上一篇文章中，我将这类监管描述为要求货运公司在不雇佣任何桥梁检查员的情况下，证明他们的卡车跨越了哪些桥梁，而 CRA 是最常被当作反面教材的法规。

适用范围

CRA 定义的事物是产品、制造或销售这些产品的公司，以及组件。其中没有任何对应于项目、包、注册表或维护者的概念。在法规中，开源仅仅作为受监管产品的组件可以具有的一种属性出现，因此用 CRA 的术语来说，不存在 OpenSSL，只有包含 OpenSSL 的产品。

非商业开源被排除在适用范围之外，这经历了大量的游说，此后也被视为社区的一场胜利。但被排除在产品监管之外并不等于从中受益。一个在 CRA 范围之外的项目，与起草者从未听说过的项目处于相同的境地。

该法规没有设立任何基金，也没有设立检查或维护机构，且其中没有任何条款要求制造商向上游贡献。这项豁免是产品法所能触及的边界：没有人销售的软件无法为市场监管提供任何抓手。

“供应链”一词在文本中出现时，取的是其在产品法上的含义，指的是将商品推向市场并可能各自承担责任的链条企业。这与同一个词在开源中所指的传递依赖图完全不同，仅仅因为词汇重合就将该法规解读为也管理后者，这是一种范畴错误。

依赖项

与开源依赖最直接相关的条款要求制造商在引入第三方组件（包括开源组件）时进行尽职调查。履行这一义务的制造商有以下几种选项：

这些途径都没有将资金导向上游作者，因为面对组件责任的理性反应是降低对其的风险敞口，而不是对其进行投资。如果一家货运公司被告知要对沿途每座桥梁的状况负责，它会优先规划桥梁较少的路线，然后才会考虑成立一个桥梁维修部门。当开源许可条款被视为企业风险时，出现的工具是许可证扫描器和组件替换策略，而安全责任也是同样性质的问题。

文本中最接近上游的规定是一项条款，要求发现组件漏洞的制造商向维护者报告。该义务假设维护者仍然存在并能够接收报告，这是维护机制所能保证的，而产品法规无法做到。

托管方

托管方类别涵盖那些支持供商业使用的开源项目但自身不销售产品的组织。托管方的义务比制造商更轻：制定安全策略，按要求配合监管机构，并处理其负责项目的漏洞报告。

这些是一个组织的职责，否则它将成为制造商文书工作中的漏洞；用桥梁来比喻，这意味着要求现有的维护团队公布一个联系号码，以便填写表格的货运公司有具体的人名可填。托管方条款中没有任何内容雇佣该团队或任命检查员，而且这些较轻的义务仍然是围绕制造商的产品来组织的。

要想通过托管方类别将资金导向开源，制造商需要非常青睐由托管方支持的组件并愿意为此付费。但该法规并没有给制造商这样做的理由：其尽职调查可以通过上一节提到的任何途径来履行，而无需托管方参与。任何确实希望购买组件保障的人，已经可以从商业再发行商那里获得。Red Hat 销售提供支持的开源软件已有二十多年，而 Chainguard 销售的加固镜像提供了 CRA 技术文件所需的 SBOM 和漏洞处理。最接近可销售的托管方产出的是第 25 条规定的自愿安全认证，这被留待未来的授权法案处理。如今成为托管方只会给基金会增加义务，却不会创造出任何制造商有义务向其购买的东西。

SBOM

SBOM 要求“至少”提供顶层依赖项，这使得传递依赖图成为可选项，并且 SBOM 会连同其余合规文书一起放入制造商的技术文件中。该文件由制造商持有，并在要求时提供给监管机构，消费者、研究人员或维护者无权访问。CE 标志技术文件一直都是这样运作的：它是制造商与未来可能对其进行审计的机构之间的私密记录。

由此产生的 SBOM 是一种责任产物，而不是透明度工具：

举个具体的例子，CRA 不会将 Windows 的公开 SBOM 放在公众可以查阅的任何地方。上一篇文章中提到的国家桥梁库存（National Bridge Inventory）向所有人开放，并且由于桥梁监管制度关注的是建筑结构所发挥的功能，因此无论产权归属如何，私人所有的大使桥（Ambassador Bridge）也要接受联邦检查。然而，成千上万个带有 CE 标志的产品中所包含的代码库却得不到类似的记录，因为 CRA 的触发条件是商业活动，且其技术文件是一份用于在事件发生后划分责任的保密档案。

实施

CRA 所启动的机制全都在产品端：欧盟委员会将把产品划分为不同的风险等级，欧盟网络安全局（ENISA）将运行一个报告平台供制造商通报其自身产品中被利用的漏洞，成员国将任命执法机构，而 CEN、CENELEC 和 ETSI 正在制定用于评估制造商的标准。这些都没有触及制造商上游的任何事物，因为该法规在那里没有作任何定义。

那些确实波及开源领域的次生影响是有限的：由于更多的制造商需要生成 SBOM，SBOM 工具将会趋于成熟，尽管 Executive Order 14028 已经推动了这一进程。在制造商向 ENISA 通报其自身产品的特定情况下，被利用漏洞的报告速度会更快。但这两种情况既非开源所独有，也不会作用于漏洞发源地的上游项目。

当 Log4Shell 事件促使欧洲出台相应的政策时，最终拿出的工具却是产品法，这在结构上根本无法对促使其诞生的基础设施产生作用。CRA 对开源的直接危害微乎其微，而且社区努力争取到的豁免条件已经是最好的结果了。

其代价是，当开源维护问题被提及时，人们现在可以拿“我们通过了 CRA”来作为说辞：一项根本不包含维护机制的法规，占据了本该用于建立维护机制的位置。开源社区通过自身的游说将 CRA 变成了一个开源话题，而两年过去了，社区依然在试图将自身代入到一份主题为制造商和消费者的文本中。