2026 年 5 月，Google 披露其发现犯罪团伙借助 AI 工具发现某主流开源项目中的重大安全缺陷。这一事件将一个早已在安全社区预判的趋势变成了现实：AI 辅助漏洞挖掘已进入攻击者工具箱。本文从防御视角出发，系统拆解这一威胁的运作机制：攻击者如何借助 LLM 构建端到端的漏洞发现流水线、目标选择的决策逻辑，以及组织可以从哪些维度建立防御边界。
攻击者视角：LLM 如何重塑漏洞发现范式
传统漏洞发现高度依赖人力。安全研究员需要阅读大量源码、理解协议设计意图、手工构造测试用例，整个过程以月甚至季度为单位计量。LLM 的介入从根本上压缩了这一时间线 —— 不是替代人类专家，而是将专家知识自动化、规模化。
从技术演进路径来看，AI 辅助漏洞挖掘经历了三个阶段。第一阶段以代码分类为核心，将代码片段输入模型，输出「有漏洞 / 无漏洞」的二分类结果，这种模式在 2022 年至 2023 年间流行，但受限于上下文窗口和被动判断的定位，漏报率和误报率均不理想。第二阶段以 LLM 辅助传统工具为核心 —— 让模型生成 fuzzing harness 或补充静态分析的 source/sink 规则，将 LLM 的语义理解能力与传统工具的精确执行能力结合，Google OSS-Fuzz 项目借助 LLM 在 272 个 C/C++ 项目中发现 26 个新漏洞，包括 OpenSSL 中存在二十年的 CVE-2024-9143，这一方向在 2024 年至 2025 年间成为主流。第三阶段以自主 Agent 审计为核心 ——LLM 作为主动探索者，调用代码浏览、调试、测试等多种工具形成假设并验证假设，Google Project Zero 的 Big Sleep 项目正是这一范式的早期实践者，它曾发现可利用的 SQLite 栈下溢漏洞。
攻击者如今正处于第二阶段向第三阶段过渡的窗口期。关键变化在于成本结构的颠覆：生成 fuzz harness 的成本从数天压缩到数分钟，验证假设的时间从数周压缩到数小时，这意味着同一攻击者可以在过去只能测试一个目标的时间窗口内，测试数十个潜在目标。
威胁模型：端到端攻击链的构成
将 AI 辅助漏洞挖掘纳入攻击者工作流，整个链路可以分解为四个核心环节：目标识别、信息收集、漏洞假设生成、验证与武器化。
目标识别阶段，攻击者不再依赖手工扫描或公开的漏洞预告，而是利用 LLM 分析公开的代码托管平台、供应商安全公告、CVE 数据库，通过自然语言提问快速定位具有特定属性的代码库。例如，攻击者可以让模型列出过去 90 天内提交量超过 500 次但尚未发布安全公告的热门开源项目，LLM 能够整合多个数据源完成这一查询，输出优先排序的候选列表。目标识别的速度提升意味着攻击者可以在安全社区注意到问题之前就已完成侦察。
信息收集阶段，攻击者利用 LLM 消化海量技术文档。RFC 规范、API 参考文档、开发者讨论记录 —— 这些过去需要安全研究员花数周时间阅读的材料，LLM 可以在数小时内完成结构化提取。Google 的 ChatAFL 项目展示了这一能力的攻击面扩展：它利用 LLM 理解协议规范，生成符合协议语法的测试用例，比传统 fuzzer 多覆盖 47.6% 的状态转换，发现 9 个此前未知的漏洞。在协议层面，这种信息收集能力的提升意味着更复杂的通信栈成为攻击目标。
漏洞假设生成是整个链路中最关键的一步。攻击者利用 LLM 的世界知识推断潜在漏洞模式 —— 常见危险函数的错误使用、访问控制检查的遗漏、状态机的边界条件处理错误。LLM 能够基于代码语义分析提出多个候选假设，并按照可利用性、可检测难度、潜在影响等维度排序。这一过程的自动化意味着攻击者不再需要资深专家即可构建高质量的漏洞假设集合。
验证与武器化阶段，攻击者让 LLM 生成触发漏洞的 PoC 代码，通过自动化测试框架执行并收集崩溃信息。一旦漏洞确认，攻击者可以将武器化代码集成到已有的攻击框架中。ProphetFuzz 项目的研究数据显示，使用 LLM 预测高风险的选项组合进行 fuzzing，72 小时内可发现 364 个漏洞，获得 21 个 CVE—— 这一数据展示了端到端流水线的效率上限。
目标选择：攻击者的决策逻辑
AI 辅助漏洞挖掘并没有改变攻击者的目标选择逻辑，但它极大地降低了执行成本，使得原本在经济上不可行的攻击变得可行。
高价值目标的首要特征是广泛部署。任何运行在数百万台设备上的软件组件，一旦被发现漏洞，攻击者可以获取大规模的潜在受害面。操作系统内核、网络协议栈、认证库、加密实现都属于这一类别。2025 年 DARPA AIxCC 竞赛中，多支参赛队伍使用 LLM 辅助的 fuzzing 系统针对此类组件进行测试，Buttercup 项目发现并修复了多个真实开源项目中的漏洞。
第二类高价值目标是供应链中的薄弱环节。攻击者清楚地知道，现代软件生态高度依赖开源组件，而这些组件往往缺乏企业级安全审查。攻击者会优先选择那些下载量大但维护者稀少、历史漏洞多但修复速度慢的项目。这一逻辑在 2026 年的供应链攻击趋势中愈发明显。
第三类目标是安全研究者尚未充分关注的领域。LLM 的一个优势在于它可以帮助攻击者快速进入陌生领域 —— 一个不熟悉嵌入式系统的攻击者，可以让 LLM 解释固件分析的基本方法、推荐工具链、描述常见的漏洞模式。这种知识转移能力大大降低了攻击者的技能门槛。
防御边界：组织可以做什么
面对 AI 加速的漏洞发现攻击，组织需要在多个维度建立防御边界。
在漏洞发现维度，组织应当主动引入 AI 辅助审计工具，将攻击者的优势部分转移到防御侧。Google OSS-Fuzz 的实践表明，将 LLM 与传统 fuzzing 结合，可以在攻击者利用之前发现漏洞。关键是建立持续的安全测试流水线，而非一次性渗透测试。对于高价值组件，建议部署多模型交叉验证 —— 让不同架构的 LLM 同时分析同一代码库，交叉比对结果以降低单模型的盲区。
在响应速度维度，AI 辅助漏洞挖掘意味着漏洞窗口期正在缩短。一旦某个开源项目被攻击者通过 AI 发现漏洞并武器化，从 PoC 公开到大规模利用的时间将大幅压缩。组织需要建立针对关键依赖项的实时监控机制，跟踪上游代码变更、安全公告、异常扫描行为。当检测到针对自身使用的某个开源组件的异常安全研究活动时，应立即触发内部评估流程。
在人员与流程维度，安全团队需要理解 AI 辅助攻击的运作逻辑。这不意味着每个安全研究员都需要成为 LLM 专家，而是需要建立一套人机协作的漏洞评估框架：AI 负责初筛和假设生成，人类安全研究员负责验证关键发现、判断业务影响、制定修复策略。2025 年 Snyk 发布的 Human + AI 漏洞审查框架正是这一思路的工业实践。
在资产与攻击面维度，组织需要重新评估哪些组件最可能成为 AI 辅助攻击的目标。高部署量、复杂协议栈、供应链关键节点 —— 这些特征组合指向的资产需要优先接受自动化安全测试。同时，对于供应链中的外部依赖，建议建立软件物料清单（SBOM），并在采购流程中引入 AI 驱动的依赖风险评估。
最后需要指出的是，AI 辅助漏洞挖掘并非万能。LLM 在漏洞发现中的局限性 —— 幻觉导致误报、上下文窗口限制跨文件分析能力、缺乏真正的代码执行语义理解 —— 同样会影响攻击者。防御者如果能够理解这些局限性，就可以在关键位置设置障碍：例如，设计攻击者难以通过 LLM 理解的混淆逻辑、增加需要深层上下文理解才能发现的安全检查。安全本质上是一场持续的攻防博弈，AI 只是让博弈的节奏变得更快，而不是改变了博弈的本质。
资料来源：本文技术背景参考腾讯安全团队发布的《自动化漏洞挖掘：过去、现在与未来》（2026 年 1 月），该文系统梳理了 2022 至 2025 年间 AI 辅助漏洞挖掘的三次范式跃迁。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。