这是一篇迟到的文章，至少相比现在AI发展的速度，但其思路依然适用于当前的CVE漏洞分析，甚至会因为目前更强的模型而变得更强。在AI技术快速变革的当下，除了模型能力之外，我们更应当多思考如何基于AI构建和形成有效的工作流，因为这是我们绝大多数人唯一可控且能够产生价值的工作。
2025 年 8 月 21 日，Efi Weiss 和 Nahman Khayet 在 Substack 发布了一篇文章，标题是《Can AI weaponize new CVEs in under 15 minutes?》。文章提出了一个对于防守方非常现实的问题：
如果 AI 可以在漏洞公告发布后，用 10 到 15 分钟生成可工作的利用代码，那么过去依赖“公开 PoC 尚未出现”而获得的缓冲期，是否还存在？
这篇文章的价值，并不在于它证明了 AI 已经能够完全替代漏洞研究人员，而在于它展示了一种自动化漏洞研究流水线的雏形。研究团队声称，他们构建的系统可以分析 CVE 公告和代码补丁，生成易受攻击的测试应用和利用代码，并通过对比漏洞版本与修复版本来验证漏洞利用结果，并尽可能排除误报。按照文中说法，单个 CVE 的完整执行时间约为 10 到 15 分钟，成本约 1 美元，发布时已有 10 个工作样例。
这意味着，漏洞利用能力正在从“专家手工研究”向“机器辅助批量验证”转变。
从公告到利用，不只是生成代码
过去谈到 AI 安全，很多讨论集中在模型是否会直接输出恶意代码。但这篇文章真正值得关注的地方，是它没有把问题简化成“让大模型写一个 EXP”。相反，研究团队把任务拆成了几个阶段：数据准备、上下文增强、测试计划、沙箱执行、结果验证和迭代修正。
这和真实漏洞分析过程是相似的。一个 CVE 公告本身通常只提供有限信息，真正有价值的是公告、受影响版本、修复版本、代码仓库、补丁差异和运行场景之间的关联。人类研究人员需要从这些信息中判断漏洞成因，找到触发路径，再构造验证环境。研究团队只是尝试把这一流程交给多个 AI Agent 协同完成。
第一步是情报获取。文中提到，他们不仅使用 NVD，也查询 GitHub Advisory Database。原因很简单：GitHub Advisory 往往能直接给出受影响仓库、版本范围、修复版本和相对可读的问题描述，这些信息对自动化分析非常关键。NVD 的 CVE API 更适合作为通用漏洞数据源，而 GHSA 更贴近开源软件包生态。
第二步是补丁分析。系统会根据漏洞版本和修复版本拉取代码，提取补丁差异，再把漏洞公告和修复代码一起交给大模型分析。这里的核心并不是“模型知道漏洞怎么利用”，而是让模型在明确的修复代码中进行上下文中推理：改了什么、为什么改、原来的逻辑为什么不安全、什么输入可能触发问题。
第三步是构建验证闭环。研究团队发现，仅让一个 Agent 同时写易受攻击应用和利用代码，很容易出现混乱。例如模型可能为了让测试通过而修改测试应用，甚至制造一个和真实漏洞无关的“可被利用”的程序。于是他们把任务拆成多个 Agent，并用代码模板约束易受攻击的应用和漏洞利用代码的边界。
这恰恰说明，AI 漏洞利用自动化的难点并不是“生成代码”四个字，而是验证体系是否可信。
几个关键工具的定位与作用
这篇文章涉及的工具不少，但可以按功能分为五类：模型、Agent 框架、漏洞数据源、执行沙箱和证明工具。
首先是大模型。研究团队早期使用本地模型，如 qwen3:8b，后来尝试 open-weight 模型，并提到 Claude Sonnet 4 在 PoC 生成方面表现最好（当然，现如今最好使用Claude Opus 4.6/4.7）。这里的定位很清晰：本地模型适合低成本、高频实验，便于调试提示词和流程；SaaS 大模型通常代码能力更强，但成本更高，也可能受到安全策略限制。OpenAI 的 gpt-oss-20b 这类开权重模型，官方定位就是低延迟、本地或特定场景使用，适合放在可控基础设施中快速迭代。其优势是成本可控、数据边界清晰、可重复实验；劣势是能力上限、工具调用质量和复杂推理稳定性仍然不如头部闭源模型。对于安全研究而言，本地模型更像实验平台，而不是最终能力保证。
其次是 Pydantic AI。文中提到研究团队从直接调用 LLM API，逐步重构到 pydantic-ai。Pydantic AI 官方定位是一个类型安全的 Python Agent 框架，可以定义 instructions、tools、structured output 和依赖类型。它适合用在这种多阶段流水线中，因为漏洞分析不是简单聊天，而是一系列结构化任务：公告解析、补丁摘要、测试计划、代码生成、执行结果判断。
Pydantic AI的优势是类型约束、结构化输出和工程化能力更好，便于调试和复用；劣势是它只能提升 Agent 应用的工程质量，不能解决模型本身理解错误、上下文遗漏或安全边界判断不足的问题。换句话说，Pydantic AI 解决的是“如何把 AI 系统做成软件”，而不是“如何保证 AI 一定判断正确”。
第三类是漏洞数据源，包括 NVD 和 GitHub Advisory Database。NVD 的优势是通用、权威、覆盖面广，CVE API 支持按 CVE ID、发布时间等条件检索。GitHub Advisory 的优势是面向开源生态，常常提供包名、生态、受影响版本、修复版本、引用链接和 GHSA 标识。对于自动化系统而言，这类结构化信息比自然语言新闻更可靠。但它们也有边界，公告描述不一定完整，修复提交不一定清晰，受影响范围也可能后续更新。如果系统只依赖公告本身，就容易把“看起来可利用”误判为“实际可利用”。这也是为什么文中要引入修复版本做对照验证。
第四类是 Dagger。Dagger 官方将其定位为可编程的测试编排平台，可以在本地、CI 或云端重复运行测试，使用容器和沙箱函数来控制环境。研究团队用它来启动隔离环境，让易受攻击应用和漏洞利用程序在受控容器中互相通信。
在这个场景里，Dagger 的价值不是攻击，而是验证。AI 生成的东西不能只靠文字判断，必须运行。Dagger 提供了可重复、可观察、相对隔离的执行环境，使每次尝试都能得到明确结果。它的优势是工程化强、适合自动化流水线；劣势是仍然依赖容器隔离和测试设计，如果测试样例本身不合理，执行成功也未必代表真实漏洞成立。
第五类是 OpenTimestamps。研究团队为了证明某个 PoC 在公告发布后多久生成，引入了 OpenTimestamps。它的定位是区块链时间戳证明标准，可以证明某份数据在某个时间点之前已经存在。对于安全研究而言，这不是漏洞利用工具，而是研究可信度工具。它能帮助研究者证明“我在某个时间之前已经生成了这个文件”，但不能证明 PoC 正确，也不能证明方法适合所有漏洞。
真正的问题是防守窗口被压缩
可以看到，这篇文章并不是简单展示某个“AI 攻击工具”，而是在提醒防守方：漏洞披露后的时间窗口正在变化。
过去，企业安全团队常常有一种默认假设：CVE 发布之后，公开利用代码出现之前，还有几小时、几天，甚至几周的处置时间。这个假设在很多漏洞治理流程中是隐含存在的。资产排查、影响分析、补丁验证、变更审批、灰度发布，所有环节都需要时间。
但如果 AI 能够批量读取每天新增的 CVE，自动拉取补丁、构造测试环境、生成验证样例并排除一部分误报，那么攻防双方的节奏就会被重新定义。攻击者不一定需要等待人类研究员写博客，防守者也不能只等安全社区给出明确 PoC 后再行动。
当然，这并不意味着所有 CVE 都会在 15 分钟内被可靠武器化。复杂漏洞、闭源软件、依赖特殊环境的漏洞、需要深度业务上下文的漏洞，仍然会让自动化系统遇到困难。所以在文章的评论区中也有人指出，复杂 CVE 和大型项目会更具挑战性，而非这样的流程可以从容应对的。
问题在于，防守不能以“最难的漏洞”为基准，而要更多关注“是否有足够多的中等复杂度漏洞能够会被快速规模化处理”。一旦攻击成本下降，企业面对的不是单个漏洞，而是漏洞流量的自动化放大。
从漏洞管理到验证能力建设
对于企业而言，这篇文章带来的启示并不是要去复刻一套自动漏洞利用系统，而是要反向思考自己的漏洞治理能力是否足够快。
第一，资产和依赖清单必须足够准确。没有清晰资产、组件、版本和暴露面，任何 CVE 响应都会从“找到受影响的系统”开始，而这个过程相当浪费时间。
第二，补丁和缓解措施需要预案化。高危漏洞出现后，不应每次都重新讨论流程，而要有分级响应、临时缓解、变更通道和回滚机制。
第三，验证能力要自动化。安全团队不能只知道“某版本受影响”，还需要能够在测试环境中快速判断自身业务是否可触发、是否暴露、是否已被缓解。
第四，AI 可以用于防守侧提速。公告摘要、资产匹配、补丁差异解读、检测规则生成、临时缓解建议、复盘报告编写，都可以成为 AI Agent 的应用场景。真正重要的是如何把 AI 放进流程，而不是把流程完全交给 AI。
说到底，这篇文章讨论的不是 AI 是否会写 EXP，而是安全响应的时间尺度正在发生变化。过去企业可以把漏洞治理当成按周推进的工作，现在越来越需要按小时甚至分钟建立初步判断能力。
如果攻击侧可以用自动化压缩研究时间，防守侧也必须用自动化压缩识别、评估和处置时间，否则，真正落后的并不是某个工具，而是整个安全治理体系对新节奏的适应能力。更多关于AI驱动漏洞管理的深度探讨，欢迎在云栈社区交流。
参考资料
发表于 5 小时前
|
查看: 4|
回复: 0
