在现代企业的代码库中，约有90%是开源的。银行、医院、电网、电信运营商、云平台，甚至你每天使用的AI服务，都建立在由相对较小的创作者群体实际编写的代码之上。其中很多工作是由志愿者和小团队完成的，他们构建了全球基础设施。这一模式非常有利于创新，但在应对时间敏感型的维护和支援时却未必能扩展开来。换句话说，“关键基础设施”与“尽力而为的基础设施”这两个概念并不总是兼容的。多年来，我们对开源代码的消费速度远远超过了我们在保障其安全方面的投入速度。

如今万物互联，一个冷门库中的漏洞不会局限于局部，而是会波及成千上万的下游应用。最近的情况发生了变化：人工智能正在大幅缩短发现漏洞所需的时间。过去需要熟练研究人员花费数周才能完成的工作，现在几分钟就能搞定。Anthropic的“玻璃翼”（Glass Wing）项目就是一个很好的例子，它在400个开源项目中发现了2300个漏洞。数量巨大。其中有一个bug，在一个开源操作系统中平白无故地存在了27年之久。时间很长，没人发现它，但AI发现了。

漏洞的发现速度远远超过了我们传统的修复方法。一个令人不安的事实是，攻击者也拥有类似的漏洞发现能力。因此，随着双方发现速度的加快，真正的瓶颈已不再在于找到缺陷本身，而在于找到之后所发生的一切。这是一场竞赛，现在的关键是谁能率先冲过终点线：是拥有妥善应用的补丁的好人，还是拥有毁灭性利用手段的坏人。

得益于最新的前沿AI模型，发现漏洞相对容易。但修复它则是另一回事，而且安全地做到这一点非常困难。一旦你知道了某个缺陷，你还必须弄清楚许多事情：你需要知道哪些版本受到影响；需要能够映射各个组件之间可能存在的依赖关系。你必须弄清楚它的业务影响是什么：如果我应用这个补丁，会不会导致业务中断？它是否会在错误的商业周期时间点产生影响？

然后我需要开发一个实际的修复方案，以便稍后发布。我必须测试这个修复方案：回归测试意味着回去检查是否破坏了其他功能。不仅要确认它解决了我们遇到的问题，还要看它在过程中有没有引入新问题。接着我需要验证该特定修复方案的兼容性：确保它能在所有我认为它会部署的不同系统上正常运行。最终，我们要将补丁部署到生产环境中，而且必须在不破坏任何东西的情况下完成这一操作。

这里有很多环节在运作，涉及百万个移动部件。在实际环境中，仅仅升级到最新版本是不现实的。我们还有其他考量因素：我们必须考虑依赖冲突、监管约束以及可能叠加在其上的自定义代码等因素。因此，团队往往需要量身定制的后向移植补丁或经过验证的替代修复方案，而不是教科书式的答案。这需要真正的工程判断力。

AI可以提供帮助，但无法完全取代熟练软件工程师的作用。因此，发现更多漏洞当然是件好事，因为它让我们有机会在漏洞被利用之前进行修复；但这只有在我们可以扩大修复规模并跟上速度时才成立。换句话说，仅仅发现更多漏洞并不会自动让任何人更安全。事实上，如果生态系统无法吸收所有这些修复的数量级，情况甚至可能变得更糟。

既然我们不能让所有漏洞或发现工具凭空消失，我们就需要一种新方法，以匹配日益增长的问题空间规模。信任始于上游：我们需要回到开源的源头。开源项目承载着多年的架构决策和机构知识，AI模型无法仅通过查看代码就直接推断出来。人类维护者对于验证修复方案不会破坏其他功能至关重要，他们需要了解可能产生的二级效应，并在长期内保持项目的稳定性。

当有人将修复方案贡献到上游代码库中，而不是仅仅在自己的私有分支中进行修改时，他们实际上是在为整个生态系统中的其他人加强安全性，使大家都能受益。此外，孤立的分支会为我们带来碎片化问题，这与我们真正需要的背道而驰。但关键在于：没有任何一家公司——无论其AI或研究人员多么出色——能够独自保障开源安全。

这需要人工智能提供商、软件供应商、云平台、安全公司、维护者以及非营利基金会之间的协调努力。需要许多人参与才能使这项工作取得成功。Lightwell和Akrites正是基于这种理念而建立的。Lightwell专注于识别、验证工程化企业环境中遭遇的漏洞修复方案，并尽可能将这些修复贡献到上游代码库。

Akrites则专注于问题的另一半：协调发现、维护者参与，以及减少可能存在的重复工作。两者共同代表了连接整个管道：从发现到修复，再到验证、披露，最终部署。这样，一切都在协调的工作流中运作，而不是各自孤立工作。以下是Lightwell实际工作流程的快速概览：首先是发现阶段。我们在开源软件中发现漏洞，包括那些可能深埋在企业应用栈内部的软件中的漏洞。

接下来，我们利用AI帮助分析漏洞和受影响的代码，确定漏洞的实际作用、如何利用它进行攻击以及需要做出哪些更改。然后，我们开发安全修复方案。与其强制客户升级到全新版本，该修复通常可以后向移植到他们正在运行的现有版本。但提出的补丁并非自动获得信任：AI辅助开发与工程审查测试相结合，以确保修复方案在解决漏洞的同时不引入新问题。

一旦通过验证，该补救措施将通过Lightwell的可信软件仓库提供，允许组织……

将其整合到现有的部署和修补流程中。最后，我们将修复方案向上游提交。该修复可以被贡献回开源项目。这意味着补救措施不会仅作为私有补丁存在，它最终将使所有使用该软件的受益者获益。因此，虽然 Lightwell 是一个可信修复方案的存储库，但 Akrites 更像是一支共享的安全事件响应团队。

其网站称，它为关键基础设施利益相关者提供了一个机密且结构化的平台，以协调他们依赖的开源项目中的漏洞发现、补救和披露工作。鉴于 AI 辅助攻击者目前的运作速度——这一点至关重要，因为攻击者的行动迅速，我们也必须同样快速。每一项发现都遵循相同的路径，以便上游维护者面对的是一个可预测的合作伙伴，而成员则获得一致的 embargo 处理。

他们是如何做到的呢？首先进行接收，然后进入重复性检查和验证阶段，接着是补救措施，最后是同步披露。这些步骤共同提供了一种更快捷的方式，让每个人都能从更安全开源软件中获益。因此，真正的要点在于：

未来开源安全的定义将不再取决于谁发现了最多的漏洞。AI 已经使发现变得容易，真正的挑战在于谁能以安全、负责任且可扩展的方式修复生态系统并补救这些漏洞。Lightwell 和 Akrites 等举措旨在帮助我们应对在我们共同依赖的庞大开源代码库中发现和修复 bug 的数量与速度。

竞赛已经开始，现在好人阵营也有了几位强力援手。这真是我们的福音。请务必充分利用这些新功能，在您的组织中实现大规模的安全提升。欲了解更多信息，请查看下方描述中的链接。