AI 正在改变软件安全流程的两端：研究人员可以更快找到漏洞，攻击者也可能利用公开线索，在修复更新普及前构造攻击。如今的核心难题不只是“能不能发现”，还包括如何核实问题、准备补丁，并让用户及时完成更新。3

发现速度上去了，确认和修复未必跟得上

Palo Alto Networks 向《经济时报》表示，AI 帮助其发现了逾 1.4 万个此前未被发现的开源软件漏洞，并在三周内完成了相当于一年人工渗透测试的工作量。19 这是公司的说法；现有材料并未提供独立验证的基准结果。

Anthropic 公布的数据也说明，发现数量增加，不等于同样多的问题已被确认或修复。该公司称，其模型在六个月内找到了超过 2.9 万个候选漏洞，但人工只审查和分流了约 6,000 个。 这几类数字不能混为一谈：候选漏洞未必最终成立，经过审查的发现也不等于已经由上游项目发布补丁。

Anthropic 的 OSS Scanner 面向符合条件的开源项目免费提供定期扫描，使用包括 Claude Mythos 在内的模型。项目加入后，模型生成的发现可以在未经人工预审的情况下送达维护者。 这或许能让潜在问题更早进入项目团队视野，但报告的数量和质量也因此格外重要。现有材料不足以核实其他报道所称的 10 月 2 日具体总数或上游修复数量。

瓶颈转向验证与打补丁

Anthropic 表示，人工审查能力限制了处理速度；TechTarget 则指出，扫描器可能把更多漏洞处理工作转移给项目维护者。 一条有价值的报告仍可能需要复现、评估影响、编写修复、测试回归，并协调发布。收到更多报告，不等于这些工作已经完成。

对安全资源有限的开源项目来说，优先处理能够复现、清楚说明受影响代码和潜在影响的报告，是更务实的做法。依赖开源软件的机构也可以为维护和安全工作提供资金支持；电子前哨基金会（EFF）就呼吁加大对开源项目的支持。 但现有证据并未核实关于维护者倦怠或特定项目人员配置变化的具体说法。

补丁发布与用户更新之间，可能出现攻击窗口

AI 辅助找漏洞有助于防守，但安全修复信息本身也可能暴露漏洞线索。Epoch AI 报告称，开源权重模型 GLM 5.3 利用已经公开、但尚未随更新送达用户的 Firefox 修复线索，对六个 Firefox 版本构造了可行攻击；按该机构估算，每次成功攻击的边际成本约为 1,000 美元。3

这是受控实验，并不意味着这些攻击已被用于攻击 Firefox 用户。不过，它展示了“补丁窗口”带来的风险：修复信息公开后，到用户实际收到并安装更新之前，可能存在一段时间差。二手报道指出，Mozilla 在 Firefox 159.0 中修复了相关漏洞。29

这并不是说公开修复本身不安全——用户需要补丁来保护自己。更实际的启示是，防守方必须考虑到技术细节可能很快被分析，因此及时部署更新十分重要。3

高补丁数量，也需要结合口径来看

微软 10 月的“补丁星期二”显示，统计口径会影响安全漏洞总数。微软发布说明列出 1,468 个 CVE，Veracode 对这次发布的统计则为 1,413 个；现有材料无法解释两者差异。 Veracode 还指出，此次更新修复了一个已遭实际利用的 Windows Shell 安全功能绕过漏洞。 仅凭总数，无法判断漏洞数量激增的原因，也无法得知其中有多少由 AI 发现。

另一个例子凸显了应对漏洞所需的速度：CERT-EU 称，PHP 项目在 10 月 20 日公布两项严重漏洞，并于次日发布修复。 路透社报道，七位网络安全专业人士警告，AI 发现的漏洞可能引发更多服务中断。17 这是对潜在后果的警告，并不能证明 AI 发现漏洞必然会导致事故。

发现更快，不等于安全必然更好

AI 可以帮助防守方更早找到弱点，但 Firefox 实验也显示，漏洞利用开发同样可能提速。3 现有来源无法判断总体上哪一方会因此获得更大优势。眼下最明确的优先事项，是把发现与有效分流、及时修复和广泛部署连接起来，避免不断增加的漏洞报告最终只变成维护者和用户面前更长的待办清单。

AI 正在改变软件安全流程的两端：研究人员可以更快找到漏洞，攻击者也可能利用公开线索，在修复更新普及前构造攻击。如今的核心难题不只是“能不能发现”，还包括如何核实问题、准备补丁，并让用户及时完成更新。3

发现速度上去了，确认和修复未必跟得上

Palo Alto Networks 向《经济时报》表示，AI 帮助其发现了逾 1.4 万个此前未被发现的开源软件漏洞，并在三周内完成了相当于一年人工渗透测试的工作量。19 这是公司的说法；现有材料并未提供独立验证的基准结果。

Anthropic 公布的数据也说明，发现数量增加，不等于同样多的问题已被确认或修复。该公司称，其模型在六个月内找到了超过 2.9 万个候选漏洞，但人工只审查和分流了约 6,000 个。 这几类数字不能混为一谈：候选漏洞未必最终成立，经过审查的发现也不等于已经由上游项目发布补丁。

Anthropic 的 OSS Scanner 面向符合条件的开源项目免费提供定期扫描，使用包括 Claude Mythos 在内的模型。项目加入后，模型生成的发现可以在未经人工预审的情况下送达维护者。 这或许能让潜在问题更早进入项目团队视野，但报告的数量和质量也因此格外重要。现有材料不足以核实其他报道所称的 10 月 2 日具体总数或上游修复数量。

瓶颈转向验证与打补丁

Anthropic 表示，人工审查能力限制了处理速度；TechTarget 则指出，扫描器可能把更多漏洞处理工作转移给项目维护者。 一条有价值的报告仍可能需要复现、评估影响、编写修复、测试回归，并协调发布。收到更多报告，不等于这些工作已经完成。

对安全资源有限的开源项目来说，优先处理能够复现、清楚说明受影响代码和潜在影响的报告，是更务实的做法。依赖开源软件的机构也可以为维护和安全工作提供资金支持；电子前哨基金会（EFF）就呼吁加大对开源项目的支持。 但现有证据并未核实关于维护者倦怠或特定项目人员配置变化的具体说法。

补丁发布与用户更新之间，可能出现攻击窗口

AI 辅助找漏洞有助于防守，但安全修复信息本身也可能暴露漏洞线索。Epoch AI 报告称，开源权重模型 GLM 5.3 利用已经公开、但尚未随更新送达用户的 Firefox 修复线索，对六个 Firefox 版本构造了可行攻击；按该机构估算，每次成功攻击的边际成本约为 1,000 美元。3

这是受控实验，并不意味着这些攻击已被用于攻击 Firefox 用户。不过，它展示了“补丁窗口”带来的风险：修复信息公开后，到用户实际收到并安装更新之前，可能存在一段时间差。二手报道指出，Mozilla 在 Firefox 159.0 中修复了相关漏洞。29

这并不是说公开修复本身不安全——用户需要补丁来保护自己。更实际的启示是，防守方必须考虑到技术细节可能很快被分析，因此及时部署更新十分重要。3

高补丁数量，也需要结合口径来看

微软 10 月的“补丁星期二”显示，统计口径会影响安全漏洞总数。微软发布说明列出 1,468 个 CVE，Veracode 对这次发布的统计则为 1,413 个；现有材料无法解释两者差异。 Veracode 还指出，此次更新修复了一个已遭实际利用的 Windows Shell 安全功能绕过漏洞。 仅凭总数，无法判断漏洞数量激增的原因，也无法得知其中有多少由 AI 发现。

另一个例子凸显了应对漏洞所需的速度：CERT-EU 称，PHP 项目在 10 月 20 日公布两项严重漏洞，并于次日发布修复。 路透社报道，七位网络安全专业人士警告，AI 发现的漏洞可能引发更多服务中断。17 这是对潜在后果的警告，并不能证明 AI 发现漏洞必然会导致事故。

发现更快，不等于安全必然更好

AI 可以帮助防守方更早找到弱点，但 Firefox 实验也显示，漏洞利用开发同样可能提速。3 现有来源无法判断总体上哪一方会因此获得更大优势。眼下最明确的优先事项，是把发现与有效分流、及时修复和广泛部署连接起来，避免不断增加的漏洞报告最终只变成维护者和用户面前更长的待办清单。