AI加速漏洞利用，BAS成CISO预算重点

三十年来，漏洞管理一直依赖一个缓冲期：从发现漏洞到有人弄清楚如何将其武器化之间的几个月。解决方案相当直接；按严重性分流，安排修复，验证，然后继续推进。正是这个缓冲期让这一流程得以运作。

今天，这个缓冲期已经消失。

AI 并没有让你的团队变慢。它改变了等式的另一边，把从发现到利用的时间从数月压缩到数小时。对于防守方来说，残酷的事实是：一个为“有余裕”而建立的流程，在没有余裕时撑不住。

AI 把漏洞发现变成了数量竞赛

在 2026 年 5 月的更新中，Anthropic 报告称，它与大约 50 个合作方使用 Claude Mythos Preview，在单个月内发现了超过 10,000 个处于高危或严重级别的、存在于系统性重要软件中的漏洞。

更早的数据同样惊人。

在 Firefox 上测试时，受限版 Mythos 模型写出了 181 个可工作的 exploit，而前一代前沿模型只写出了 2 个。它在所有主要操作系统和浏览器中都发现了漏洞，包括一个在 OpenBSD 中潜伏了 27 年而未被发现的 bug。

截至本文撰写时，它发现的内容中超过 99% 仍未修补。

AWS 在 2026 年 2 月的一份 threat-intelligence 报告展示了另一面：不需要 zero-day，只需要薄弱凭证，并通过一个自定义 MCP server 自主运行 offensive tools 进行工业化利用。AWS 证实，在 55+ 个国家/地区共有 600+ 台设备受影响；根据独立研究人员的说法，该威胁行为者的日志将 2,516 台设备列入队列，分布在 106 个国家/地区。

无论哪种情况，规则都已经明显改变。过去需要罕见专长的事情，如今可以以机器速度和规模运行。

漏洞武器化窗口也崩塌了

过去，防守方在一个 CVE 公布到其首次被确认在野利用之间，通常有数月时间，这个窗口被称为 time-to-exploit（TTE）。

这个窗口已经关上。

Zero Day Clock 显示，2026 年的平均值大约为 24 小时，而 2024 年约为 53 天。

入侵数据也印证了这一点。

Verizon 的 2026 DBIR 将 32% 的初始访问技术归因于漏洞利用，并预计这一数字还会继续上升，因为 AI 编码助手让 exploit 构建、将工具移植到新语言，以及发现新的缺陷，对以前从未具备这些能力的攻击者来说都变得可行。

告诉团队更快打补丁，就像叫一艘货轮瞬间刹车

行业的本能反应是更快打补丁。监管机构也在把它写进规则：许多法规现在对某些严重漏洞指向当天修复。董事会有此期待，高管也会要求这样做。

但修复并不是一个开关。补丁要先通过回归测试，等待变更窗口，等待审批，并遵守既有的正常运行时间和合规承诺。为了赶在 exploit 之前而停掉生产，最后只会变成另一种宕机。

而数据表明，一切都在朝错误的方向发展。

Verizon 2026 DBIR 跟踪了 13,000+ 家组织：

已知被利用漏洞的中位修复时间：43 天，较前一年 32 天上升

完全打补丁的比例：从 38% 降至 26%

当进攻以小时计、修复以周计时，入侵几乎总会发生在中间。

同样根据 Verizon 的 DBIR，即便是表现最好的组织，在检测后的第一周内也只能关闭 30-40% 的已知被利用漏洞：尽管多年持续投入，这个速度几乎没有变化。

因此，命令团队更快打补丁并不会改变物理现实，这感觉就像要求一艘货轮瞬间刹车。

瓶颈已经转移，策略也必须转移

二十年来，漏洞管理一直建立在一套整齐的假设上：

发现缺陷，

按严重性评分，

先修最严重的。

当每季度只有几十个 critical 漏洞时，CVSS 分流是有效的。不幸的是，它面对每天数百或数千条披露时几乎毫无胜算。

再回到 Verizon 的 DBIR：中位组织在 2025 年必须修补 16 个已知被利用漏洞，而前一年为 11 个，增幅接近 50%。

那还发生在 AI 发现的缺陷开始淹没漏洞目录之前。

与此同时，严重性评分并不能告诉你某个漏洞在你的环境中是否可达、你的控制措施是否已经会阻挡它，或者它是否会与其他问题串联成真正重要的攻击链。一个几乎全是“9”或“10”的严重性列表，本质上等于没有优先级。

所以，有用的问题不再是“哪里有漏洞？”，而是“现在针对我们，哪些是真正可利用的？如果有人尝试，我们的防御会不会发现？”

这正是 Breach and Attack Simulation（BAS）被设计来回答的问题。

为什么 BAS 会成为对抗 AI 攻击的基石

BAS 采用真实世界中的对手技术，也就是最新头条所对应 campaign 背后的 TTPs，并安全地在你的实时防护和检测堆栈上运行它们。不是扫描。不是理论映射。而是一场实际演练，展示你的工具究竟会拦住什么、会检测到什么、又有哪些会漏过去。

在一个被披露信息淹没的世界里，这能带来三件单靠漏洞管理做不到的事。BAS：

把理论与现实区分开来。一个已被你的 WAF、IPS 和 EDR 中和掉的缺陷，与一个能直接闯进来的缺陷，是完全不同的问题。BAS 会告诉团队两者分别是什么，让团队不再把每个 CVE 都当成五级火警。

验证你已经为此付费的控制措施。大多数企业会运行 10 到 70 种安全工具，且存在无数重叠策略；BAS 衡量它们在当前配置下是否真的生效，并找出隐藏在缝隙中的残余风险。

为安全修补争取时间。当你能证明某个关键资产已经受到加固控制保护时，补丁就可以通过正常变更控制流程，而不是紧急上线。若没有保护，你就知道必须先做缓解。

这种收益已经开始体现在预算上：一线反馈越来越多地表明，CISO 正在为 BAS 预留专门预算，而一年前这还不是独立预算项。

这正是 Gartner 现在称为 Adversarial Exposure Validation 的转变：把安全有效性（“我的控制措施是否正常工作？”）与业务上下文（“哪些资产最重要，哪些是真正可达的？”）结合起来，按照组织的现实而不是假设性的原始分数来排序。

如果再配合 autonomous penetration testing，它能证明攻击者是否可以把暴露面从初始立足点一路串联到组织的 crown jewels，那么 BAS 就补齐了全景。

一边问：“等等，他们能攻破我们吗？”另一边问：“但我们会发现吗？”

一起运行时，BAS 和 autonomous pentesting 用证据取代猜测。

BAS 也必须以机器速度自主运行

这里有一个问题。

如果攻击者在自主运行，那么一个人类需要一周才能完成的验证周期，在一开始就已经过时。机器速度的攻击需要机器速度的防御，而唯一足够快、能够对抗自主进攻的，是自主防御。

对把原始 generative AI 直接用于这件事的合理担忧是安全性。正如 Picus CTO Volkan Erturk 所警告的那样，一个被要求发明 exploit 的模型，可能会回传一个真实可用的 malware sample，或者编造某个组织从未使用过的技术。你不想让未经验证的 binaries 在生产环境中爆炸，也不想让防御建立在并不存在、或不可能存在的攻击之上。

Picus 的做法是让模型负责协调，而不是创造。

Picus 的 agentic BAS 不要求 AI 编写 payload，而是把一份新的 threat report 与一个经过筛选、预先验证过的安全测试积木库进行匹配。安全团队只需指定一个 threat，接下来由一个 multi-agent 系统接手：一个 agent 识别威胁并制定研究计划，其他 agent 从多个来源收集并验证情报，builder agent 则把对手的 TTPs 映射成可用于模拟的 attack chains。

输出的是一个准确、可直接运行的模拟，且能在几分钟内组装完成。

这压缩了整个循环。CISA 警报或转发来的头条，会变成一个有范围的测试、一个 posture score、优先排序的缓解措施和一份高管报告，通常只需几分钟；人类负责审查例外，而不是推动并拖慢每一个步骤。

这就是 Picus Platform 的设计目标

打补丁仍然很重要，但当 AI 以成千上万的速度发现缺陷，并在数小时内将其武器化时，单靠打补丁不可能成为你的全部策略。如果进攻是自主的，防御也必须至少以同样速度运作，而这正是 Picus 所要实现的。

可扩展的是验证：确认你的控制措施究竟能拦住什么，证明哪些是可利用的，并且只把修复时间和人力投入到真正能改变结果的地方。AI-powered、agentic BAS 是 Picus Platform 的核心支柱之一，它会持续测试你的防御是否能阻挡并检测到重要威胁，而无需等待人工启动流程或推进到下一轮。当发现缺口时，平台会指出所需的 vendor-specific mitigation，而不是只在工单堆里再添一张单子，然后再次验证，确认缺口确实已经关闭。

能立刻判断一条新头条是否会让业务处于风险之中的需求，不会很快消失。Picus Platform 能在别人提问之前，把这个答案给到安全团队。

在下一条头条落地之前，先看看它是否会让你暴露风险。Request a demo。

注：本文由 Picus Security 的 Security Research Engineer Sıla Özeren Hacıoğlu 撰写。