AI 正在超过人类修复漏洞的速度
ZDNET AI··作者 Steven Vaughan-Nichols
关键信息
文章强调，并非所有发现的问题都同样紧急：少数是正在被利用、需要立即处理的高危问题，而大量其他问题只是会消耗分流时间的背景噪音。文章还指出，AI 让人们更便宜地发现自己编写和使用的软件中的缺陷，这带来的更多是“数量失控”问题，而不只是技术问题。
资讯摘要
ZDNET 的分析认为，AI 正在以前所未有的速度加速漏洞发现，以至于人工团队已经难以跟上修复节奏。文章把这件事描述为既是好消息也是坏消息：发现了更多漏洞，但修复它们也变成了更沉重的运营负担。文章指出，传统安全流程默认高危问题的数量是可控的，团队通常会先处理 CVSS 评分较高的漏洞，并应对偶发的零日漏洞。现在，AI 让漏洞发现变得低成本且可扩展，并且可以覆盖各种软件和基础设施。文章提到，Apple 甚至开始限制研究人员可提交的潜在危险漏洞报告数量，这说明连大型厂商也已经被报告量压垮。
文章还引用 Microsoft 2026 年 7 月的 Patch Tuesday：当月共发布 570 个补丁，其中包括 3 个零日漏洞，说明补丁数量正在快速上升。Microsoft 自己也表示，随着 AI 帮助防御者发现更多问题，客户会在每次安全发布中看到更高数量的安全更新。Chainguard 联合创始人兼首席执行官 Dan Lorenc 则表示，AI 找到漏洞的速度已经超过防御者打补丁和修复漏洞的能力，这让原本就困难的问题进一步放大。文章最后得出的结论是，安全团队必须更积极地进行分流和优先级判断，因为海量报告本身已经成为一种风险放大器。
资讯正文
ZDNET 的重点结论
AI 发现的安全问题正像潮水一样增长。
无论是使用个人电脑还是运行数据中心，每个人都会受到影响。
我们还没有为即将到来的一切做好准备。
好消息是，AI 正在以前所未有的速度发现安全漏洞。坏消息也是，AI 正在以前所未有的速度发现安全漏洞。两者兼而有之：我们固然很高兴能发现那么多 bug，但要把它们全部修复，简直是一项庞大的工程。没错，如果你是 Google，你就能在 2026 年 6 月修复比过去两年里更多的 Chrome bug；但大多数公司不是 Google，也没有那样的资源去修复如此多的安全漏洞。
事实上，连苹果——没错，就是苹果——也已经被 AI 提交的 bug 报告压得喘不过气。因此，苹果在 6 月告诉安全研究人员，它“限制了研究人员可以提交给其内部安全团队的潜在危险软件漏洞数量。如果你发现了一个真正骇人的漏洞，但你已经超出上限，那也无济于事。下个月再试吧。
另请参阅：Google 如何使用 AI 代理在 60 天内发现并修复 1,072 个 Chrome 安全漏洞
因此，问题就来了。AI 辅助的漏洞发现正在加快 bug 报告的节奏，但真正的问题在于，机器能够挖掘出的内容，与人类实际能够分流、判断和处理的内容之间，差距正在不断扩大。于是，开发者、安全团队以及企业不得不承受越来越重的负担，去区分可被利用的漏洞和机器生成的噪音。不过，感到吃力的并不只是开发者。系统管理员、CISO 以及终端用户，也都被迫在一轮又一轮补丁中疲于奔命。
AI 安全潮汐
过去的安全工作流程，默认高价值漏洞会以相对可控的数量出现。你会查看 Common Vulnerabilities and Exposures（CVE）评分，并立即修补那些真正高危的漏洞。你也会希望某个零日漏洞不要突然出现，把你的一天搅乱。那是过去。现在不同了。
另请参阅：CrowdStrike 警告称，AI 既是网络武器，也是巨大的攻击目标
AI 打破了这一假设，因为它让大规模发现漏洞变得廉价。虽然开源程序占据了大部分头条，但这无论如何、从任何角度看，都不是一个开源问题。例如，微软 2026 年 7 月的 Patch Tuesday 发布了 570 个补丁，其中包括 3 个零日漏洞。这创下了纪录。我敢肯定，在今年结束前，这个纪录还会被打破。
为什么？并不是因为 Windows 比以往任何时候都更不安全。原因正如微软 5 月所解释的那样：“AI 帮助防御者发现更多问题，客户会在每次安全更新中看到更高数量的安全更新。”这些数字只会继续增加。
正如安全公司 Chainguard 的联合创始人兼首席执行官 Dan Lorenc 最近在一场网络研讨会上所说，AI 现在“发现其编写的软件以及其使用的软件中的漏洞的速度，远远超过了防御者打补丁、获取更新并修复漏洞的能力”。他指出，发现漏洞本来就总是比修复漏洞更容易，但 AI“在发明更好的灭火器之前，又往火上浇了一大桶汽油”。
这也让问题变得格外难以管理：并不是所有这些问题都同等重要。少数漏洞是正在发生的、紧急的、可被利用的，而更多漏洞则只是持续不断的修复背景噪音。安全团队被迫对这些问题进行分诊，而问题数量本身就成了风险放大器。比如，我过去常建议 Windows 用户暂缓给电脑打补丁，因为太多补丁最终都会出问题，比如 2026 年 1 月的 Patch Tuesday 更新。如今，随着零日攻击接踵而至，你可能别无选择，只能咬牙更新，并祈祷补丁本身不会把你坑了。无论好坏，正如 Linux stable kernel 的维护者 Greg Kroah-Hartman 所说：“如果你没有使用最新的 stable/long-term kernel 系统，你的系统就是不安全的。”如今，对 Windows、MacOS，乃至几乎所有程序来说，情况也都一样。
这不只是 Linux 的问题。你们有些人可能会觉得，这主要是 Linux 和开源软件的问题。其实不是。Linux kernel 之所以是最显眼的案例，只是因为它的维护者是公开且直言不讳的，而且他们本来就已经不堪重负。情况有多糟？7 月份，Linux kernel 在两天内就报告了 432 个 CVE。类似的情况也出现在专有软件中；只是公司没有告诉我们而已。你可以从它们的补丁和系统变得有多大看出来。没错，其中一部分是 Microsoft 在 Windows 中加入了更多 AI，但我强烈怀疑，很大一部分其实是在修补潜在的 AI 安全漏洞。
例如，Adobe 的 Acrobat Chrome 扩展安全失误 HermeticReader，只要访问一个恶意网页，就会暴露敏感的 WhatsApp Web 数据。这些网页看起来和其他任何网页没什么不同，但当你访问它时，陷阱就会触发，并在扩展中唤醒一个休眠程序。随后它会深入你的 WhatsApp，抓取你的聊天列表、联系人姓名、消息、个人资料名称，以及当前打开的任何对话的文本——你知道，几乎就是一切。
这次攻击是由 AI 将三种不同的漏洞串联起来实现的，它使得“任何网页都能在一次未认证、单次访问、零点击的情况下，向扩展自身的存储区写入内容”。雪上加霜的是，随后一名罪犯又通过 Hermes Agent 框架，使用 DeepSeek LLM 将这次攻击自动化了。另请参阅：微软全面押注新的 AI 驱动 Windows 安全战略
这场潜在灾难中唯一的好消息是，Adobe 很快发布了该扩展的更新版本，在造成过多损害之前修补了这个安全漏洞。我们不可能总是这么幸运。正如 Linux Foundation 首席执行官 Jim Zemlin 在北美开源峰会上所说：“如今，平均利用时间已经从 63 天崩塌到了 -7 天。攻击甚至在补丁发布之前就已经发生了。”这难道不“棒”吗？
分诊税
与此同时，AI 生成漏洞报告的另一项成本不只是误报；还包括证明这些报告是误报所需的时间。维护者仍然必须阅读它们、复现它们，并判断它们究竟是重复报告、幻觉，还是真正隐藏在糟糕表述中的漏洞。这是一种专家注意力税，而且在团队规模较小时打击最为严重。另请参阅：AI 正在变得可怕地擅长发现隐藏的软件漏洞——甚至包括数十年前的代码
这个问题影响的不只是维护者。它与你在家用电脑前的处境有关，也与那些正在决定是否要为系统打补丁的《财富》500强 CISO 们有关；这就是问题所在。你是否愿意每隔一天就给系统打补丁并重启？你负担得起吗？你又能承受不打补丁的代价吗？那种可以依赖一个坚固、稳定的程序连续运行数周甚至数年的日子已经结束了。补丁发布的节奏已经加快，而且短期内不会放缓。当每个人都淹没在“高”和“严重”的海洋中时，严重性评分的作用就小得多了。
公司感受到的影响
企业和奥德修斯一样，正被困在斯库拉和卡律布狄斯之间。它们既想要更快的检测，也需要更少的噪音。AI 确实可以帮助更早地发现真正的缺陷，但同样的工具也可能生成看起来足够权威、足以要求审查、却并不带来任何价值的报告。这会形成一种反馈循环：安全团队花在验证报告上的时间，比修复根本问题还多。企业该怎么办？
这时你也许会问自己：“为什么 AI 不能修复那些漏洞？”答案很简单：不能。发现安全漏洞远比修复它们容易得多。一项针对 20,000 多个由 AI 修复的问题的学术研究发现，LLM 引入的“新漏洞几乎是开发者的 9 倍，而且其中许多表现出开发者代码中未曾出现的独特模式”。简而言之，药方可能比疾病更糟。即便是最好的、由 AI 驱动的修补程序，例如用于 Python 代码的 PatchitPy，其修复成功率也只有 80%。这已经不错了，但远非完美。更糟的是，一些开发者发现，在“经过多轮 AI 修复之后，严重漏洞的数量可能会上升，而不是下降”。为什么会这么难？
据前 Google Project Zero 经理、计算机安全专家 Ben Hawkes 所说，一个重要原因在于：“很难体现这样一个事实：某个漏洞在一种部署环境下可能极其严重，在另一种环境下又只是有点重要，甚至根本无关紧要——而且它可以在同一时间同时具备这几种属性。漏洞修复很难。”他说得没错。那么你能怎么办呢？Google 有一些建议。归纳起来就是：
缩小范围：要求模型进行最小化、定向的更改（例如“镜像这个上游修复”或“把这个依赖更新到 X 版本”），而不是笼统地要求“消除漏洞”。
将修复与验证分开：把验证当作一个独立阶段。这意味着在打补丁后，重新运行扫描器、fuzzer 和针对该 CVE 的定向测试，而不是把“能编译并且测试通过”当作安全性的证明。
对复杂更改进行人工审查：可以把 AI 当作草稿生成器或检索助手，但在涉及架构层面的变更、多文件重构，以及任何触及身份验证、授权或数据处理的内容时，仍应由人工工程师主导。
企业声誉也会面临风险。如果一家公司看起来忽视漏洞报告，就会显得玩忽职守；如果把每一份机器生成的报告都当作紧急事项，就会消耗员工时间并延误真正的修复。实际结果是，对更强的安全团队、更严格的证据要求，以及更好地利用可利用性信号而不是原始报告数量的需求正在上升。
你准备好了吗？我怀疑没有。另见：“我已经不是程序员了”：Linus Torvalds 谈他现在只用的两个工具
企业表示他们在寻找 IT 安全人员，但招聘人数并没有像 2022 年那样多。更令人不安的是，“ISC2 现在将预算限制列为人员短缺的头号原因，首次将‘缺乏合格人才’挤到了后面（ISC2 2024）。这一变化很重要：它意味着缺口越来越是领导层和投资问题，而不是技能供给问题。ISACA 的数据也证实了这一点，显示即使市场上存在合格候选人，团队仍然人手不足。”
这不会有好结果。下一步会发生什么
这个问题的下一阶段很可能更多是流程上的，而不是技术上的。组织将需要更激进的分流规则、更清晰的披露政策，以及在人工看到报告之前用于去重和评分的更强自动化。否则，AI 只会继续增加发现数量，以及包裹在这些发现外面的垃圾信息数量。另见：Linux 正在迎来一次安全警醒——为什么这是不可避免的，而我并不担心
Linux、Microsoft 和 Adobe 带给我们的关键教训是：这如今已经是一个全生态系统范围内的运营问题。AI 不仅仅是在发现更多漏洞；它正在改变漏洞管理的经济性，而这种变化正在冲击软件供应与支持的每一层。我们必须认真对待这些问题，否则在接下来的几个月里，我们会看到一些 IT 安全问题，让过去那些重大事件——从 Morris worm 到 Marks and Spencer 3 亿英镑勒索软件攻击——看起来都只是小题大做。
来源与参考