开源供应链需“硬分叉”应对AI风险

Mythos 是真实存在的。我知道业内很大一部分人认为这只是一场营销炒作，我也理解为什么。我理解。但我看过这些发现，而且情况很糟。这些并不是“哎呀，这一行写错了，所以这里就是 RCE”那种问题。它们是从成千上万条 SAST 扫描器本来就会发现的问题里，挑出几十个，再以全新的方式组合、串联成更严重的结果。那是一种真实的创造力，就像 Move 37。那不是更好的扫描器，而是另一类威胁。

从某些角度看，这甚至不重要。即使这个特定模型是个骗局，这种能力也无论如何都会到来。有些日子里，我希望它真的是骗局。那样我们会有更多时间。但你可以相信我，也可以不信。无论如何，这篇文章剩下的内容都在讲我们该怎么应对，而我现在就开始说。

华盛顿已经跟踪这件事有一段时间了，但你不能去监管一个大多数业内人士都认为是编出来的东西。现在每个董事会都在进入准备模式（而且确实如此），华盛顿特区终于可以开始思考他们能采取哪些步骤。很明显，他们需要扮演一个角色，但还不清楚该怎么做，或者应该做到什么程度。而且他们处在一个非常艰难的位置。

监管得太少，就有可能让一家美国公司意外制造出一种会威胁我们关键基础设施的武器。监管得太多，同样的事情就会发生在中国。整件事感觉就像对病毒做 gain-of-function research。大家都知道离开实验室前要洗手，但仅仅因为我们把它设为强制，并不意味着世界其他地方也会这么做。武汉那次的故事，我们已经见过了。

限制任何政府能做什么的结构性问题在于：尽管欧洲通过 CRA 已尽力而为，开源并不可治理。法律和行政命令不适用于全世界那些把东西免费放到互联网上的人。美国意识到了这一点，所以他们把重点放在自己能做、也应该做的地方：消费端。这个判断是对的，而这正是这篇文章接下来要谈的内容。

开源生态与消费模式还没准备好应对这一切

过去十年里，我每天都在处理这个问题。我在 Google 期间共同创办了 OpenSSF 和 Alpha-Omega。我创建了 Sigstore、Scorecards，以及最早的开源恶意软件扫描器。我资助了把 Rust 引入 Linux kernel、以及让 PyPI 启用 MFA 的项目资助。后来我创办了 Chainguard，试图以商业化、规模化的方式把这些事情都做起来。我说这些不是为了炫耀，而是因为我需要你相信我：世界消费开源软件的方式从根本上就是有缺陷的，任何渐进式改进都不足以在时间内解决问题。

至少不是现在这种形式。也许永远都不行。它必须改变。

过去很多年里，大多数公司一直在免费消费开源软件，却几乎没有真正思考过这件事。现代应用是层层依赖堆起来的，而当其中某一层出问题时，修复会沿着整个 stack 级联扩散。对于拥有大量 legacy codebase 的大型组织来说，这不是一个下午就能修好的事。现在，快速推进本身也带来了风险。AI 也极大增强了 supply chain attack。若在没有仔细审查的情况下急着修补一个漏洞，你可能会安装比原始问题更糟的 malware。

维护者一侧更难。尤其是那些数量庞大、真正关心并愿意帮忙的维护者。也有很多人不愿意这么做，这完全没问题。他们对下游并没有义务。互联网上一些最关键的软件，是由一两个业余时间维护的人在维持。多年下来，自动化扫描器和 AI 生成的报告已经用大量低质量噪音把他们淹没了。与商业软件不同，开源维护者没有合同，也没有 SLA。无法保证补丁会被编写、合并，甚至无法保证相关人员能联系上。

协调漏洞披露（coordinated vulnerability disclosure）是为另一种世界设计的：在那个世界里，发现一个严重漏洞需要数周的专家工作，而且目标只是少数几个知名项目。现在，一个模型一夜之间就能在长尾项目里找到数百个漏洞。现有体系跟不上。对于那些得不到修补的漏洞，我们都需要一个备用方案。

真正需要做什么

我们需要 Plan A，也需要 Plan B。

Plan A：真正能规模化运作的协调披露。由一个可信的单一机构来路由经过充分验证的报告和补丁回流到 upstream，并支持那些愿意接受帮助的维护者。不是十几个相互竞争的组织去提交噪音工单。要有一个维护者会识别、也会信任的协调行动，让他们的报告能被顶到每个收件箱的最前面。现在，Glasswing 设法让大约 6% 的发现被 upstreamed。这个项目永远不可能达到 100%。这不是开源长尾的运作方式。我的最佳估计是，在严格时间压力下，我们最多也只能让大约 50% 的项目实现正常的协调披露，而且要达到这个目标还需要大量工作。

Plan B：我们如何处理剩下的部分。而且这不是一个清晰的二分法。有一大片混乱的中间地带：有些项目维护者会回应，但无法在时限内发布修复；有些项目虽然有补丁，但下游没人接收。对于这些情况，以及那些维护者根本无法或不愿打补丁的项目，我们需要一个最后维护者（maintainer of last resort）。开源赋予你 fork 的权利。你可以接手一个项目，承担 stewardship，并让它独立继续存活。对已死或无响应项目进行 fork，这种事每天都在发生。但在一个有数百个漏洞、由几十个组织同时报告的世界里，我们需要在一个地方集中管理这些能让最终用户信任的 forks。这将涉及艰难的决定和伤人的感受，但这是避免 fragmentation 的唯一办法。

一年前，这在规模化上还不可能实现。现在可以了。正是造成这场危机的同样 AI 能力，让最后维护者这一角色变得可行。这个职能需要安放在一个可持续获得资金、有人手、保持中立并且值得信任的地方。

修复 dependency tree 的最佳时机是 20 年前。次好的时机就是现在。俗话说：如果你想走得快，就一个人走；如果你想走得远，就一起走。问题是，我们既需要快，也需要远。

道路上的三个分叉

那么我们到底该怎么做？这件事会有三种走向，取决于你认为这问题有多少该由别人解决，以及我们要花多久才会意识到没人会来救我们，并真正把事情理顺。

天真路线：什么都不做，只是祈祷。Glasswing 把一切都 upstream 修好了，你的供应商神奇地把每个 workload 都 sandbox 起来，确保没有任何东西能逃逸，你的团队把遗留 deployment pipeline 重写成每 60 秒发布一次，你的 CISO 自 2014 年以来第一次能睡个安稳觉。每个维护者都会在 24 小时内回应每一次披露。每家公司都会在补丁落地当天更新所有依赖。没人引入 regression。没人安装伪装成补丁的 malware。我想生活在这个世界里。我们并不生活在这个世界里。

混乱路线：没人做集中化。每家大型云服务商都 fork 出自己版本的关键库，每个版本都有自己的 patch set。三家不同的安全厂商各自发布同一个 logging framework 的竞争性 fork。你的团队最后只能想办法搞清楚，哪个 fork 的哪个版本修了哪些 CVE，以及它们是否又引入了新的 CVE。这就是我们什么都不做时的默认结局。

硬分叉路线：有意识、协调且痛苦地决定，为开源消费构建新的信任基础设施。一个能规模化运作的披露流水线。一个可信的、用于维护 forks 的地方。对哪些项目应该 fork、哪些 forks 应该存活作出艰难决定。这是最困难的选项，也是唯一真正可行的选项。

开源一直都有这样的机制。当一个项目无法或不愿适应时，你就 fork 它。你接手 stewardship，完成工作，然后继续前进。规则一直都是这样。一直如此。

现在不同的是规模。我们谈的不是 fork 一个项目，而是构建一套能够 fork、维护并分发成千上万个项目的基础设施。在时间压力之下，而且另一边还有真实对手。这就是我们所有人必须做出的、最艰难的 fork。

正是造成这场危机的同样 AI 能力，也让这一切成为可能。软件将以一年前根本无法想象的方式改变，而我认为，在另一边会有一个更光明的未来。

这一切真的会奏效吗？老实说，我也不知道。但我们必须开始。正如 Programmer's Credo 所说：“We do this not because it is easy, but because we thought it would be easy when we started.” 这次甚至在一开始就感觉不轻松。

在 Chainguard blog 获取最新消息。

注：本文由 Chainguard 首席执行官兼联合创始人 Dan Lorenc 撰写并贡献。