01 · LLM辅助代码审计与漏洞线索生成
代码审计是漏洞挖掘链条中最依赖专家经验的环节，也是LLM最先产生实质增量的环节。其核心范式可归纳为"LLM理解语义 + 传统工具提供精度"的混合架构：静态分析器负责无遗漏的广覆盖扫描（代价是高误报），LLM负责对每个告警进行语义级裁决——这个函数的真实业务语义是什么、这条数据流是否可达、这个告警在该上下文中是否可被利用。
1.1 技术机制：从告警消歧到自主审计代理
- 语义消歧（Alert Triage）。针对Semgrep/CodeQL等工具产生的海量告警，LLM结合代码上下文、调用链与业务注释进行逐条裁决与根因解释，可将分析师待处理告警压缩一到两个数量级。这是当前企业侧落地最成熟的形态。
- Source/Sink 定位。将安全规则表述为自然语言（"追踪用户输入到命令执行的完整路径"），由LLM生成数据流查询或定向审计计划，弥补规则库对新型漏洞模式覆盖滞后的问题。
- 审计代理（Auditing Agent）。更进一步的做法是把审计过程建模为Agent任务：模型自主规划审计路径、调用检索与静态分析工具、迭代验证假设。2025年以来，多个开源审计Agent（如基于Claude的Vulnhuntr等）在数小时内在热门GitHub项目中找到了十余个0-day，引发了"人人皆可审计"的能力平权讨论。
1.2 代表性研究（均可公开核实）
| 成果 | 发表/出处 | 核心贡献 | 关键结果 |
|---|---|---|---|
| Zero-Shot Fuzzers | Deng et al., ISSTA 2023 | 证明LLM无需领域适配即可作为通用测试输入生成器 | 在深度学习库等目标上，仅凭通用提示即可触发输入有效性错误，开启"LLM即Fuzzer"研究线 |
| CodaMosa | Lemieux et al., ICSE 2023 | LLM与覆盖引导Fuzzing的混合测试生成 | 当代码覆盖陷入平台期时，由LLM探索新的输入类型，突破传统变异算子的表达边界 |
| TitanFuzz / FuzzGPT | Deng et al., ICML 2023 | 首次用LLM测试深度学习库与编译器 | 在PyTorch、TensorFlow等成熟库中发现大量缺陷，展示LLM生成"语法与语义双重合法"输入的能力 |
| WhiteFox | OOPSLA 2024 | LLM增强的编译器/语言实现白盒测试 | 在GCC等被fuzz多年的成熟目标上发现此前遗漏的缺陷 |
| OSS-Fuzz-Gen | Google, 2024（开源项目） | LLM自动生成Fuzzing harness并接入OSS-Fuzz流水线 | 将"为新项目接入持续Fuzzing"的冷启动成本降至自动化流程，体现产业界对该范式的规模化采纳 |
| PentestGPT | Deng et al., USENIX Security 2024 | 首个系统化评估LLM自动渗透测试交互框架的研究 | 在真实授权靶场中以多轮交互引导完成渗透测试各阶段任务，公开了交互基准与失败案例分析，验证了LLM作为渗透助手的可行性与当前局限 |
1.3 产业侧验证：XBOW与"机器众测"的登场
学术研究之外，2025年出现了更具信号意义的产业事件：AI漏洞挖掘公司XBOW登顶HackerOne美国排行榜，成为首个在该平台超越全部人类白帽黑客的自主系统——据其官方博客及平台数据，其在约90天内提交近1,060份漏洞报告（经项目方定级：54个严重级、242个高危级、524个中危级），其中130余个已被项目方确认修复、303个进入处置流程，约45%仍待响应——报告洪峰对平台验证能力的冲击同步显现。在其自建、未用于模型训练的104个仿真挑战基准上，厂商及媒体报道的对照测试显示其约28分钟完成了人类渗透测试员约40小时的工作量（约80–85倍）；该数字为受控基准环境下的对比结果，引用时应保留口径限定。此外，其报告了Palo Alto GlobalProtect VPN中一个影响2,000余台主机的此前未知漏洞（厂商口径）。这一事件的意义不在于单次成绩，而在于漏洞赏金市场的供需结构首次被机器改写：报告洪峰之下，平台与厂商的验证、响应与修复管线成为新的瓶颈。
误读警示："AI找到N个漏洞"不等于"N个可被利用"。多数厂商披露的漏洞计数未经独立复现，严重级别的认定也依赖厂商自身评级。阅读此类数据时，请始终追问三个问题：是否有可复现的PoC？是否经第三方验证？是否区分了"疑似"与"确认"？
02 · 智能模糊测试：LLM给Fuzzer装上"语义大脑"
传统Fuzzing的核心弱点是"懂语法、不懂语义"：变异引擎可以生成海量合法输入，却不知道程序"应该"做什么。LLM的介入方式有四种典型角色：种子生成（生成语义丰富的初始语料）、Harness合成（自动编写测试桩）、字典/语法推断（从文档与代码中提取输入结构）、状态机探索（对协议类目标规划会话序列）。
2.1 代表性研究脉络
| 成果 | 发表/出处 | LLM承担的角色 | 关键结果 |
|---|---|---|---|
| Fuzz4All | Xia et al., ICSE 2024 | 通用多语言输入生成器 | 以统一框架对C/C++、Java、Rust等多种语言处理器生成测试输入，多篇独立复现确认其相对传统fuzzer的覆盖优势 |
| LLM-guided Protocol Fuzzing | Meng et al., NDSS 2024 | 从协议文档推断输入结构与会话逻辑 | 仅凭RFC等协议文档即可对主流协议实现开展有效fuzzing，显著降低协议审计门槛 |
| KernelGPT | ASPLOS 2025 | 内核驱动交互harness自动合成 | 面向Linux内核驱动自动生成syscall交互序列，缓解内核fuzzing长期以来依赖人工编写驱动的痛点 |
| Buttercup | Trail of Bits, AIxCC 2025（开源） | 在libFuzzer骨架上注入LLM语义种子 | AIxCC亚军系统：以经典覆盖率引导fuzzer为底座、LLM负责"语义无感"的用例设计，取得高补丁准确率与最优成本结构，赛后开源 |
2.2 范式判断：生成式不会取代变异式
一个容易被标题党掩盖的事实是：AIxCC决赛成绩最好的系统中，没有一支采用"纯LLM生成"路线。冠军ATLANTIS的架构是"符号执行+定向fuzzing+静态分析"的多技术编排，LLM承担定位、分析与补丁角色；亚军Buttercup以libFuzzer为骨架；对AIxCC全赛程的SoK复盘进一步指出，约半数赛题可被基础技术解决，LLM的价值体现在攻克剩余难题与串联全链路。当前工程共识是：LLM是Fuzzing的加速器与导航仪，而非替代发动机——覆盖率反馈的搜索效率与LLM的语义先验是互补关系。
03 · 崩溃分析、可利用性判定与补丁合成
发现崩溃只是开始。一个成熟的自动化系统必须把"崩溃"加工成"可处置的安全结论"：根因是什么、是否可稳定复现、能否被利用、如何修复且不引入回归。这三个环节恰是LLM"阅读-推理-生成"能力的最佳舞台，也是AIxCC评分体系（PoV验证+补丁质量）刻意考察的维度。
3.1 端到端架构解剖：从Naptime到ATLANTIS
Project Naptime / Big Sleep（Google）
Google Project Zero与DeepMind合作的漏洞研究Agent。其架构的关键设计是工具化环境：模型不直接"想象"漏洞，而是在可反复执行的沙箱中调用代码浏览、调试器、模糊器等工具，用执行反馈校正推理——这直接回应了LLM幻觉问题。2024年11月在SQLite中发现可利用栈缓冲区下溢（Google自家OSS-Fuzz持续fuzz多年未发现）；2025年8月一次性披露20个自主发现的真实0-day（FFmpeg、ImageMagick等）。
ATLANTIS（Team Atlanta, AIxCC冠军）
由佐治亚理工、三星研究院、KAIST、POSTECH组成的Team Atlanta开发的夺冠系统（技术报告公开），采用四模块流水线：威胁定位（Threat Localization）→ 分析（Analysis）→ 分诊（Triage）→ 补丁生成（Patch Generator），底层以符号执行、定向fuzzing与静态分析为执行引擎，LLM负责语义理解与决策编排。其决赛领先第二名170余分，胜在全程稳定性与补丁质量。
Buttercup（Trail of Bits, AIxCC亚军）
以libFuzzer为骨架的"AI增强fuzzing"路线：LLM不主导搜索，而是生成语义细腻的种子与诊断信息，在经典覆盖率反馈之上叠加语义层。该路线成本结构最优，赛后作为开源CRS发布，被OpenSSF评价为"对产业界最具直接借鉴意义"的架构之一。
补丁合成的学术基座：SWE-bench
Jimenez et al.（NeurIPS 2023）提出的SWE-bench基准，用真实GitHub issue检验"端到端修复真实代码问题"的能力，已成为Agent修复能力的标准度量。其方法论启示同样适用于漏洞修复：以真实仓库、真实issue、可执行测试集作为唯一可信的验收标准，拒绝"看起来对"的补丁。
3.2 效率的量化：45分钟与152美元
DARPA官方复盘给出的决赛运营数据极具冲击力：单个赛题任务的平均完成成本约152美元（含算力与模型积分），平均补丁耗时约45分钟。作为对照，行业统计中人工修复一个关键Web应用漏洞的中位周期约35天。即便考虑赛题环境与生产环境的差异，这两个数量级的差距也足以说明：瓶颈正在从"发现"向"组织流程"转移——企业的修补流水线、变更审批与回归测试体系，将成为下一个十年安全建设的真正主战场（第3页第2节展开）。
赛事资源数据同样值得记录：每支决赛队伍获配85,000美元Azure算力额度与50,000美元大模型API额度；SoK复盘显示，七支队伍中五支的LLM额度消耗不足25%——瓶颈在算力编排、工程稳定性与验证管线，而非模型调用本身（来源：SoK论文资源使用分析，机构评估口径）。
04 · 端到端系统与里程碑事件总表（2024–2026）
4.1 AIxCC决赛全景：成绩、赛制与启示
2025年8月8日，DARPA在DEF CON 33主舞台公布AIxCC决赛成绩。决赛共7支队伍（从42支DEF CON 32半决赛参赛队伍中脱颖而出：42-b3yond-6ug、all_you_need_is_a_fuzzing_brain、Lacrosse、Shellphish、Team Atlanta、Theori、Trail of Bits，各获200万美元研发资助），其CRS在约5,400万行真实开源代码上连续自主运行约143小时、分七个阶段完成任务（据SoK论文复盘，赛题涉及Linux内核、Wireshark、SQLite、shadowsocks等广泛部署的真实项目；赛事方未完整公开项目清单）。赛后，竞赛管理方复核修正植入合成漏洞数为63个（原公告为70个），识别数54个不变。
成绩侧的确定性
- 7支队伍中前四名均实现60%以上识别率，能力并非个别团队的孤例；
- 冠军Team Atlanta（400万美元）、亚军Trail of Bits（300万美元）、季军Theori（150万美元）的全部前三名系统均已开源；
- 赛后陆续披露：决赛系统发现的18个真实0-day中，部分存在于网络边缘设备常用组件——真实世界影响开始兑现。
结构性的隐忧
- 赛事评论员与研究者指出同一个事实：去掉"补丁"阶段的CRS，就是一个功能完整的进攻系统——检测与利用占系统工作量的绝大部分，补丁只是最后一道工序；
- SoK复盘显示部分系统存在严重稳定性问题（中途崩溃、得分遗漏），"自主"距离"可靠"仍有工程差距；
- 多支决赛系统开源后，同类能力的私有化部署门槛已大幅降低——攻防能力扩散不可逆。
4.2 2024–2026里程碑事件总表
下表按时间顺序收录本课题引用的全部关键事件，每条均给出可溯源的公开出处（详见第3页参考文献）。
| 时间 | 事件 | 事实要点 | 出处类型 |
|---|---|---|---|
| 2016.08 | DARPA CGC决赛 | 7台CRS全机器攻防，Mayhem夺冠（200万美元），陈列于史密森尼博物馆；确立"自动发现+自动修补"的竞赛范式。 | 赛事官方 |
| 2016.12 | Google OSS-Fuzz上线 | 对开源项目的持续化Fuzzing服务启动，论文发表于USENIX Security 2017；至今累计帮助修复数以万计漏洞。 | 论文+官方 |
| 2024.08 | AIxCC半决赛（DEF CON 32） | 42支队伍参赛、7支晋级决赛（各获200万美元研发资助）；CRS识别率约37%、修复率约25%。 | 赛事官方 |
| 2024.11 | Big Sleep发现SQLite 0-day | AI首次在广泛部署的真实软件中发现可利用内存安全漏洞（栈缓冲区下溢）；该洞潜伏多年、OSS-Fuzz未覆盖。 | Google官方博客 |
| 2025.06 | XBOW登顶HackerOne美区榜 | 首个超越全部人类白帽的自主系统；90天约1,060份有效报告，基准挑战速度约80倍于人工。 | 平台数据+媒体 |
| 2025.08 | AIxCC决赛（DEF CON 33） | 86%识别率、68%修复率、18个真实0-day、平均152美元/任务；ATLANTIS夺冠。 | 赛事官方+SoK论文 |
| 2025.08 | Big Sleep披露20个0-day | 一次性披露20个自主发现的真实0-day（FFmpeg、ImageMagick等），全部附自主复现过程。 | Google官方博客 |
| 2025.11 | GTG-1002事件披露 | Anthropic披露其9月检测到的行动：某国家背景组织将Claude Code武器化，针对约30个目标执行大规模网络间谍行动，AI承担约80–90%战术操作；披露同时承认模型存在幻觉与夸大成果现象——AI自动化首次进入国家级网络行动公开视野（厂商自披露口径，自主性数据未经独立验证）。 | 厂商披露 |
| 2026.01 | AISLE×OpenSSL 12个0-day | OpenSSL 1月27日安全更新修复的12个漏洞全部由AISLE的AI系统独立发现（含1个高危栈缓冲区溢出CVE-2025-15467），其中3个为1998–2000年引入、潜伏25–27年的古老缺陷，5个修复被官方采纳。 | 项目官方+机构披露 |
| 2026.02 | Anthropic 500+高危漏洞与Claude Code Security | 2月5日披露Claude Opus 4.6在生产级开源代码库中发现并验证500余个高危漏洞；2月20日Claude Code Security以受限研究预览形式发布。 | 厂商披露 |
| 2026.03 | Anthropic×Mozilla Firefox专项 | 两周内发现22个Firefox漏洞（14个高危级），并自动生成其中2个的可运行浏览器利用——AI生成浏览器利用的首次公开记录。 | 厂商联合披露 |
| 2026.04 | Mythos Preview与Project Glasswing | Anthropic发布受限安全模型并联合约50家机构（12家创始伙伴+约40家获批机构）启动Glasswing；扫描1,000余开源项目识别23,019个问题（6,202个高危/严重级），抽样1,752个经6家独立机构复核真阳率90.6%；承诺1亿美元额度与400万美元捐赠。 | 厂商披露+独立抽样复核 |
| 2026.04 | Firefox 150单版本修复271个漏洞 | Mozilla披露借助Claude Mythos Preview在Firefox 150中修复271个安全问题——主流浏览器首次大规模采纳AI辅助安全审计成果。 | 厂商联合披露 |
| 2026.06 | Mythos 5接棒与出口管制实践 | Mythos Preview由Mythos 5接替、Glasswing伙伴扩至约150家；同月美国商务部在出口管制框架下批准Mythos 5向100余家美国企业与机构开放——前沿模型漏洞能力首次被纳入出口管制实践。 | 官方/媒体报道 |
证据分级说明：赛事成绩与论文结果为"已证实事实"；厂商披露的0-day数量与真阳率为"机构评估"（自述口径）；表中"事实要点"仅转述公开披露内容，不代表本学院独立验证结论。
05 · 能力边界的冷静评估
高质量的研究著作必须同时写明"能做什么"与"不能做什么"。综合学术论文、赛事复盘与厂商披露，当前AI自动化漏洞挖掘的能力边界可归纳为五条：
- 边界一：幻觉没有消失，只是被验证器约束。LLM可能生成看似合理实则错误的根因分析与补丁。行业通行解法是"外部验证管线"——以编译、执行、回归测试作为裁决标准（AIxCC的PoV验证、SWE-bench的可执行测试集同理）。脱离验证管线的"裸模型输出"不构成安全结论。
- 边界二：基准成绩 ≠ 实战能力。植入式基准（LAVA-M/Magma）与赛题环境便于评判，但真实代码库的噪声（误报来源、业务复杂度、环境依赖）远高于基准。AIxCC SoK复盘明确指出：约半数赛题可被基础技术解决，真实0-day发现率与成本收益比仍是开放问题。
- 边界三：维护者侧出现"报告洪峰"反噬。能力普及的另一面是开源维护者的 triage 负担激增——大量AI生成的报告质量参差，知名项目维护者已公开抱怨低质量AI报告消耗社区精力。自动化发现的规模越大，验证与协同披露机制越重要。现实中的反噬已经出现：curl维护者因AI生成报告洪峰于2026年1月宣布终止已运行六年的漏洞赏金计划（该项目自2019年以来为81个真实漏洞支付逾9万美元）；同期AISLE等高质量AI报告又为curl贡献多个真实CVE——同一技术既能淹没通道，也能产出金子，区分二者的成本正在成为社区的新负担。
- 边界四：对抗性代码是新的攻防面。攻击者可故意编写针对AI审计弱点的混淆代码（误导性变量名、伪装无害的业务逻辑），形成"反AI审计"对抗；同时，AI审计工具自身的供应链（提示词、插件、模型来源）也成为攻击目标——与本专题"大模型安全攻防"课题直接相关。
- 边界五：端到端可靠性仍是工程深坑。AIxCC约143小时自主运行中，多支队伍的系统在后期阶段崩溃或得分遗漏；SoK的关键结论（KF1）即"稳定性与准确性是CRS的决定性因素"。实验室演示与生产级系统之间，隔着大量不显山露水的工程细节。
- 边界六：补丁本身成为新的攻击面。当AI生成补丁大规模进入开源仓库，攻击者可借"看似修复"的PR植入隐蔽后门（业界已以XZ Utils事件为镜鉴推演该风险）；评审AI生成补丁的能力与工具链建设，将决定"机器修复"红利能否安全兑现。
5.1 厂商披露数据的证据分级速查表
第4.2节事件总表中的量化数据，按证据强度可分为三级：已证实事实（赛事官方成绩、可公开复核）、机构评估（厂商/政府研究机构自述、经部分复核）与研究推断（本专题归纳）。下表逐条标注，引用时务必连同证据级别一并使用：
| 量化声明 | 披露主体 | 证据级别 | 引用注意事项 |
|---|---|---|---|
| AIxCC决赛：86%识别率、68%修复率、18个真实0-day、约152美元/任务 | DARPA / OpenSSF | 已证实事实 | 植入漏洞数63个为管理方复核修正值；成绩档案已部分公开归档，可复核性最高。 |
| XBOW：90天约1,060份有效报告、基准速度约80倍于人工 | 平台数据+厂商 | 机构评估 | 计数依赖平台判定口径，未经同行评审复现；"速度80倍"为特定基准条件下的对比结果。 |
| Big Sleep：一次性披露20个真实0-day（FFmpeg、ImageMagick等） | Google官方博客 | 机构评估 | 附自主复现过程描述，可信度较高；漏洞细节与可利用性评级仍属厂商自述口径。 |
| Anthropic：模型在开源代码库中发现500余个高危漏洞（2026-02） | 厂商披露 | 机构评估 | 未见独立抽样复核数据，引用时应保留"厂商报告"限定词。 |
| AISLE：12个OpenSSL 0-day（2026年1月更新，3个为25–27年古老缺陷，5个修复被采纳） | 安全研究机构（AISLE） | 机构评估 | 获OpenSSL官方安全公告背书，可信度较高；完整复现细节未公开。 |
| Anthropic×Mozilla：两周22个Firefox漏洞、2个可运行浏览器利用 | 厂商联合披露 | 机构评估 | 联合披露已含可利用性验证环节；建议以"首次公开记录"的定性方式引用。 |
| Mythos：23,019个问题、6,202个高危/严重、抽样真阳率90.6%（1,752个抽样，6家独立机构） | 厂商披露+独立抽样复核 | 机构评估 | 真阳率经独立安全机构抽样复核，是本表中复核强度最高的厂商数据，但仍非全量验证。 |
小结：AI自动化漏洞挖掘今天的真实定位是——一位不知疲倦、偶有幻觉、必须被验证器约束的初级研究员。把它当作替代安全团队的银弹，会在误报洪峰与错误补丁中付出代价；把它当作放大专家带宽的杠杆，并以工程化验证闭环兜底，则是当前唯一被大规模证据支持的正确姿势。这一判断直接支撑第3页的企业落地路线图。