AI 漏洞猎手：大模型如何参与漏洞发现、代码审计与攻防验证？

原创

lidasimida
lidasimida

安全学习之路

2026年5月27日 14:21
广东

去阅读

AI 漏洞猎手：大模型如何参与漏洞发现、代码审计与攻防验证？

一句话核心观点：AI 不是替代安全研究员的“自动黑客”，而是把代码理解、证据整理、工具调度和验证闭环做得更快；真正可靠的 AI 漏洞猎手，一定是“大模型 + 安全工具 + 人类审计”的组合系统。

本文是“AI 漏洞猎手”系列第 1 篇，先讲总框架。后续可以继续拆代码审计、CodeQL/Semgrep 协同、fuzzing、Agentic 漏洞研究、攻防验证和企业落地。

重要说明：本文只讨论授权环境下的代码审计、漏洞发现、验证和修复闭环。不提供真实目标攻击步骤、可复制 exploit payload、绕过技巧、批量扫描脚本或武器化利用链。实战用例均为脱敏/抽象场景，用于说明方法。

先给结论：AI 能让漏洞研究更快，但不能让责任消失

漏洞研究不是“看到一段危险代码，然后模型说有洞”这么简单。真正的漏洞发现至少要回答四个问题：这段代码是否可达？输入是否可控？危险操作是否真的发生？有没有权限、校验、边界检查或业务约束挡住它？

大模型擅长的是读代码、整理上下文、形成假设、解释工具输出、生成测试思路和修复建议。它不擅长的是保证事实完全正确、替你承担授权边界、自动判断业务影响、在复杂系统里独立给出最终结论。

图 1：AI 漏洞猎手不是单模型，而是一条研究流水线

核心要点：AI 漏洞猎手的目标不是“自动攻击”，而是把安全研究从散点经验变成可追踪、可复核、可交付的工程流程。

为什么现在值得写这个题

过去几年，AI 安全能力的讨论经常停在两个极端：一边认为 LLM 只是会写解释，找不到真漏洞；另一边认为 AI 很快会自动攻破所有系统。两种说法都太粗糙。

更接近现实的变化有三条。

第一，代码上下文窗口变大，模型可以一次读更多文件、更多调用链、更多配置和测试。它不一定能自己证明漏洞，但能更快定位“值得审”的路径。

第二，安全工具链正在被 AI 包装成 agent 工作流。Google Project Zero 的 Project Naptime 把 LLM 放进类似安全研究员的工具环境里，让模型可以浏览代码、运行工具、形成假设、迭代验证。Big Sleep 则进一步展示了 AI agent 在真实开源项目中发现漏洞的案例。

第三，fuzzing、SAST、CI、安全修复正在变成一条自动化流水线。Google OSS-Fuzz 的 LLM fuzz target generation、DARPA AI Cyber Challenge、CodeQL、Semgrep 等资料都说明，AI 最有价值的落点不是“凭空找洞”，而是和已有工具结合。

核心要点：AI 漏洞猎手不是一个“模型能力”问题，而是一个“工具链编排”问题。

三个角色：LLM、工具、人类审计员

一个可靠的 AI 漏洞发现系统，至少有三个角色。

LLM 负责语义理解和假设生成。它能读懂“这个接口像是改订单状态”“这里缺少 tenant 校验”“这个 sanitizer 只处理了 HTML，没有处理 SQL 语义”。这些判断很像安全研究员的初筛。

工具负责事实约束。CodeQL、Semgrep、编译器、测试框架、fuzzer、依赖扫描器、SBOM、日志和运行时监控，负责告诉系统：路径是否存在、输入是否可控、sink 是否可达、crash 是否稳定、依赖是否真的被调用。

人类审计员负责边界、优先级和最终结论。尤其是业务漏洞，模型和工具很难单独判断“这个操作是否应该允许”。人要确认授权范围、业务语义、影响等级、修复方式和披露流程。

图 2：LLM、工具和人类审计员的分工

一个常见误区是让 LLM 单独审计整个仓库。这样做容易得到“看起来很专业”的结论，但无法知道证据是否可靠。更稳妥的方式是让模型围绕工具输出工作：先有可追踪证据，再让模型解释、关联和补全。

实战用例一：权限校验缺失怎么审

假设一个内部系统有订单退款接口。AI 漏洞猎手不会直接去构造攻击请求，而是先做代码审计。

第一步，它从路由表和 controller 中定位退款入口，提取调用链：refundController -> refundService -> paymentClient。第二步，它识别关键业务对象：订单、租户、用户角色、退款金额、审批状态。第三步，它沿着数据流追踪用户输入如何进入退款服务，重点看是否经过身份认证、租户隔离、订单归属校验和金额审批。

如果模型发现“退款前检查了登录态，但没有校验订单是否属于当前租户”，它不能直接下结论说“存在漏洞”。它还要要求工具或审计员补证据：这个入口是否对普通用户开放？订单 id 是否用户可控？服务层是否有统一拦截器？数据库查询是否自动带 tenant\_id？是否存在上游网关策略？

图 3：权限校验缺失的 AI 审计链路

这个用例的价值在于：AI 不是替你“打接口”，而是帮你把审计问题结构化。安全团队最终交付的不是一句“这里可能越权”，而是一条证据链：入口、可控输入、缺失校验、敏感操作、修复建议、回归测试。

核心要点：AI 做代码审计，最重要的是把“猜测”升级成“证据链”。

实战用例二：依赖漏洞影响判断

企业经常遇到这样的告警：某个依赖版本存在 CVE，扫描器报高危，但业务团队不知道自己是否真的受影响。AI 在这里可以做“影响面分析助手”。

它可以先读取 SBOM、依赖树和锁文件，确认漏洞组件是否存在；再结合调用图和 import 关系判断业务是否调用了受影响 API；然后读取框架配置，判断是否启用了相关功能；最后输出一个影响判断：已调用且配置满足触发条件、已安装但未调用、仅测试依赖、版本不受影响、需要人工确认。

这里 AI 的价值不是替代漏洞库，而是把“漏洞情报”翻译成“本系统是否受影响”。它能自动读 release note、CVE 描述、依赖树和项目代码，生成一份安全团队和业务团队都能看懂的影响分析。

实战用例三：Fuzzing crash 怎么归因

Fuzzing 的难点不只是生成输入，而是把“崩溃”变成“可修的漏洞”。AI 可以参与三个环节：生成 fuzz harness、解释 crash log、辅助最小化复现和修复测试。

例如一个解析库暴露了 parse\\_message() 函数。AI 可以根据公开 API 文档生成一个 harness 草案，编译失败后根据错误日志调整类型和初始化逻辑。fuzzer 跑出 crash 后，AI 读取栈信息、输入结构和最近代码变更，给出归因假设：空指针、越界、状态机未处理、长度字段不一致、递归深度失控等。

图 4：AI + Fuzzing 的闭环

需要注意，AI 生成的 harness 不一定正确，crash 归因也可能误判。可靠流程必须让编译器、fuzzer、sanitizer、单测和人工 review 来约束模型输出。

核心要点：AI 让 fuzzing 更像“研究助理”，但 crash 是否构成漏洞，仍要靠可重复证据和人工判断。

Agentic 漏洞研究：从一次性问答到假设循环

Project Naptime 和 Big Sleep 的启发在于：AI 漏洞发现不应该是“问模型有没有漏洞”，而应该是让模型在受控环境里形成假设、调用工具、观察证据、修正假设。

一个典型循环是：模型先读代码和文档，提出“这里可能存在边界检查缺失”；然后调用代码搜索、静态分析或测试工具；如果证据不足，它继续缩小范围，寻找更具体的触发条件；最后输出报告，说明证据、影响、限制和修复建议。

图 5：Agentic 漏洞研究的假设循环

这一套流程对企业非常重要。因为安全团队不只需要“发现一个问题”，还要知道 AI 是怎么得出结论的。没有审计痕迹，AI 找到的问题很难进入正式漏洞管理流程。

攻防验证的边界：证明风险，不制造攻击手册

安全验证需要足够具体，否则业务团队不会修。但具体不等于把攻击链写成教程。一个合格的 AI 漏洞猎手文档，应该区分“证明风险需要的证据”和“可滥用的利用细节”。

图 6：攻防验证的安全边界

这不是为了把文章写浅，而是为了让它能被企业安全团队、研发团队和管理层同时使用。内部文档也会流转，安全边界必须写进方法论里。

AI 漏洞猎手的局限

AI 很适合加速安全研究，但它有几个硬限制。

第一，模型会幻觉。它可能把不存在的函数、配置或调用路径写得很像真的。第二，模型容易忽略框架隐式行为，例如统一鉴权中间件、ORM 默认过滤、编译条件和环境变量。第三，模型会被上下文截断影响，看到局部代码就下全局结论。第四，模型不能独立判断业务语义，比如“客服能不能退款”“租户管理员能不能查看子账号数据”。

AI 的正确定位不是“替代审计员”，而是“让审计员带着更好的上下文、更完整的证据、更快的工具循环工作”。

企业落地：把 AI 放进漏洞管理流水线

企业要落地 AI 漏洞猎手，不能只买一个聊天窗口。更合理的架构是：代码仓库、SAST、依赖扫描、fuzzing、CI、漏洞工单、修复和回归都接入统一流程，让 AI 在每一步做它擅长的事。

图 7：企业 AI 漏洞猎手落地架构

上线前，建议至少检查 12 项。

核心要点：AI 漏洞猎手不是一次性工具，而是一条可审计、可度量、可回归的安全工程流水线。

五个常见问题，直接给答案

1. AI 现在能不能独立发现真实漏洞？

能在某些受控条件下发现真实漏洞，公开资料中 Big Sleep 就是重要案例。但企业不能把它理解成完全自动化。真实环境仍然需要工具证据、人类复核、授权边界和修复闭环。

2. AI 代码审计和传统 SAST 谁更可靠？

它们解决的问题不同。SAST 更适合可形式化规则和数据流追踪；AI 更适合理解业务语义、解释结果、生成假设和写报告。最可靠的是组合使用。

3. AI 能不能写 PoC？

在授权靶场和内部实验环境里，可以让 AI 辅助生成最小化验证思路和回归测试。但正式文章和知识库不应沉淀可直接滥用的 exploit payload、绕过步骤或攻击链。

4. AI 找洞最大的风险是什么？

不是“找不到洞”，而是把不确定结论写得过于确定，或者把安全验证越界成攻击操作。企业落地必须强制证据链、人工复核和授权边界。

5. 第一个落地点应该选哪里？

建议先选代码审计 triage、SAST 告警解释、依赖漏洞影响判断和 fuzzing harness 生成。这些场景收益明确，风险可控，也容易用确认率、误报率和修复时间衡量。

最后的判断

AI 漏洞猎手真正改变的是安全研究的工作方式。过去，研究员要在代码、规则、日志、测试和报告之间来回切换；现在，AI 可以把这些碎片串成一个更快的假设验证循环。

但这条路的前提不是让模型拥有更大的攻击权限，而是给它更好的工具、更清楚的边界、更可靠的证据和更严格的人类复核。

值得收藏的一句话：AI 漏洞猎手的价值，不在于替你攻击系统，而在于更快地把“可能有洞”变成“有证据、可修复、可回归”的安全结论。

参考资料

·[1] Google Project Zero, Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models
https://projectzero.google/2024/06/project-naptime.html

·[2] Google Project Zero, From Naptime to Big Sleep
https://projectzero.google/2024/10/from-naptime-to-big-sleep.html

·[3] DARPA, AI Cyber Challenge
https://www.darpa.mil/research/programs/ai-cyber

·[4] Google Security Blog, AI-Powered Fuzzing: Breaking the Bug Hunting Barrier
https://security.googleblog.com/2023/08/ai-powered-fuzzing-breaking-bug-hunting.html

·[5] OSS-Fuzz, LLM target generation
https://google.github.io/oss-fuzz/research/llms/target\_generation/

·[6] GitHub CodeQL Documentation
https://codeql.github.com/docs/

·[7] GitHub CodeQL, Data flow and taint tracking
https://codeql.github.com/docs/writing-codeql-queries/about-data-flow-analysis/

·[8] Semgrep Docs, Semgrep Code
https://semgrep.dev/docs/semgrep-code/overview

·[9] MITRE CWE
https://cwe.mitre.org/

·[10] NIST SP 800-218, Secure Software Development Framework
https://csrc.nist.gov/pubs/sp/800/218/final

·[11] OpenAI, Disrupting malicious uses of AI by state-affiliated threat actors
https://openai.com/index/disrupting-malicious-uses-of-ai-by-state-affiliated-threat-actors/