Azul《2026 年 AI 漏洞差距报告》发现：企业修补速度落后于 AI 威胁

Azul 的《2026 年 AI 漏洞差距报告》发现，安全负责人认为配备 AI 的攻击者能够迅速采取行动，而其所在组织部署修复程序所需的时间却与之不匹配。在一项针对 300 名美国安全负责人的调查中，69% 的受访者表示，攻击者能够在三天内构建出可用的漏洞利用程序；与此同时，44% 的受访者表示，其组织需要四天或更长时间，才能在生产环境中修复一个严重漏洞。

报告最引人注目的发现，是受访者将这些延迟与自身经历联系起来：85% 的受访者表示，曾发生过可归因于修补缓慢的安全事件、疑似安全事件或险些发生的安全事件。这个数字反映的是受访者报告的经历，并非经过独立核实的违规事件发生率；它也不能证明这些事件是由 AI 导致的。

这项研究由 Azul 委托 Censuswide 开展，重点调查大规模部署 Java 的组织。报告传递的更广泛信息关乎运营实践：发现漏洞只是第一步。修复程序必须经受住测试、部署到受影响的系统，并消除整个系统环境中的暴露风险，而团队未必能完全掌握该环境的情况。

两种不同步的时间尺度

这项调查分别考察了安全负责人对攻击者的预期，以及其所在组织自身的部署能力：

• 69% 的受访者认为，配备 AI 的攻击者能够在三天或更短时间内构建出漏洞利用程序，其中 22% 的受访者认为所需时间不到 24 小时。
• 56% 的受访者表示，其组织能够在三天内将严重补丁部署到生产环境：其中 13% 表示不到 24 小时，43% 表示需要一至三天。
• 44% 的受访者表示需要更长时间：32% 需要四至六天，12% 需要更久。

这些数字反映的是调查答复的分布，并非对攻击者利用相同漏洞攻击特定组织的速度进行的实测。两者之间的差距令人担忧，也说明组织的准备程度存在问题；但不应将其解读为每家企业都面临一个精确的三天暴露窗口。

以一天为界限，也能看到同样的不平衡：22% 的受访者预计攻击者能够如此迅速地采取行动，而表示所在组织能在这一时间内部署修复程序的受访者仅占 13%。与此同时，59% 的受访者承认，尽管 AI 驱动的攻击工具加剧了风险，他们却没有调整安全态势。

测试是造成延迟的重要因素

在 58% 的受访组织中，测试 Java 运行时更新会让补丁周期延长四天或更久。其中，36% 的受访者表示需要四至六天，22% 表示需要一周或更长时间。另有 33% 表示需要一至三天，9% 表示不到 24 小时。没有受访者表示跳过了测试。

运行时变更可能影响许多应用，因此测试有其实际必要性：安全更新若导致关键服务中断，就会带来另一个运营问题。报告指出，更新范围也加重了这一负担，因为完整的 OpenJDK 季度版本可能会在修复漏洞的同时包含非安全性变更。

Azul 另行评估了超过六年间发布的 26 个 OpenJDK 季度更新，并将其中六个归类为导致严重回归的更新。这个 23% 的比例是该供应商对版本发布情况的评估，并非对单个客户应用发生故障频率的调查估算。

在受访者报告的加快修补速度的主要障碍中，44% 提到了大量测试工作，40% 提到了受影响系统的复杂性或老旧程度，36% 提到了对已知漏洞的可见性有限。25% 的受访者提到了供应商延迟发布补丁。整体来看，修复工作面临的许多挑战都源于企业自身的部署流程。

事件报告与资产清单缺口需分别解读

55% 的受访者报告称，曾发生过可归因于修补缓慢的已确认安全事件；53% 的受访者报告称，曾险些发生此类事件。受访者可以选择多个答案，因此这些数字存在重叠，不应相加。85% 这一更广为引用的总体比例还包括疑似安全事件。

这项调查并未证明所有这些事件都涉及 Java 漏洞。受访者所在组织大量使用 Java，但研究既涉及更广泛的软件修补问题，也包含专门针对 Java 运行时的问题。

资产清单是另一项难题。只有 19% 的受访者表示，其生产环境中的 Java 运行时资产至少有 90% 已达到最新安全补丁级别。这意味着 81% 的受访者未达到这一门槛，但不代表他们有 81% 的运行时都没有更新到当前版本。大约五分之一的受访者表示，其资产中只有一半或更少已更新到当前版本。

另有 51% 的受访者承认，他们对关键 Java 运行时的可见性不完整或有限，其中包括嵌入式、遗留和非托管实例。要在打包应用或容器中找到存在漏洞的运行时，可能比识别由中央统一管理的安装实例更困难。如果部署流程从未触及某个系统，补丁就无法消除该系统的暴露风险。

Azul 的技术为讨论带来了什么

Azul 的安全更新服务仅为选定版本提供安全修复，并以此前已稳定的 OpenJDK 版本为基线。该公司提供季度更新、定向月度更新和周期外更新，旨在减少企业部署紧急修复时需要评估的无关变更。

这是一种范围较窄的技术干预，并不意味着可以免除变更控制。限制代码变更可以缩小验证范围，但仍需进行针对应用的检查、明确部署责任，并做好回滚准备。Azul 是这份报告的赞助方，同时销售旨在解决报告所衡量问题的产品。

其 Java 资产清单和漏洞管理工具针对工作流程的另一环节：识别运行时环境、版本和风险暴露情况，以便在有新的漏洞信息披露时，将其对应到受影响的系统。报告没有提供受控对比，以证明受访组织采用这些产品后能在多大程度上改善情况。

Azul 联合创始人兼首席执行官 Scott Sellers 表示：“我们的研究表明，安全负责人了解相关威胁：认知已不再是短板，执行才是。”

将修补意愿转化为可衡量的流程

对于未来一年，32% 的受访者将更快、更频繁地修补漏洞列为降低风险暴露的首要策略，另有 26% 的受访者倾向于完善软件和运行时环境清单。还有 17% 的受访者优先考虑检测与响应，而非加快修补速度。

研究建议追踪从漏洞披露到修复的整个流程：哪些系统受到影响、由谁负责、需要进行哪些测试，以及修复是否确实部署到了生产环境。只有当团队能够确认相关系统资产均已完成修复时，设定截止期限才有意义。

美国相关调查结果来自 2026 年 8 月 3 日至 7 日开展的实地调查，受访者是来自员工人数至少为 1,000 人且在生产环境中大量使用 Java/JVM 的组织的安全负责人。这些是特定人群的自我报告，而非对所有企业的普查，也不是对漏洞利用开发情况的直接测量。

完整的《2026 年 AI 漏洞差距报告》详细介绍了调查结果和方法。报告最明确的启示是，修补速度和运行时环境可见性需要同步提升：如果组织无法识别所有受影响的部署，也无法确认更新已部署到这些环境中，那么快速修复的价值就会十分有限。