6%困境：AI以机器速度发现漏洞，世界却仍在以人的速度打补丁
一份漏洞披露项目的报告显示，其修复率只有6%。把这个数字套进典型的依赖树和14天合规时限里，你会发现，每一次前沿模型发布，都可能变成大多数企业根本没有足够人手应付的补丁激增。
截至2026年5月下旬，通过某AI漏洞发现项目披露的漏洞中，约有6%已经完成修复。这个数字来自向美国众议院国土安全委员会提交的证词，其中直接提出了一个尖锐的问题：披露机制能否跟上每一次模型发布的节奏？这是迄今为止，关于AI如何改变漏洞发现与补丁管理最有用的一个数字，因为它把一种模糊的不安，转化成了可以套用到自己系统上的算术题。本文就来做这道题。
AI 如何改变了漏洞发现与补丁管理？
协同披露机制天生是为“稀缺”设计的：研究者发现一个漏洞，私下上报，供应商拿到一个固定的修复窗口（通常90天左右），之后公告才对外公开。整套机制的前提，是漏洞以涓流的速度被发现。
机器规模的发现，同时打破了这两个前提。云安全联盟（Cloud Security Alliance）审视过一项行业说法：某个模型在长期被大量审计过的开源代码中，发现了数千个此前未知的漏洞，其中一些已经潜伏了数十年。云安全联盟未能独立核实这些能力说法，因此具体数字应当存疑对待。但6%的修复率不需要这样的保留态度：无论真实的发现规模最终是多少，修复的速度已经有据可查，而且很难看。发现正在被自动化，修复没有。
你要背多少这笔债？
先看清一棵现代依赖树的形状。USENIX Security一项针对npm生态的研究发现，安装一个普通软件包，等于隐性信任了另外79个软件包和39位维护者。一款中型产品哪怕只有几十个直接依赖，实际站立的地基往往是几百到上千个、其开发者从未读过源码的组件。
把数字套进一次披露浪潮里。保守假设，一次机器规模的披露事件会波及一棵1,000个组件依赖树中的2%，也就是20个受影响组件。按证词披露的修复率计算，发布当天大概只有其中1个组件有上游补丁可用，剩下19个，隔离、缓解还是替换，都得你自己想办法。
而时钟已经在倒数。英国的“网络必需认证”（Cyber Essentials）要求关键和高风险安全更新必须在14天内完成，认证资格更是许多公共部门合同的硬性前提；这类14天窗口，在其他司法辖区企业的安全SLA中同样十分常见。19项组件级缓解要在14天内完成，意味着在照常运营之外，还要以每天1.4个的速度持续冲刺两周。
再对照现实。Veracode对第三方代码的分析发现，79%的第三方库在被引入代码库之后，就再也没有更新过，多数团队诚实的基线吞吐量其实接近于零。就算2%的假设显得激进，把它降到0.5%再算一遍：两周内5个组件，仍然超出了一个每周只能上线一次依赖更新的团队所能承受的范围。这个结论经得起任何合理输入的检验：一次不算大的披露浪潮，也能把典型的补丁产能甩开一个数量级。
谁会比你更早拿到补丁？
手握大量未公开漏洞的实验室，总得先告诉某个人，再告诉所有人。坐视不管说不过去，直接全网公开更糟，逐一悄悄通知成千上万个受影响项目又不现实。理性的选择，是提前简报一个小圈子：那些安全团队规模足以消化保密信息洪流的大型平台。这本质上是分诊，但换个角度看，它也是一种会员分级。这个小圈子完成私下修复，到模型对公众开放之间的这段间隔，就是一个开始日期大致可预测、名单却完全轮不到你置喙的“计划内暴露窗口”。
圈子之外，压力落在了整条链条中资源最少的人身上。Linux基金会的开源软件普查二期（Census II）发现，那些使用最广泛的软件库，往往只靠极少数维护者支撑，很多人还是无偿的。没有谁会为一个照看了二十年、无人问津的解析库的志愿者安排轮值待命，也没有哪个联盟会替你提前修复那些间接依赖。6%这个数字，就是“发现像软件一样规模化，修复却仍然像人力一样规模化”的真实写照。
发布日补丁激增应对模型该怎么搭？
把每一次官宣的前沿模型发布，当作设施团队对待台风预警的方式来处理：一个有明确日期、触发既定响应流程的事件。这个模型分四部分。
责任人。补丁激增的应对责任，属于拥有部署流水线的人，通常是技术负责人或IT运维负责人。安全团队的职责是分诊和排序；真正把补丁发布出去的，是工程团队。一份由无法发布代码的团队拥有的应对方案，只是一份文件而已。
一条经过测量的基线。统计过去一个季度里团队实际测试并部署的依赖更新数量，按周计算，数据来自变更记录，而不是印象。这个数字，才是你真实的应对产能，理应被写进技术战略，与一份能标出“哪些组件永远等不到上游修复”的依赖清单放在一起。
触发阈值。用前面的算术给应对规模定标：依赖树规模，乘以假设的触及比例，再乘以94%这个“大概率发布时仍未修复”的份额，除以14天。如果结果落在你实测的产能之内，演练一遍，收工。如果超出产能——对多数中型企业而言，大概率会超出——那就提前约定不依赖打补丁的缓解手段：网关处的虚拟补丁、对高风险组件的网络隔离、功能开关级别的应急熔断，以及一份你会优先保护的20个依赖的排序清单。把组件设计成可以随时被切断、又不至于拖垮整个产品，这正是我们在智能体系统安全一文中反复强调的原则。
把合规后果写进纸面。网络必需认证一旦过期，足以让企业失去公共部门业务的投标资格。一旦漏洞波及个人数据被利用，英国信息专员办公室（ICO）要求的72小时报告时限就会启动，这与欧盟GDPR的72小时数据泄露通报要求同源。网络保险公司在每次续保时，也都会追问补丁节奏。这三项后果，都应该在你把任何东西搭建到某个前沿模型之上以前，写进采购文件里，这正是AI就绪度评估中不那么光鲜、却最实际的那一半。
那个提前简报的小圈子，会继续守着自己的名单；而下一次发布日期，也早已写进了某个人的日历。这篇文章里所有数字中，唯一由你掌控的，是你实测出来的补丁吞吐量。这周就把它量出来。
常见问题
什么是漏洞披露窗口，为什么它正变得更危险？
它指的是漏洞被私下上报，到细节公开之间的间隔。过去，这段时间是用来在公众知情之前先把补丁做出来，保护用户。但当同一个AI模型既生成了发现结果，又会在一个已知日期公开可用时，这段窗口就变成了倒计时：终点是尚未打补丁的企业，与一件强大的漏洞发现工具在公开场合相遇的那一刻。
我该如何测算自己组织的发布日补丁应对产能？
用你的依赖树规模，乘以一个假设的披露触及比例（0.5%到2%是相对稳妥的规划区间），再按“大概率没有上游补丁”的比例打折，除以14天，就能得到你需要的每日缓解速度。把它和你从真实变更记录中测出的实际吞吐量对比，缺口部分用隔离、熔断这类提前约定好的缓解手段补上，而不是寄望于运气。
使用成熟、经过广泛审计的开源软件，能让我免受AI发现漏洞的冲击吗？
效果不如从前。正在被审视的说法，涉及的正是那些在被反复审查的代码中潜伏了数十年的漏洞，而修复数据指向的瓶颈是维护者的人力，不是代码的年龄。“开源软件普查二期”发现，最广泛使用的软件库恰恰只靠极少数维护者支撑，也就是说，越流行，发布日的风险反而越集中，而不是被稀释。
相关阅读
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 华盛顿把自家AI实验室列入风险名单："供应商锁定"从此不再只是价格问题
- 企业AI试点为何难以规模化：卡住项目的不是能力，是信任
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。