AI发现漏洞，谁来修补你的EOL Java代码？
今年早些时候，一个AI模型在OpenBSD的TCP协议栈中发现了一个潜伏了27年的漏洞。同一次扫描还揪出了FFmpeg的H.264代码中一个存在了16年的bug。
对于AI被用来大规模、全方位地发现开源软件中的漏洞，你作何感想？
因为这就是正在发生的事情。处理那些有活跃维护者的代码中，由机器速度发现的漏洞已经够棘手了。那些没有友善的“安全之手”照看的代码又该怎么办呢？
过去几周，我一直在核实大量关于AI与漏洞发现的说法。我预料到会有炒作成分，也确实不少。但刨去这些，数字依然令人警觉。
发现不再是难点
这些令人瞩目的数据来自Anthropic的Project Glasswing更新。他们的前沿模型扫描了超过1000个开源项目，标记出超过23000个潜在漏洞。
独立安全机构已对第一批高危和严重级别的发现进行了分类，并确认其中约90%为真实漏洞。
530个漏洞已披露，约75个已修复
在向开源维护者披露的约530个高危/严重漏洞中，前几个月只有约75个被打上了补丁。
这种差距有一部分可以理解。但关键的是，维护者（其中大部分是志愿者）已经请求Anthropic放慢速度，因为他们跟不上节奏。
修复一个高危漏洞（据Anthropic称）大约需要熟练人员两周的工作量，而机器几秒钟就能发现它。你可以自己算算账。
这就是新时代：机器速度的漏洞，人类速度的修复。
NCSC表示要为补丁浪潮做好准备
英国国家网络安全中心（NCSC）已经预见到了后果。今年5月，NCSC首席技术官Ollie Whitehouse警告所有组织做好准备迎接“漏洞补丁浪潮”：随着AI对几十年的技术债务进行“强制纠正”，整个软件栈将迎来一波软件更新。
这些建议很明智，但执行起来很痛苦。采用默认更新策略；首先修补外围系统；尽可能实现自动化。
如果你运行的所有软件背后都有支持机制——无论是开源维护者的默认选项还是商业合同——那你就成功了一半。
另一半是自动化的构建、质量保证和部署系统。
即将到来的变更数量前所未有。如果需要人工来应用和验证每次更新，那么麻烦就在眼前。
仔细阅读救助计划的小字
Linux基金会于6月启动了Akrites：一个面向开源维护者的共享安全事件响应团队，由AWS、Google、Microsoft、Anthropic、OpenAI等机构支持。
Chainguard的Athena联盟为其成员开展类似工作。
美国白宫现在运营着自己的漏洞信息交换中心。
目标是让修复方案得到验证、去重并协调分发给维护者，这比用成千上万个PR淹没他们要好得多。
没有人希望联盟违背维护者的意愿分叉项目，但这是一种可能性。
然而后果依然存在：行业越擅长修复受支持的软件，相比之下不受支持的那些软件就显得越脆弱。
修复按维护者的节奏到来
为什么？看看Akrites如何描述自己的流程。修复方案会回流到每个项目的原始仓库，按照维护者的节奏。即使是针对已无人在维护的软件包的“最后维护者”条款，也承诺只为最新版本提供修复。
那么，维护者的节奏究竟是什么？你正在运行的版本呢？
Spring上游团队修复受支持的分支；他们不会复活Spring Boot 2.7。Jackson项目修补当前流。AngularJS多年前就已归档。
当信息交换中心将协调好的修复方案向上游推送时，它只会到达维护者仍在支持的版本。
停止支持（EOL）的版本很可能得不到修复，甚至在CVE中都不会被提及，因为维护者作为一个群体不会为他们不修复的软件流发布CVE。
但攻击者会知道。
你的开源软件资产正变得越来越危险，而且按设计，没有人会告诉你。
对于大部分Maven Central来说，已经没人了
为了说明这一点，我查了Maven Central的数据。在我看过的大约85万个软件包中，超过一半在过去两年中没有发布过任何版本。
这些项目是已完成还是已废弃，对你来说没有区别；这两种情况都不会在14天内处理CVE。当信息交换中心寻找上游维护者时，对于仓库中的大部分软件，那里已经没人了。
为什么Java团队身处冲击区
当然，这并非Java独有。Sonatype在2024年前后的分析显示，所有生态系统中只有约11%的开源项目有任何维护活动的迹象。
既然这是Foojay，让我们更仔细地看看Java。
首先，安装基数。Java的巨大优势在于应用程序能运行几十年。这意味着有大量Spring Boot 2.x、旧版Jackson、遗留Struts和Java 8仍在生产中稳定运行。如果一家公司还在运行旧版Java，那么很可能其他大部分软件版本也很旧。
Azul的2025年Java状况调查发现，近五分之一的组织仍在运行Java 6或7。Java 6于2006年发布（我对此记忆犹新）。
旧代码不是避风港
AI扫描新旧代码一样起劲。那个存在了27年的OpenBSD bug告诉我们，模型才不管某个东西在那里安静待了多久。你喂给它什么，它就处理什么。当然，发现古老漏洞是绝佳的公关素材：看看AI有多强大，找到了人类几十年都没发现的问题。
这可能是公关宣传，但也有其内在真相。AI正以工业化的速度发现比人类更多的漏洞。如果你以为这会逐渐消退，那我有个坏消息：目前AI只找到了最简单的漏洞。那些跨越模块边界的更复杂问题，我们还没触及呢。
当挖掘简单漏洞就能找到大量“宝藏”时，为什么还要花钱去追查复杂缺陷呢？
Spring中已可见端倪
Spring生态系统仅在6月就发布了67个CVE，其中27个为高危。而2025年全年只有17个。
真正的风险在于Broadcom不再评估影响的版本：Spring Boot 2.7系列项目的漏洞目录中已有97个CVE，而且还在增长。今年早些时候一批7个jackson-databind反序列化CVE也讲述了同样的故事。
攻击者先行，审计员紧随其后
CrowdStrike的2026年全球威胁报告显示，在公开披露之前就被利用的漏洞增加了42%。
攻击者还能在几小时内逆向分析已发布的补丁。如果Spring 6发布了修复，而你的应用运行在Spring 5上，那么那个补丁提交就是一份免费的漏洞利用路线图，直指你的系统。
合规机构也注意到了。在英国，4月生效的Cyber Essentials更新将关键补丁的14天窗口期作为自动认证失败的条件。范围内的设备上若存在不受支持的软件，则直接不合格。新的问卷要求总监级别的人员签署声明，保证全年维持控制措施。现在有人要为此负责了。
美国联邦供应商面临CISA新的基于风险的指令，对于最严重的情况需要在72小时内处理。记住，审计员的扫描器读取的是和攻击者相同的CVE源。
四项实际措施
准确盘点你的EOL风险敞口。 大多数SCA工具对支持状态只字不提。你可能会收到CVE警告，但解决它是你自己的问题。你真正需要知道的是，你的依赖项中哪些有上游会提供修复。专用的生命周期结束数据集可以填补这一空白。全文披露：我为HeroDevs工作，我们拥有这些数据。
对仍有上游支持的版本采用默认更新策略。 NCSC说得对。如果你在使用受支持的版本，就把无聊的补丁自动化，让人力专注于难题。
对每个EOL组件做出明确决策。 有四个选项。立即迁移。自行修补（即分叉代码并永远维护）。购买商业支持（例如HeroDevs的永不结束支持）来维护EOL版本。或者隔离系统并书面接受风险（审计员会要求看到书面记录）。
每种方案在特定情况下都有其正确性。
而放任自流、什么都不做是唯一错误的答案，但大多数组织的默认状态正是如此。NCSC的指南要求替换遗留系统或将其恢复至供应商支持状态。
压缩你的响应时间预期。 无论你在2024年设定的补丁SLA是什么，现在它已经过时了。做好在几天内部署关键修复的准备，并准备好应对CVE成批到来而非零星出现的情况。
水位已在上涨
补丁浪潮常被当作未来事件来谈论。对于生命周期结束的Java，它几个月前就开始了；jackson-databind那批漏洞和6月份的Spring数据就是前锋。信息交换中心、联盟和AI实验室正在构建一个工业化的发现与修复系统。
一个针对还有人在修复的软件的系统。
数据说明：Maven Central分析涵盖849,571个软件包和2090万个发布版本。如果一个软件包在过去两年内没有发布任何类型的版本，则被视为不活跃：457,087个软件包（54%）符合此定义。这是故意采用粗略的启发式方法；一个两年内没有任何发布的项目，不可能在14天内为你提供安全修复。
Steve Poole是Java Champion兼HeroDevs开发者倡导者，该公司为生命周期结束的开源软件提供安全支持。他的博客在noregressions.dev。
本文AI发现漏洞，谁来修补你的EOL Java代码？最初发布在foojay上。