好消息是AI正在以前所未有的速度发现安全漏洞。坏消息也是如此。一方面能够快速发现大量漏洞固然是好事但要把它们全部修复却是一项极为繁重的工作。即便是谷歌这样的科技巨头也能在2026年6月为Chrome修复比过去两年加起来还多的漏洞但绝大多数企业并非谷歌根本没有足够的资源来应对如此数量的安全问题。就连苹果公司也被AI生成的漏洞报告所淹没。2026年6月苹果公司通知安全研究人员限制了他们向内部安全团队提交潜在危险软件漏洞的数量上限。如果研究人员发现了极其严重的漏洞却已超出限额也只能等到下个月再提交。问题的核心在此AI辅助漏洞发现正在加速漏洞报告的产生速度但真正的矛盾在于机器能够发现的漏洞数量与人类实际能够处理和分类的数量之间存在越来越大的鸿沟。这给开发者、安全团队以及各类企业带来了沉重负担他们需要在可被利用的真实漏洞和机器产生的噪音之间不断做出判断。不仅是开发者感到力不从心系统管理员、首席信息安全官CISO乃至普通用户都在疲于应付一个接一个的补丁更新。过去的安全工作流程建立在一个假设之上高价值漏洞的出现频率相对可控。安全人员可以参照通用漏洞披露CVE评分优先修复评分最高的漏洞同时祈祷不要遇到零日漏洞。但这已是过去的逻辑现实情况已截然不同。AI打破了这一假设使大规模发现漏洞的成本极度降低。尽管开源软件获得了最多关注但这绝非一个单纯的开源问题。以微软为例其2026年7月的补丁星期二共发布了570个补丁其中包含三个零日漏洞创下历史纪录。而这一纪录很可能在年底前就会被再次打破。原因并非Windows变得更不安全而是正如微软在2026年5月所解释的那样AI帮助防御者发现了更多问题用户将在每次安全更新中看到更多安全补丁。这一趋势只会持续加剧。安全公司Chainguard联合创始人兼CEO丹·洛伦茨Dan Lorenc在一场网络研讨会上表示AI正以远超防御方修补和更新漏洞能力的速度在其编写和使用的软件中发现漏洞。他指出发现漏洞本就比修复漏洞容易而AI在发明出更好的灭火器之前又往火里倒了一大桶汽油。这一局面之所以难以管控在于并非所有漏洞都同等重要。少数漏洞具有紧迫性且已被积极利用而更多漏洞则属于日常修复范畴的背景噪音。安全团队被迫对海量问题进行优先级排序而数量本身就是风险的放大器。以往笔者曾建议Windows用户不必急于打补丁因为许多补丁本身存在问题例如2026年1月的补丁星期二事件。但如今面对接连不断的零日攻击用户可能别无选择只能咬牙更新并祈祷补丁本身不会带来新的问题。Linux稳定内核维护者格雷格·克罗亚-哈特曼Greg Kroah-Hartman曾直言如果你用的不是最新的稳定/长期支持内核你的系统就是不安全的。如今这一结论同样适用于Windows、macOS以及几乎所有软件。有些人可能认为这主要是Linux和开源软件的问题但事实并非如此。Linux内核之所以最为显眼是因为其维护者公开发声而他们本已捉襟见肘。情况有多严峻2026年7月仅两天内就有432个CVE被报告在Linux内核中。同样的问题也出现在专有软件中只不过相关公司没有公开披露。从补丁体量的持续增大便可窥见一斑。当然部分增量来自微软向Windows集成更多AI功能但笔者强烈怀疑其中很大一部分是针对潜在AI安全漏洞的修复。举一个具体案例Adobe Acrobat Chrome扩展程序的安全漏洞HermeticReader仅需用户访问一个恶意网页便可暴露WhatsApp Web的敏感数据。这类网页看似普通但一旦访问便会触发扩展程序内部的隐藏模块进而窃取用户的聊天列表、联系人姓名、消息内容、账户名称及当前对话内容——几乎无所遗漏。这一攻击由AI将三个不同漏洞串联而成实现了无需认证、单次访问、零点击即可向扩展程序自身存储写入数据的能力。更令人担忧的是该攻击随后被犯罪分子通过DeepSeek大语言模型与Hermes智能体框架自动化实施。此次事件的唯一好消息是Adobe迅速发布了更新版本在造成大规模危害之前堵住了漏洞。但我们未必总能如此幸运。正如Linux基金会CEO吉姆·泽姆林Jim Zemlin在北美开源峰会上所言如今从漏洞披露到被利用的平均时间已从63天缩短至负7天——也就是说漏洞甚至在补丁发布之前就已遭到利用。与此同时AI生成漏洞报告的另一代价并不仅仅是误报还有证明误报所消耗的时间。维护人员仍需逐一阅读、复现并判断这些报告是重复提交、AI幻觉还是掩藏在混乱表述中的真实漏洞。这是一种专家注意力的消耗税对规模较小的团队打击尤为沉重。这不只是维护人员的烦恼对于在家使用PC的普通用户以及需要在补丁还是不补丁之间艰难抉择的企业CISO来说同样是切身问题。你愿意每隔一天就修补和重启系统吗你负担得起吗你又能承担得起不补丁的代价吗过去那种可以依赖稳定程序运行数周乃至数年的时代已经一去不返。补丁节奏正在加速而且短期内不会放缓。当所有人都被高危和严重评级的发现淹没时严重性评分的参考价值也随之大打折扣。企业就如同奥德修斯被夹在斯库拉与卡律布狄斯之间进退两难既希望更快地检测漏洞又需要更少的噪音干扰。AI能够更早发现真实缺陷但同样的工具也可能生成看似权威、实则毫无价值的报告迫使安全团队花费大量时间验证报告而非专注于修复根本问题。企业究竟该怎么办或许有人会问为什么不让AI来修复这些漏洞呢答案很简单目前做不到。发现安全漏洞远比修复它们容易。一项针对逾2万个AI修复案例的学术研究发现大语言模型引入新漏洞的数量几乎是开发者的9倍且其中许多漏洞呈现出开发者代码中未见的独特模式。简而言之药方可能比疾病本身更危险。即便是目前最优秀的AI补丁工具如针对Python代码的PatchitPy成功修复率也仅有80%。这已相当不错但距离完美仍差距甚远。更令人沮丧的是有开发者发现经过多轮AI修复后严重漏洞的数量反而可能有增无减。为何如此困难谷歌Project Zero前负责人、计算机安全专家本·霍克斯Ben Hawkes指出了一个关键原因很难准确描述这样一个事实同一个漏洞在某种部署环境中可能极为严重在另一种环境中只是有些重要而在另一种情况下则无关紧要——这些情况可以同时成立。漏洞修复本来就很难。此言极是。那么面对这一困境我们能做些什么谷歌给出了一些建议核心要点如下缩小范围要求模型进行最小化、针对性的修改例如对照上游修复方案或将此依赖项更新至X版本而非笼统地消除漏洞。将修复与验证分离将验证作为独立阶段处理即在应用补丁后重新运行扫描器、模糊测试工具和针对该CVE的专项测试而不是以编译通过、测试通过作为安全的证明。复杂变更需人工审查将AI作为草稿生成工具或搜索助手但涉及架构层面的修改、跨多文件的重构以及涉及身份验证、授权或数据处理的任何内容必须由人类工程师主导。企业还面临声誉风险。如果一家公司看似忽视漏洞报告会显得玩忽职守如果将每一份机器生成的报告都视为紧急事项处理则会耗尽员工精力、延误真正的修复工作。实际结果是企业越来越需要更强大的安全团队、更严格的证明要求以及更好地利用可利用性信号而非仅凭原始报告数量来做决策。你们真的准备好了吗笔者对此深表怀疑。企业都声称在招募IT安全人才但其实际雇用人数远不及2022年的水平。更令人警觉的是ISC2的数据显示预算限制首次取代合格人才短缺成为人员短缺的第一大原因ISC2 2024年报告。这一转变意义深远它表明人才缺口越来越多地是领导力和投入不足的问题而非技能供给问题。ISACA的数据印证了这一点即便市场上存在合格候选人团队依然人手不足。这种局面难以善终。这一问题的下一阶段很可能需要从流程层面而非技术层面寻求突破。各组织需要建立更严格的分类规则、更清晰的披露政策以及更强大的自动化机制在人工介入之前完成报告的去重和评分。否则AI将继续在放大发现数量的同时也放大裹挟其中的噪音。从Linux、微软和Adobe的案例中我们可以得出一个核心结论这已是一个生态系统层面的运营问题。AI不只是在发现更多漏洞它正在改变漏洞管理的经济逻辑而这一转变正在冲击软件供应和支持的每一个环节。我们必须认真对待这些问题否则在未来数月内我们将会目睹IT安全事件的严重程度令从莫里斯蠕虫到玛莎百货3亿英镑勒索软件攻击等历史事件相形见绌。QAQ1AI在发现安全漏洞方面有多大优势为什么人类跟不上AAI能以极低成本大规模扫描代码发现漏洞的速度远超人工。以微软2026年7月的补丁星期二为例单次更新就发布了570个补丁创历史纪录。而安全团队的人员规模、处理能力和预算并未同步增长导致漏洞报告积压、优先级难以判断处理速度远远落后于发现速度。Q2AI能不能自动修复它发现的安全漏洞A目前AI修复漏洞的能力十分有限。研究表明大语言模型引入新漏洞的数量几乎是开发者的9倍。即便是表现最好的AI补丁工具PatchitPy成功修复率也只有80%。更糟糕的是经过多轮AI修复后严重漏洞的数量有时反而会增加因此目前AI更适合辅助人类而非独立承担修复任务。Q3普通用户和企业该如何应对越来越快的补丁节奏A普通用户应尽量及时更新系统因为零日漏洞被利用的时间已缩短至补丁发布前7天。企业层面谷歌建议将漏洞修复范围缩小、将修复与验证分离并对涉及身份验证等关键环节的变更保留人工审查。同时企业需要加大安全团队投入建立更完善的漏洞分类和优先级评估机制。