2026年6月25日，Linux基金会发布了一封联合公开信，标题只有一句话：「We All Depend on Open Source. We Will Defend It Together.」
这封信的核心论点直白而紧迫：AI已经打破了攻防双方之间的平衡。过去，在一个主流开源项目中找到一个严重漏洞需要安全专家花数周时间。现在，机器可以在几分钟内完成同样的工作，甚至一次扫描就返回多个漏洞。
与此同时，一个名为Akrites的倡议正式亮相。它由Linux基金会牵头，联合了19家公司和基金会——Amazon Web Services、Anthropic、Google、Microsoft与GitHub、NVIDIA、OpenAI、Red Hat、Rust基金会等等，覆盖了从云计算、AI实验室到金融和电信的整条产业链。目标明确：在关键开源软件中协调漏洞发现、修复和披露，将补丁合入上游，再分发至下游关键基础设施。
用信中的话说：「Patch the commons together。」
AI打破了什么平衡
公开信描述了一个具体的场景：数十家公司独立扫描同一个开源库，各自提交一份漏洞报告。维护者的收件箱被淹没在重复的报告中。而每一个未被修补的已知漏洞，都是一个等待泄露的定时炸弹。
Endor Labs提供了一组数字：过去几个月里，通过AI发现的数千个已验证的开源漏洞中，只有不到5%得到了修补。OpenInfra基金会补充了另一个数据点：OpenStack社区在2026年第二季度发布了20个安全公告，而整个2025年只有2个。
信中将未公开的漏洞称为「实质上的武器」，并以此论证保密性的必要性：在补丁部署到位之前，漏洞细节不应公开。Akrites将提供一个「单一、可信赖的保密协调平台」，让维护者面对一个可预测的合作伙伴，而非一百个互不协调的报告。
Akrites还承诺了一项更具争议性的功能：当某个关键软件包无人维护时，它将扮演「最后兜底维护者」的角色，确保修复仍能触及所有用户。
签署者名单引发的信任危机
公开信在Hacker News上获得了446个积分和216条评论。讨论的热度很高，但共识很少。最集中的批评指向签署者名单本身。
「看到这个名单，大量开源社区成员会持怀疑态度——理当如此，」一位用户写道。他的担忧代表了相当一部分人的看法：名单上的公司中，有许多被社区长期批评从开源中大量获取却回报甚少。当这些公司站出来说要「防卫」开源时，信任不会自动产生。
实施路径是另一个焦点。这些公司会通过现有渠道提交PR与维护者协作（路径A），还是以安全为名义fork项目（路径B）？路径A能带着社区一起走，路径B则将社区割裂。「隔离社区对他们来说不是bug，是功能，」一位评论者尖锐地指出。
「保密性」这个词触动了开源社区最敏感的神经。开源的传统是代码透明、过程透明、讨论透明。一个由企业主导的、在保密协议下运行的漏洞协调机制，与这一传统的张力显而易见。有人将其描述为「实质上的集中化和控制行为」，担心这最终会演变为对关键开源软件包的隐形管控。
另一个反复出现的诉求更直白：与其组织共同防卫，不如组织共同出钱。一位评论者写道：「我渴望有一天能读到这样的标题——我们所有人都依赖开源，我们将一起资助它。」
防守方的逻辑
支持这一倡议的声音来自另一个角度。
一位Linux基金会员工（声明未参与Akrites内部工作）详细列举了他所在团队支持开源项目的具体方式：AWS提供的云计算积分、付费导师计划、聘请Trail of Bits进行安全审计、举办维护者面对面峰会、资助大型CI运行器。这些细节让抽象的承诺变得具体。
一个被反复提及的事实是：今天80%的Linux内核开发来自受薪的企业员工。Kubernetes也是如此。承载世界运转的开源基础设施，实际上已经在由这些公司维护。从这个角度看，Akrites并非企业侵入开源，而是已经在从事这项工作的人和组织之间建立协调机制。
还有评论指出，低质AI生成的安全报告确实在淹没维护者。「当前对开源最大的攻击是PR垃圾邮件和随之而来的信任崩塌，」一位评论者写道。如果Akrites能在协调层面过滤噪声——仅提交已验证、可复现的漏洞，附带经过测试的修复方案——这确实可能减轻维护者的负担。
从协调的角度，Akrites解决的是一个真实的问题：同一批代码、同一批缺陷、同一批加速发现它们的工具。各自为战不仅浪费资源，还会在生产环境中留下不兼容的补丁。
名称的来由
「Akrites」（Akritai的单数形式）源自拜占庭帝国时期驻守东部边境的边防士兵。词根「akron」意为「边界」或「边缘」——与英文中的「frontier」同源。Linux基金会在官网上试图将其与「critical」联系在一起，这很快被HN用户以词源学事实纠正。
命名在讨论中引发了细微的争议。有人指出，历史上前线的税收减免停止后，Akritai迅速消失——倘若这种模式被复制，当企业的免费AI使用额度耗尽后，协调机制还能持续多久？
更深层的伦理焦虑
讨论中浮现出的远不止安全机制的设计问题。一些人将其视为开源运动自身历史的回响。
一个反复出现的论点：从「自由软件」到「开源」的命名转变本身就是为了让企业更舒服地参与。MIT和Apache等宽松许可证的广泛采用，使得企业可以取用而后不归还。有评论者感慨：「如果AGPL当初成为默认许可证，软件产业的格局将完全不同。」
另一些人则提醒，不应将问题简化为「企业 vs. 社区」的二元对立。Linux内核的80%代码由企业员工贡献，但企业的方向与社区的方向是否总是一致，是另一回事。一个由Linux基金会发起的、仅限会员参与、需要签署NDA的协调机制——无论动机多么合理，都无法回避围绕治理和透明度的质疑。
窗口期
公开信的结尾带着紧迫感：「现在还有窗口期来应对新的开源安全风险现实，但这个窗口不会一直敞开。」
这句话可能是整封信中最无争议的陈述。AI确实在改变攻防节奏，维护者确实在被报告淹没，端到端的供应链安全确实需要一个比现状更有效的协调框架。分歧在于：谁来协调、如何协调、谁有权定义「关键」软件包、以及保密的边界在哪里。
Akrites给出的答案是集体行动。社区给出的回应是：证明它。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。