有人可能会声称，AI 审查代码已经解决了我们所有的安全问题。并非如此。但共享代码库为每个人都能使用的错误修复创建了一个中央仓库。

　　“无 bug、安全的代码如今可以实现”——这是个好想法，只是碰巧错了。

　　这一雄心勃勃的声明，是对 Eric Raymond 关于 AI 辅助漏洞发现乐观态度的 80 多条回复之一。Raymond 认为，既然人类编写的代码语料库是有限的，那么其中的缺陷也是有限的。有了“一百万个友好的机器人”来帮忙修复，我们就有能力借助 AI 来保护我们的软件。我完全支持这个方向。问题在于，我们把它当成一场终将完成的漏洞狩猎。今天的工具正在揭开昨天代码中的漏洞。凭什么假设明天的工具不会对我们今天认为安全的软件做同样的事？

　　对于我们这些花了几十年争论开源的人来说，这是一个有趣的发展。Raymond 普及了 Linus 定律：“只要眼球足够多，所有 bug 都无所遁形。”但提供源代码从来不能保证有足够多合格的眼球；实话实说，真正愿意去看的人少之又少。AI 终于让更多眼球发挥作用了，只不过它们碰巧是机器之眼。

　　开源的机会在于我们接下来选择做什么。我坚信，我们今天比以往任何时候都更需要开源：共享代码库为一代代错误猎人提供了一个地方，让他们贡献每个人都能使用的修复。正如我最近在 All Things Open 主题演讲中所说，这也是我们集体决定哪些软件重要、以及为什么重要的一种方式。当生成另一个代码库变得容易时，这个选择更重要。

　　漏洞狩猎并未结束

　　正如我所写的，开源代码从未如此安全。很少有人检查过它。优势在于，当有人发现问题时，代码和流程足够开放，可以对此做些什么。

　　AI 让发现环节变得更加有趣。2024 年 11 月，谷歌报告称，在已经历数十万小时模糊测试的项目中，使用 AI 生成的模糊测试目标发现了 26 个漏洞。3 月，Mozilla 与 Anthropic 合作，在 Firefox 中发现了 22 个安全漏洞，其中 14 个被评为高严重性。这是一个受到大量审查的软件，但大语言模型仍能更深入地审查。这令人印象深刻，但也是宣布软件漏洞终结的奇怪基础。这些发现的教训是：我们的信心已经超过了我们检查代码的能力。更好的工具暴露了差距，但它们百分之百没有确定没有剩余差距。

　　Raymond 的有限代码论证无法让我们绕过这个问题。即使我们冻结一个代码库，并承认其缺陷是有限的，这也不意味着今天的工具能全部找到它们，更不能证明它们已经找到了。哦，顺便说一句：我们并不会冻结生产软件。并非真的冻结。我们会更改代码、升级依赖项，并连接原始开发者从未想到的系统。Raymond 帖子下那些乐观的评论者也承认，错误会残留在系统及其复杂行为之间的交互中。而这是例外吗？不，甚至可以说大规模存在。对企业而言，这些交互正是它实际依赖的软件。

　　这些都不能使修复变得毫无价值。Mozilla 表示，全部 22 个安全漏洞都已通过发布修复，并得益于附带小型、可复现测试用例的报告。我们可以在不达到某种永久安全状态的情况下变得更加安全。但仍然必须有人验证调查结果，并修复人们可以使用的软件。这就是开源论点变得更强的地方。更好的工具会不断发现我们错过的东西。共享项目让我们可以一起进行修复，而不是每家公司花钱在自己的私有版本中重新发现和修复同样的问题。

　　可读软件只是起点

　　有一个相关论点是，AI 辅助的逆向工程使源代码访问变得无关紧要。也就是说，如果机器可以从二进制文件中重建有用的代码，那我们不是实际上让一切都开源了吗？嗯，不是。在别人的服务器上运行的软件不一定给你一个二进制文件来检查。合理的重建并不自动等于忠实还原。9 月的一份研究预印本发现，一些 LLM 反编译的函数通过了提供的测试，却在其他合法输入下表现不同。看起来干净的代码和原始程序不一定是同一回事。

　　即使假设逆向工程变得更好，反编译器也不会给你项目的测试、设计讨论、构建环境或历史记录。它肯定不会给你开源许可证。能够阅读实现，并不自动授予你修改和再分发的权利。

　　这些权利很重要，因为它们允许你用找到的东西做更多事情。你可以在上游贡献修复，或在必要时维护分支。专有供应商也可以运行出色的 AI 审计；通用代码库并非开源独有。区别在于谁可以参与维护它，以及这项工作是否可以独立于原始供应商继续进行。

　　所以我不会取消源代码访问的价值。更好的机器之眼让可用的源代码更有价值。但更大的机会一直在于围绕它的项目：人们决定什么值得维护，并共享工作。

　　我们仍然需要维护软件

　　PHP 10 月 21 日的安全发布让这一点非常具体。一位开发者在 2024 年发现了一个潜在问题的迹象。原则上理解了其潜在可利用性，但没有具体的攻击路径。修复涉及兼容性、性能和第三方扩展方面的艰难权衡。有限的专家资源和停滞不前的协商一致进程使工作无法向前推进。

　　AI 辅助的研究随后证明了该问题的全部影响。PHP 基金会和维护者协调了跨支持版本的修复，基金会承认了资源和决策方面的失误。更多机器之眼有助于让危险变得具体。它们没有决定接受或组织发布哪种兼容性成本。人们做到了。是的，人们。我们一直在谈论把人们从软件开发中自动化掉，而这项工作不断说明，为什么我们需要了解软件并能对此做出决定的人。

　　我们还需要停止纵容“AI 消除了共享代码需求”这种愚蠢言论。“我可以用 Claude 构建完全适合我个人需求的软件”听起来很棒，直到这些需求包括在未来十年维护数据库、操作系统或办公套件。很少有企业愿意对这一切负全部责任，但代理可以很快产出第一个版本。

　　在开源方面，正是出于这个原因，我主张将客户修复引入主项目。私有补丁解决了今天的问题，同时让其所有者负责完成未来的每一次升级。完全私有的代码库使责任大大增加。廉价的代码生成并不能使持续维护免费。

　　设想一个代理修补了库中的授权缺陷。在共享项目中，该修复可以成为回归测试、受支持版本和每个下游用户的更新。而有一百个私有重写，就有一百个团队必须确定他们是否有同样的问题，以及他们的修复是否有效。AI 可能会让这项工作更便宜。但选择重复一百次，似乎仍然是对进步的一种奇怪定义。

　　共享代码也有成本。广泛部署的依赖可能广泛传播缺陷；在用户安装之前，仓库中的修复不会保护任何人。这就是为什么我们要支持维护者并认真对待更新，而不是假设公共代码会自行处理。

　　Raymond 是对的：防守方需要更好的工具。但这些工具越强大，坚持用一堆定制软件取代成熟的共享项目就越显得奇怪。如果明天的机器人会发现今天的机器人错过的错误，我宁愿有一个共享项目，准备好对它们做些什么。