Long-form Technical Research Report

基于大模型智能体的开源项目安全缺陷自动审计、漏洞挖掘、验证与利用技术调研报告

面向网络空间安全专业学生与课程评审的长篇技术研究报告。在完整保留调研论证的基础上，通过章节导读、关系图解、术语辅助和证据口径改善阅读与理解。

展开阅读导航

#摘要

大语言模型（Large Language Model，LLM）与智能体（Agent）技术正在改变软件安全审计和漏洞研究的自动化边界。早期研究通常将漏洞检测视为代码片段分类问题，近年来则逐步转向面向真实仓库的全项目理解、工具调用、多智能体协作、跨文件数据流推理、攻击面建模、动态验证、PoC 生成、修复与回归验证。与此同时，传统程序分析、模糊测试、符号执行、自动利用生成和运行时取证并未被 LLM 取代；相反，当前高质量研究越来越强调将 LLM 的语义理解与 CodeQL、Joern、Semgrep、AFL++、libFuzzer、KLEE、angr、Sanitizer、Nuclei 等确定性工具结合，形成“神经-符号-动态执行”混合链路。

本文围绕课程选题一“基于大模型智能体的开源项目安全缺陷自动审计和验证系统”，系统调研以下内容：

  1. 代表性开源或公开研究系统，包括 DeepAudit、AgentStalker、OpenSecurity、ESAA-Security、Sandyaa、Vulnhuntr、OpenAnt、Visa VVAH、GitHub Security Lab Taskflow Agent、RepoAudit、RAPTOR、PentestGPT 等；
  2. 经典与现代漏洞挖掘工具，包括 CodeQL、Semgrep、Joern、AFL++、libFuzzer、syzkaller、boofuzz、WinAFL、KLEE、angr、Triton、Ghidra、Qiling 等；
  3. 漏洞验证、PoC 和利用相关工具，包括 Nuclei、OWASP ZAP、sqlmap、Commix、Metasploit、pwntools、rex、Mechanical Phish 等；
  4. 运行时验证、沙箱和证据固化技术，包括 ASan、UBSan、CASR、rr、Tracee、nsjail 和 gVisor；
  5. 代表性论文、工业界实践与 2025-2026 年最新研究动态；
  6. CyberGym、CyberGym-E2E、CVE-Bench、ExploitGym、SEC-bench Pro、CWE-Bench-Java、Vul4J、Magma、NIST SARD/Juliet 等评测基准；
  7. 当前仍未解决的核心问题和具有研究价值的创新方向。

调研表明，当前研究前沿已经从“LLM 能否发现漏洞”转向“如何构建可靠、可验证、可复现的自动化漏洞研究 Harness”。项目级上下文选择、程序图与 LLM 的结合、发现与验证分离、对抗式验证、确定性运行时 Oracle、可利用性分级、差分验证、自动生成 、闭环覆盖反馈和可重放证据链，是目前最值得关注的研究方向。

关键词：大语言模型；智能体；代码审计；漏洞挖掘；静态分析；程序分析；模糊测试；漏洞验证；PoC；自动利用生成；证据链；可复现安全研究

阅读说明

页面中的图解用于替代或压缩原文中的关系表达，不新增实验数字，也不把项目方自述改写为独立验证结论。带虚线的术语可悬浮、聚焦或点击查看上下文解释。

证据口径

Source Type 学术论文 / 官方文档 / 官方项目 / 机构技术文章 / 二手资料

Claim Status 论文实验结果 / 官方自报结果 / 项目方自述 / 独立事实 / 作者综合判断 / 待进一步核验

实体 Tag 图例
系统Agent、Harness、研究原型
工具CLI、框架、分析器、Fuzzer
论文学术论文或研究成果
基准Benchmark、Dataset、Suite
实践工业实践、竞赛、机构计划

#报告阅读地图

#1. 调研范围、资料来源与可信度说明

#1.1 与课程任务的对应关系

漏洞研究生命周期

该流程来自原文 1.1，用于对应课程选题一从仓库解析到证据链和报告的完整链路。

  1. Repository Understanding
  2. Vulnerability Discovery
  3. Reachability / Data-flow Reasoning
  4. Independent Verification
  5. PoC / Trigger Construction
  6. Runtime Observation
  7. Impact Confirmation
  8. Evidence Preservation / Replay
  9. Patch / Regression Validation

课程选题一要求实现从开源代码仓库解析、智能体审计、工具调用、漏洞复核、自动利用、证据链到结构化报告的完整链路，并要求对不少于 20 款主流开源项目进行检测。因此，本调研不把“漏洞检测”局限为传统 ，也不把“漏洞利用”简单等同于生成一段 exploit 代码，而是覆盖上方流程图所示的完整研究生命周期。

这一范围与课程对“误报过滤、自动漏洞利用、证据链、验证结果”的要求直接对应。

#1.2 资料优先级

本文按照以下可信度层级使用资料：

A级
顶级或主流会议论文、正式论文、官方技术文档、官方代码仓库；
B级
高质量 arXiv 预印本，尤其是同时公开代码、数据集或评测脚本的研究；
C级
Google Project Zero、DARPA、GitHub Security Lab、Cloudflare、Visa、OpenAI、Anthropic 等机构的官方工程文章或产品研究报告；
D级
社区整理、Awesome 列表、二手博客，仅用于发现线索，不作为关键结论的主要证据。

Source Type 描述资料从哪里来；Claim Status 描述当前结论是什么性质。本文只在宣传性表述、定量实验和作者综合判断处显式标注，避免把每段正文都做成 Badge。

对于项目方自称“首个”“国内首个”“发现若干 CVE”等宣传性表述，本文均视为项目方自述，不直接等同于独立学术验证。对于厂商公开的扫描规模、漏洞数量和误报下降比例，也明确标记为官方自报结果。

#2. 技术演进综述：从规则扫描到 Agentic Vulnerability Research Harness

技术演进视图
传统阶段

规则、查询与程序分析

语法模式、AST、控制流、数据流、符号执行、Fuzzing 与 DAST；优势是可解释、确定、易复现。

LLM 阶段

从代码分类到项目语义理解

早期代码片段分类暴露跨文件上下文缺失、调用路径难验证和危险 API 误判等问题。

Agent 阶段

迭代式漏洞研究

模拟人工研究员形成假设、查看代码、运行工具、观察结果并修正假设。

2025-2026

Harness 成为核心研究对象

模型、上下文选择、工具、Agent 角色、状态管理、动态验证、证据与评测共同决定效果。

#2.1 传统阶段：规则、查询与程序分析

传统自动化代码审计主要依赖：

其典型工具包括 Semgrep、CodeQL、Joern、KLEE、AFL++、libFuzzer 等。传统方法的主要优势是：

  1. 结果可解释；
  2. 执行行为相对确定；
  3. 易于复现；
  4. 在已知漏洞模式上可规模化部署。

主要局限则包括：

#2.2 LLM 阶段：从代码分类到项目语义理解

早期 LLM 漏洞检测常见流程是：

代码片段
  ↓
Prompt
  ↓
Vulnerable / Safe

这种方法对真实项目存在明显问题：

因此，近年的研究开始转向：

Repository
  ↓
Structure / Graph / Threat Model
  ↓
Targeted Context
  ↓
LLM Reasoning
  ↓
Tool-assisted Verification

#2.3 Agent 阶段：从一次性回答到迭代式漏洞研究

Google Project Zero 的 Project Naptime 强调模拟人工漏洞研究员的工作方式：形成假设、查看代码、运行工具、观察结果、修改假设、继续调查。后续 Big Sleep 报告了一个在 SQLite 中发现并在正式版本发布前修复的真实可利用问题。这类工作说明，智能体的价值不只是“多轮聊天”，而是可持续的假设-工具-证据循环。

#2.4 2025-2026：Harness 成为核心研究对象

到 2026 年，公开研究和工业实践出现共同趋势：

因此，当前研究对象已经逐渐从单一模型转为：

#3. 代表性大模型智能体代码审计与漏洞研究系统

#3.1 DeepAudit

#3.1.1 项目定位

DeepAudit 是课件明确列出的参考系统，也是目前公开工程完成度相对较高的多智能体代码审计项目之一。其公开架构通常包含：

Orchestrator
    ↓
Recon / Repository Understanding
    ↓
Analysis / Audit Agent
    ↓
Verification Agent
    ↓
Sandbox PoC
    ↓
Report

其主要技术特点包括：

#3.1.2 研究价值

DeepAudit 最值得借鉴的不是“用了多个 Agent”，而是尝试将代码扫描、复核、PoC 和报告连接为闭环。这与课程题目要求高度一致。

#3.1.3 局限与注意事项

资料：DeepAudit GitHub★ 6.6k

#3.2 AgentStalker

#3.2.1 项目定位

AgentStalker 强调把 LLM Agent 或软件系统作为整体对象进行端到端安全审计，其公开方法包含：

Static Modeling
      ↓
Attack Graph Synthesis
      ↓
Sandbox Dynamic Verification
      ↓
Evidence Adjudication

其设计涉及：

#3.2.2 研究价值

AgentStalker 的重要贡献是把“漏洞发现”升级为“系统建模-攻击路径-动态证据-裁决”。这种思想比单纯输出漏洞清单更符合可验证安全研究。

#3.2.3 局限

公开资料也提示其仍存在：

因此，更适合把它视为方法论和研究框架，而不是已经充分验证的通用工业扫描器。

资料：AgentStalker GitHub★ 128

#3.3 OpenSecurity

OpenSecurity 更接近 AI 驱动的多领域安全分析平台，而非单一代码漏洞扫描器。其规划通常覆盖：

其核心启示是三层分工：

AI Orchestration
       ↓
Deterministic Security Tools
       ↓
Knowledge / Evidence

这种架构强调：LLM 适合做工具编排、假设形成和语义解释，而 AST、反汇编、数据流、文件哈希、执行结果等事实应由确定性工具产生。

资料：OpenSecurity GitHub★ 34

#3.4 ESAA-Security

#3.4.1 核心思想

ESAA-Security 的代表性思想是 ，即事件溯源式智能体架构。它不把一次安全审计视作不可解释的对话，而是将每个阶段记录为事件：

RepositoryParsed
CandidateFound
PathConfirmed
VerifierStarted
PoCGenerated
SandboxExecuted
EvidenceCaptured
VerdictIssued

事件日志具有：

#3.4.2 研究意义

这一路线直接回应了 LLM 安全审计的核心缺陷：

与自由形式 Agent 相比，事件溯源更接近安全工程所需要的审计轨迹和证据链。

资料：ESAA-Security 论文arXiv · Preprint · 2026

#3.5 Sandyaa

Sandyaa 是 2026 年出现的自主代码审计项目，其公开思路强调“递归深入直到证明真实漏洞”。其分析能力包括：

与一次性扫描不同，Sandyaa 代表一种递归研究模式：

Candidate
   ↓
Need More Context?
   ↓
Follow Call / Data Flow
   ↓
Update Hypothesis
   ↓
Try to Prove or Falsify

其研究价值较高，但项目仍处于较新、较早期阶段，适合观察思想而不宜把公开宣传直接视作成熟工业能力。

资料：Sandyaa GitHub★ 233

#3.6 Vulnhuntr

Vulnhuntr 是代码审计 Agent 中非常有代表性的“入口驱动”系统。其核心思想是：

典型路径：

Remote Input
     ↓
Entry Point
     ↓
Interprocedural Call Chain
     ↓
Potential Sink

其公开项目主要聚焦 Python，并涉及 LFI、RCE、SQLi、SSRF、IDOR 等漏洞类型。

#研究意义

Vulnhuntr 的重要价值在于证明“选择什么上下文”可能比“让模型看更多代码”更重要。其方法与后续的可达性裁剪、攻击面感知分析具有连续性。

资料：Vulnhuntr GitHub★ 2.7k

#3.7 OpenAnt

#3.7.1 技术路线

OpenAnt 是 2026 年非常值得关注的研究系统之一，主要面向真实开源项目中的输入传播类漏洞，包括：

其核心分为两部分。

第一部分是可达性驱动的代码裁剪：

External Entry Point
        ↓
Reachable Functions
        ↓
Security-sensitive Operations
        ↓
Analysis Unit

论文报告这种方法能够显著减少需要交给后续分析的代码表面，同时保留攻击相关路径。

第二部分是对抗式验证：

Defender / Finder
发现漏洞假设
       ↓
Attacker / Verifier
主动尝试推翻假设
       ↓
Sandbox Dynamic Validation
       ↓
Surviving Finding

#3.7.2 研究意义

OpenAnt 代表当前非常清晰的研究方向：

  1. 不把全仓库直接交给模型；
  2. 不把“第二个 Agent 同意”当作验证；
  3. 验证者应主动查找不可达、不可控、已净化、需高权限等反例；
  4. 最终需要动态环境中的事实。

资料：OpenAnt 论文arXiv · Preprint · 2026；OpenAnt GitHub★ 666

#3.8 Visa Vulnerability Agentic Harness系统（VVAH）

#3.8.1 项目概况

Visa 在 2026 年 6 月公开 VVAH 参考实现，目标是组织完整的 Agentic Vulnerability Research 工作流。其公开阶段覆盖：

Discovery & Modeling
      ↓
Deep Dive & Verification
      ↓
Synthesis & Reporting
      ↓
Remediation & Validation

具体思路包括：

#3.8.2 研究价值

VVAH 的突出特点是 。它强调先理解：

这比“扫所有 CWE”更接近真实安全审计。

#3.8.3 公开局限

VVAH 官方资料也明确提醒：

这使 VVAH 成为很好的研究参考：它公开承认了 Agent 漏洞发现与“确定性确认”之间的鸿沟。

资料：VVAH GitHub★ 645

#3.9 Anthropic Defending Code Reference Harness

#3.9.1 项目定位

Anthropic 于 2026 年公开的 Defending Code Reference Harness 是当前公开程度最高、方法学完整度最强的漏洞研究参考实现之一，MIT 许可下开源，明确将其定位为"从与多家安全团队的合作实践中沉淀的最佳实践参考"。

其整体架构由 7 个专职智能体串联执行：

Build Agent
    ↓
Recon Agent
    ↓
N × Find Agent（并行）
    ↓
Verify / Grader Agent
    ↓
Judge Agent（去重）
    ↓
Report Agent
    ↓
Patch Agent + Patch Grader

#3.9.2 方法论：六阶段工作流

Harness 附带的博客将实践总结为六阶段方法论：

Threat Model
    ↓
Sandbox
    ↓
Discovery
    ↓
Verification
    ↓
Triage
    ↓
Patching

其中关键设计包括：

#3.9.3 官方公开的实证结果

Harness 官方博客一并公布了若干量化数据（属于官方自报）：

#3.9.4 研究意义

Anthropic Harness 有三方面价值明显高于同类系统：

  1. 完整覆盖发现—验证—分诊—修复全生命周期，且每阶段都有确定性校验点，直接对应课程要求的"证据链"和"可验证"目标；
  2. 以工程数据佐证"发现不再是瓶颈，验证与分诊才是"这一当前领域核心判断；
  3. 作为 Claude Code Skills 交付，与本调研第 3.10 节 GitHub Security Lab Taskflow Agent 一样体现出声明式工作流的趋势，且方法论蒸馏更彻底。

资料：Anthropic Defending Code Reference Harness★ 6.4k；官方博客：Defending Code with Claude

#3.10 GitHub Security Lab Taskflow Agent

GitHub Security Lab 的 Taskflow Agent 将安全 Agent 工作流写成声明式任务流，通常通过 YAML 描述：

其技术价值包括：

相比“一个万能 Prompt 扫所有漏洞”，Taskflow 体现出安全任务专门化趋势：

Auth Bypass Taskflow
IDOR Taskflow
Token Leakage Taskflow
Injection Taskflow

这类声明式流程对可重复实验尤其重要。

资料：GitHub Security Lab Taskflow Agent

#3.11 RepoAudit

RepoAudit 是面向仓库级漏洞发现的智能体研究，重点关注：

其研究意义在于将 Agent 的“搜索行为”纳入漏洞检测方法本身。模型不是一次性获得全部代码，而是在工具支持下逐步探索相关文件与路径。

资料：RepoAudit 论文arXiv · Preprint · 2025

#3.12 RAPTOR

RAPTOR 是一个公开的自主安全研究框架，其目标是把多类传统安全工具串联为统一研究工作流：

Static Analysis
      ↓
Repository / Binary Understanding
      ↓
LLM Validation
      ↓
Fuzzing
      ↓
Exploit Generation
      ↓
Patch Writing

公开项目涉及：

其最大的研究价值并不是某个单独算法，而是展示了 的正确方向：模型负责决定“下一步做什么”，工具负责产生静态路径、覆盖率、崩溃、编译和执行等事实。

同时，项目仍具有明显研究框架属性，自动 Exploit 等能力不宜视为已稳定覆盖任意真实项目。

资料：RAPTOR GitHub★ 3.3k

#3.13 Shannon

#3.13.1 项目定位

Shannon 是 Keygraph 于 2026 年公开、以 AGPL-3.0 开源的自主 AI Pentester，明确定位为"白盒 AI 渗透测试"，通过将源码静态分析与实时攻击相结合，在 PoC 成功前不将假设升级为漏洞。

其五阶段流程与本调研第 2.4 节强调的"假设—工具—证据循环"高度一致：

Pre-Reconnaissance（源码扫描：识别框架/入口）
        ↓
Reconnaissance（对目标应用的实时探测，与源码上下文对齐）
        ↓
Vulnerability Analysis（Injection/XSS/SSRF/Auth 等专项 Agent）
        ↓
Exploitation（真实 PoC，未证明的假设直接丢弃）
        ↓
Reporting（Markdown 报告 + 修复建议）

#3.13.2 技术特点

#3.13.3 研究意义

Shannon 与 Vulnhuntr 同属"以攻击面驱动上下文选择"的路线，但把攻击面覆盖从单一 Python 生态扩展到 Web 应用与 API，并把动态验证从"路径证据"升级为"真实 PoC 攻击成功"。它体现了当前领域从"发现候选"向"证明可利用"迁移的工程化实践。

#3.13.4 局限

资料：Shannon GitHub★ 45.5k

#3.14 PentestGPT

PentestGPT 并非专门的开源代码审计系统，而是 AI 辅助渗透测试的重要代表，因此属于相邻方向。

其原始研究强调将渗透过程拆分为：

现代版本进一步支持多模型交互式工作流。其价值在于展示了 LLM 如何维护攻击任务状态、规划后续步骤和解释工具输出。

对本课题而言，它更适合用于比较“代码审计 Agent”与“攻击任务规划 Agent”的差异，而不是作为直接代码扫描基线。

资料：PentestGPT GitHub★ 14.1k；PentestGPTUSENIX Security 2024

#3.15 AI 辅助逆向：GhidraGPT、GhidraMCP 与 GhidrAssist

GhidraGPT 属于 AI 辅助逆向分析方向的代表工作，当前更广泛的生态还包括 GhidraMCP、GhidrAssist 等项目。

它们通常实现：

这类工具对“源代码不可用”或“漏洞验证涉及二进制依赖”的项目有价值，但并非课程源码审计主线。

资料：GhidraG PT★ 400；GhidraMCP★ 9.4k

#3.16 AI-Infra-Guard

#3.16.1 项目定位

AI-Infra-Guard 是腾讯朱雀实验室公开的全栈 AI 红队平台，整合了 ClawScan、Agent Scan、MCP Server & Skills Scan、AI 基础设施 CVE 扫描与越狱评估五类能力，覆盖对 AI 基础设施与智能体生态的自动化安全评估。

#3.16.2 与本调研主题的关系

严格来说，AI-Infra-Guard 属于相邻方向：

因此本文将其归入相邻方向章节。它对本课题的可参考之处在于：基于 YAML 指纹与 CVE 规则的批量识别机制，可作为审计系统在处理项目依赖组件时的对照方案。

资料：AI-Infra-Guard GitHub★ 4.1k

#3.17 系统层面对比

系统/项目主要对象仓库级理解程序分析工具多 Agent动态验证PoC/Exploit证据/回放当前定位
DeepAudit源代码仓库是有是是有有工程型开源系统
AgentStalkerAgent/软件系统是图/污点是是有强调裁决研究框架
OpenSecurity多领域安全部分多工具是视 Agent 而定部分部分平台型项目
ESAA-Security审计流程间接可接入是可接入非核心很强架构研究
Sandyaa源代码是辅助自主递归有有evidence.jsonAlpha/早期项目
VulnhuntrPython 源码是调用链Agent主要静态部分路径证据专项研究工具
OpenAntOSS 源码是可达性分析对抗角色是验证导向是2026 前沿研究
Visa VVAH源码仓库是可接入是有验证阶段有有企业开源 Harness
Anthropic Harness源码仓库是Docker/ASan/gVisor是（7 类）强制 3/3 复现强制 PoC全阶段可复现一等企业开源参考
Taskflow Agent安全工作流是MCP/CodeQL是可编排可编排流程可复用声明式框架
RepoAudit真实仓库是路径/数据流Agent非核心非核心事实验证学术研究
RAPTOR源码/二进制是SAST/Fuzz是是有有研究型工具编排
ShannonWeb/API 源码是静动混合是（专项）是强制 PoCMarkdown 报告开源 AI Pentester
PentestGPT渗透测试目标级外部工具模块化是攻击规划过程记录相邻方向
AI-Infra-GuardAI 基础设施部分YAML/CVE 规则平台内多 Agent是（红队）已知漏洞报告相邻方向（AI 平台安全）

表中“有”表示公开设计或代码包含相关能力，不代表已经在所有语言、漏洞类型和真实项目上完成大规模独立验证。

#4. 漏洞挖掘工具体系

工具技术谱系
静态分析CodeQL / Joern / Semgrep / Bandit / gosec

候选告警、调用关系、数据流、程序切片

FuzzingAFL++ / libFuzzer / syzkaller / boofuzz

覆盖率、触发输入、Crash、Harness 质量

符号执行KLEE / angr / Triton / SymCC

路径约束、可达输入、二进制状态探索

二进制与固件Ghidra / Radare2 / Qiling / Binwalk

反编译、模拟执行、固件提取

PoC / ExploitNuclei / sqlmap / Commix / Metasploit / pwntools

结构化验证、专项利用、利用原型

运行时证据与沙箱ASan / UBSan / CASR / rr / Tracee / nsjail / gVisor

错误类型、回放、行为观测、隔离执行

本章按照“静态程序分析-模糊测试-符号执行-二进制与固件分析”的技术谱系整理开源工具。重点不是罗列工具，而是分析其能够提供什么类型的事实、适合解决什么研究问题，以及与 LLM Agent 的关系。

#4.1 程序表示与静态分析

#4.1.1 ：代码属性图

2014 年 IEEE Symposium on Security and Privacy 的经典论文 Modeling and Discovering Vulnerabilities with Code Property Graphs 提出了 Code Property Graph（）。其中， 表示控制流图， 表示程序依赖图。其基本思想是将：

融合为统一属性图，并使用图遍历表达漏洞模式。

CPG 的意义在于，它把原本分散的程序事实统一起来：

Function A
  ├── AST → Syntax Node
  ├── CFG → Branch / Loop
  ├── Call → Function B
  ├── Data Flow → Variable C
  └── Dependency → Sink D

对大模型而言，CPG 能够提供比原始代码更紧凑、更结构化的上下文。当前“Graph + LLM”“CPG + MCP”“程序切片 + LLM”研究均可追溯到这一基础。

经典论文：Yamaguchi et al., IEEE S&P 2014IEEE S&P 2014

#4.1.2 Joern

Joern 是最具代表性的开源 CPG 平台之一，被广泛用于漏洞研究、代码查询和数据流分析。

#核心能力

Joern 很适合作为 Agent 的“程序事实服务”：

Agent Question:
“用户输入能否到达 exec?”

      ↓

Joern Query / Data Flow

      ↓

Structured Path:
source → f1 → f2 → sink

而不是让模型靠阅读数十个文件猜测调用关系。

#优势

#局限

资料：Joern Documentation；CPG Documentation

#4.1.3 CodeQL

CodeQL 将代码构建为数据库，并通过 QL 查询语言进行语义分析，是现代静态安全分析的重要代表。

#主要能力

典型安全分析：

Source
  ↓
Propagation
  ↓
Sanitizer?
  ↓
Sink

#对 LLM 研究的价值

CodeQL 可以承担三种角色：

  1. 候选生成器：产生高召回的安全告警；
  2. 路径事实提供者：给出 source-to-sink 传播路径；
  3. 规则执行后端：由 LLM 生成或补充项目特定 source/sink 规则。

2023 年 GitHub CodeQL 团队就公开介绍过使用 LLM 辅助 API 建模，以扩展 sink 等语义模型。这是“LLM 不替代静态分析，而是补充其语义规格”的重要实践。

#局限

资料：CodeQL Data Flow Documentation；GitHub Security Lab: LLM-assisted CodeQL modeling

#4.1.4 Semgrep

Semgrep 是高效、易扩展的代码模式与静态分析工具。

#适用能力

Semgrep 的优势是规则开发快、语言覆盖广、适合批量扫描和 CI/CD。

#与深层程序分析的分工

更合理的定位是：

Semgrep
  → 快速发现候选、局部模式、危险调用

CodeQL / Joern
  → 深层跨过程路径、调用关系、程序切片

不应把 Semgrep Community Edition 简单描述为完整的跨文件程序分析器；高级跨函数、跨文件能力与具体产品/引擎配置有关。

资料：Semgrep Taint Analysis

#4.1.5 Bandit工具 与 gosec工具

Bandit 和 gosec 适合作为语言专项基线。

#Bandit

面向 Python，基于 AST 检查常见安全问题，如：

资料：PyCQA Bandit★ 8.2k

#gosec

面向 Go 语言，提供大量安全规则并支持常见输出格式。

资料：securego/gosec★ 8.9k

#研究定位

两者适合作为：

但其主要能力仍是规则驱动，不适合作为复杂跨项目业务逻辑漏洞的唯一发现手段。

#4.1.6 DongTai IAST工具

DongTai 是开源 IAST（Interactive Application Security Testing）项目。IAST 通过在程序运行过程中收集：

来判断漏洞。

IAST 位于 SAST 与纯 之间：

Static Knowledge
      +
Runtime Instrumentation
      =
IAST

对自动验证研究而言，IAST 的价值是能够提供“真实执行路径”而非纯静态近似。

资料：DongTai GitHub★ 1.3k

#4.2 模糊测试（Fuzzing）

Fuzzing 是未知漏洞挖掘的核心技术之一。与 LLM 结合后，研究焦点逐渐从“让 LLM 代替 Fuzzer”转向“让 LLM 改善 Harness、字典、输入结构、目标选择和覆盖率反馈”。

#4.2.1 AFL++

AFL++ 是现代覆盖率引导模糊测试的重要开源平台。

#主要能力

#适用对象

#与 LLM Agent 的结合方向

High-risk Function Discovery
          ↓
LLM Generates Fuzz Harness
          ↓
Compile
   ↓ fail        ↓ success
Repair Agent      Fuzz
                    ↓
               Coverage / Crash
                    ↓
             Harness Refinement

真正有研究价值的是闭环，而不是“把 AFL++ 接进系统”。

资料：AFL++ Documentation

#4.2.2 libFuzzer

libFuzzer 是 LLVM 生态中的进程内、覆盖率引导、进化式 Fuzzer。

典型接口：

int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
    // target API
    return 0;
}

它适合：

libFuzzer 与 和 ASan 等工具结合紧密，非常适合作为“LLM 自动生成 Harness”的实验后端。

资料：LLVM libFuzzer Documentation

#4.2.3 syzkaller

syzkaller 是无监督、覆盖率引导的内核 Fuzzer，最初面向 Linux，目前公开支持或扩展到多个内核和系统目标，是内核漏洞挖掘方向最具代表性的工具之一。

#核心特点

#为什么与 LLM 研究有关

内核 Fuzzing 的瓶颈之一是 syscall specification。KernelGPT 等研究已经探索使用 LLM 自动生成 syzkaller 系统调用规格。这说明 LLM 最适合填补“人工语义建模成本”，而不是替代覆盖率引导执行。

资料：syzkaller GitHub★ 6.3k

#4.2.4 boofuzz

boofuzz 是 Sulley 的继任者之一，适合网络协议和状态化交互 Fuzzing。

#主要特点

#适用场景

#与 LLM 结合的潜力

LLM 可辅助：

资料：boofuzz Documentation

#4.2.5 WinAFL

WinAFL 是针对 Windows 程序的 AFL 风格 Fuzzer。

#适用对象

#研究价值

课程主线以开源项目为主，因此 WinAFL 并非核心工具，但它补足了 Windows 二进制安全方向。

#注意事项

WinAFL 的工程配置通常比 libFuzzer 复杂，对插桩、目标函数和运行环境要求较高，应将其视为专项工具而非通用默认方案。

资料：googleprojectzero/winafl★ 2.6k

#4.2.6 Fuzz Introspector工具

Fuzz Introspector 的核心价值是比较：

静态上可达的代码
       vs
当前 Fuzz Harness 实际覆盖的代码

因此可以回答：

这非常适合形成 Agent 闭环：

Fuzz
 ↓
Coverage Analysis
 ↓
Uncovered High-risk Targets
 ↓
LLM Improves Harness
 ↓
Fuzz Again

资料：Fuzz Introspector

#4.2.7 LibAFL工具

LibAFL 是 Rust 编写的模块化 Fuzzing 框架，支持自定义：

它更适合 Fuzzing 研究者开发新算法。对短周期工程任务而言，AFL++ 和 libFuzzer 更易落地；对长期科研，LibAFL 提供更大的算法实验空间。

资料：AFLplusplus/LibAFL★ 2.6k

#4.3 符号执行与约束求解

#4.3.1 KLEE

KLEE 是 2008 年 OSDI 的经典符号执行系统。

普通执行只测试具体值：

x = 3

符号执行把输入视为：

x = Symbolic

并为不同分支维护路径约束，例如：

Path 1: x > 100
Path 2: x <= 100

求解器可自动构造满足路径的输入。

#研究意义

KLEE 证明了自动路径探索和输入生成的可行性，也是后续 、 和混合 Fuzzing 的基础之一。

#局限

#与 LLM 的新关系

LLM 可以：

而求解器负责确定性求值。

资料：KLEE Project；KLEEOSDI 2008

#4.3.2 angr

angr 是面向二进制分析的开源框架，支持：

典型任务：

Target Address
      ↓
Symbolic State Exploration
      ↓
Path Constraints
      ↓
Concrete Input

适合：

资料：angr

#4.3.3 Triton

Triton 是动态二进制分析框架，支持：

与 angr 相比，Triton 更接近可嵌入的动态符号执行基础设施。

资料：JonathanSalwan/Triton★ 4.2k

#4.3.4 SymCC工具

SymCC 采用编译器插桩方式执行 Concolic/，以减少纯解释式符号执行开销。

它代表另一条路线：

Compile-time Instrumentation
        ↓
Native Execution Speed
        +
Symbolic Constraints

适合调研混合 Fuzzing 和符号执行性能问题。

资料：eurecom-s3/symcc★ 868

#5. 二进制、逆向工程与固件专项工具

本章覆盖二进制、逆向工程与固件方向的代表性工具。虽然课程题目以开源项目源码审计为核心，但真实项目可能包含原生库、闭源插件、预编译组件或固件依赖，因此这些工具具有补充价值。

#5.1 Ghidra

Ghidra 是由美国 NSA 开源的逆向工程平台，支持：

当前 AI 生态进一步通过 GhidraGPT、GhidraMCP 等方式把反编译器能力暴露给 LLM Agent。

资料：NationalSecurityAgency/ghidra★ 70.5k

#5.2 Radare2工具 与 Cutter工具

Radare2 是高度可脚本化的逆向分析工具集，Cutter 是其图形化前端生态的重要组成部分。

适合：

其优势是开放和灵活，但自动程序语义恢复能力与 Ghidra、angr 等工具的侧重点不同。

#5.3 Qiling Framework

Qiling 是多架构、多操作系统的二进制模拟框架，可在没有真实设备的情况下执行：

适合：

资料：QilingFramework/qiling★ 6k

#5.4 Binwalk工具

Binwalk 是固件分析常用工具，可用于：

它不直接完成漏洞发现，但可以作为固件项目的预处理入口。

#6. 漏洞验证、PoC 与利用工具

验证链路

原文强调 Nuclei、ZAP、sqlmap、Commix、Metasploit、pwntools 等工具任务不同，不能混为一谈。

  1. 候选发现
  2. 路径事实
  3. 语义分析
  4. 独立验证
  5. 专项动态工具
  6. 确定性 Oracle
  7. 证据与回放

漏洞验证工具需要根据功能区分为三类：

  1. 已知漏洞模板验证器：如 Nuclei；
  2. 漏洞类型专项验证器：如 sqlmap、Commix；
  3. 利用开发与自动利用基础设施：如 Metasploit、pwntools、rex。

这三类工具不能混为一谈。

#6.1 Nuclei

Nuclei 是模板驱动的安全验证工具，其核心结构是：

Request
  +
Matcher
  +
Extractor

模板可以描述：

#研究价值

相比让 LLM 直接生成任意 Python PoC，让模型先生成结构化验证规格再转换为 Nuclei Template 更容易：

#局限

Nuclei 更擅长：

而不擅长自动理解任意源码中的新型复杂业务逻辑漏洞。

资料：projectdiscovery/nuclei★ 29.5k；nuclei-templates★ 12.6k

#6.2 OWASP ZAP

OWASP ZAP 是漏洞研究工具链中不可缺少的开源 DAST 工具。

其功能包括：

#与 Nuclei 的差异

Nuclei
→ 高度模板化、快速验证、社区模板生态

ZAP
→ 完整 Web DAST、代理、爬虫、主动/被动扫描

ZAP 更适合对运行中的 Web 项目做广泛动态测试；Nuclei 更适合作为结构化、可复现的专项验证器。

资料：OWASP ZAP；OWASP WSTG Tool Resource

#6.3 sqlmap

sqlmap 是 SQL 注入自动检测与利用的经典工具。

支持：

#与代码审计结合的高价值模式

Static Analysis
发现 request.id → SQL execution
          ↓
Agent 提取 endpoint / parameter / auth
          ↓
sqlmap 针对性验证

这比对全部 URL 无差别扫描更具有研究意义。

资料：sqlmapproject/sqlmap★ 37.8k

#6.4 Commix

Commix 是命令注入自动检测与利用工具。

适合验证：

其研究价值同样体现在“候选引导验证”：静态或 LLM 分析先定位具体 endpoint、parameter 和 sink，再调用 Commix 验证。

资料：commixproject/commix★ 5.8k

#6.5 Metasploit Framework工具

Metasploit 是成熟的漏洞利用与渗透测试框架，在本文语境中应予以准确定位，其提供：

#对本课题的价值

#不适合的误解

Metasploit 不是“自动发现任意新漏洞”的工具。它主要依赖已有模块和研究成果。

资料：rapid7/metasploit-framework★ 38.5k

#6.6 pwntools

pwntools 是二进制利用开发的 Python 库，适合：

在自动化系统中，pwntools 可以作为二进制 PoC 的统一执行框架，但它本身不会自动发现漏洞。

资料：Gallopsled/pwntools★ 13.6k

#6.7 rex：自动利用生成的经典开源系统

rex 是 angr 生态中的自动利用引擎，源于 Cyber Grand Challenge 相关研究。

其公开能力包括：

Crash
  ↓
Crash Triage
  ↓
Crash Exploration
  ↓
Exploitability Analysis
  ↓
Exploit Generation（部分类型）

rex 代表 LLM 时代之前的 （AEG）路线。

资料：angr/rex★ 653

#6.8 Mechanical Phish 与 DARPA Cyber Grand Challenge

Mechanical Phish 是 Shellphish 团队在 DARPA Cyber Grand Challenge 中构建的 Cyber Reasoning System。

其历史意义在于，它在没有 LLM 的时代就尝试自动完成：

Analyze
  ↓
Find Vulnerability
  ↓
Generate Exploit
  ↓
Patch

其技术栈与 angr、rex、Driller、Fuzzing 等研究关系密切。

#对今天 Agent 研究的启示

LLM 并不是自动漏洞研究的起点。更准确的技术演进是：

Symbolic Execution
      ↓
Fuzzing + AEG
      ↓
Cyber Reasoning Systems
      ↓
LLM + Program Analysis
      ↓
Agentic Vulnerability Research Harness

资料：Mechanical Phish GitHub Organization；Mechanical Phish: Resilient Autonomous HackingIEEE Security & Privacy · 2018

#6.9 Trivy工具：供应链与 方向

Trivy 对课程主线属于“相关但不是核心漏洞语义分析”的工具，其可用于扫描：

#研究价值

开源项目审计不应只关注自研代码，还需要知道：

Trivy 可提供“已知供应链风险候选”，而后续研究可以进一步做可达性判断。

资料：aquasecurity/trivy★ 36.8k

#7. 运行时验证、崩溃分析、沙箱与证据工具

#7.1 AddressSanitizer工具（ASan）

ASan 是内存安全验证的重要确定性 Oracle，可检测：

其价值在于把：

“程序崩溃了”

升级为：

错误类型 + 地址 + Stack Trace + 触发输入

资料：Clang AddressSanitizer

#7.2 UndefinedBehaviorSanitizer工具（UBSan）

UBSan 用于检测多类未定义行为，如：

它可与 Fuzzing 结合，提供比普通 Crash 更丰富的运行时证据。

资料：Clang UndefinedBehaviorSanitizer

#7.3 CASR

CASR 是 Crash Analysis 与去重工具，可处理：

Fuzzing 经常产生大量重复崩溃：

1000 crash files
      ↓
CASR
      ↓
Root-cause Deduplication
      ↓
Unique Findings

因此，CASR 对自动化漏洞研究中的“Crash → Finding”转换很有价值。

资料：ispras/casr★ 355

#7.4 rr

rr 是 Linux 下的 Record and Replay Debugger。

基本模式：

Record Execution
       ↓
Replay
       ↓
Reverse Debugging

它特别适合保存复杂、非确定性漏洞的执行轨迹。

在证据链中，可形成：

finding-001/
├── poc
├── input
├── rr-trace
├── logs
└── verdict

资料：rr-debugger/rr★ 10.6k

#7.5 Tracee

Tracee 是基于 eBPF 的 Linux Runtime Security/Observability 工具。

可观测：

它非常适合为 PoC 提供行为证据，例如：

Static Claim:
request.cmd → os.system

Runtime Evidence:
/bin/sh created
child process executed
canary file written

资料：aquasecurity/tracee★ 4.5k

#7.6 nsjail

nsjail 是轻量级 Linux 隔离工具，使用：

适合限制：

对自动生成 PoC 的系统而言，隔离执行是基本安全要求。

资料：google/nsjail★ 4k

#7.7 gVisor

gVisor 是开源 Linux 兼容沙箱，通过用户态应用内核等机制提供额外隔离层，并提供 OCI Runtime runsc。

#与普通容器的差异

普通容器共享宿主内核；gVisor 在应用与宿主内核之间增加系统调用处理层，从而减少直接暴露。

#优势

#局限

资料：gVisor Documentation

#8. 经典研究成果与代表性论文综述

本章按时间与技术问题组织代表性研究。与简单论文列表不同，重点分析每项工作的研究问题、方法、证据、影响和局限。

#8.1 KLEE：自动路径探索与测试生成的经典基础（OSDI 2008）

论文： KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs

#研究问题

如何在缺少人工测试输入的情况下，通过符号执行自动探索复杂系统程序路径并生成高覆盖测试？

#核心方法

#历史意义

KLEE 建立了自动化漏洞验证中的一个核心范式：

今天的 LLM Agent 可以帮助选择目标、理解语义和构造驱动，但最终满足路径条件仍可以交给确定性求解器。

#局限

资料：KLEEOSDI 2008

#8.2 Code Property Graph：统一程序表示（IEEE S&P 2014）

论文： Modeling and Discovering Vulnerabilities with Code Property Graphs

#研究问题

单独的 AST、CFG 或数据依赖图只能表示程序的一部分结构，如何统一表达漏洞模式所需的语法、控制流和依赖关系？

#核心方法

将：

AST + CFG + PDG

融合为：

Code Property Graph

然后使用图遍历表达漏洞模式。

#影响

CPG 成为 Joern 等工具的理论基础，也为 2025-2026 年“CPG + LLM”研究提供结构化上下文。

#当代意义

LLM 面临上下文窗口和跨过程推理问题时，程序图提供了一种比全文 RAG 更适合安全分析的结构化检索方式。

资料：IEEE S&P PaperIEEE S&P 2014

#8.3 GPTScan论文：LLM 与程序分析混合路线（ICSE 2024）

#研究问题

仅依赖静态规则容易缺失项目语义，仅依赖 GPT 又容易产生幻觉，能否把二者结合？

#核心思想

GPTScan 代表了早期成熟的混合范式：

LLM
→ 理解安全语义 / 识别候选

Program Analysis
→ 验证程序事实

#研究意义

GPTScan 的重要性不在于某个具体模型，而在于明确了：

这条路线后来在 IRIS、QLPro、VulWeaver 等工作中继续发展。

资料：GPTScanICSE 2024；GPTScan GitHub★ 105

#8.4 IRIS：LLM 增强全项目污点分析（ICLR 2025）

#研究问题

传统 SAST 的关键困难之一不是数据流算法本身，而是：

#方法

IRIS 使用 LLM 推断项目特定安全规格，再结合静态分析完成全项目污点分析。

概念流程：

Repository
   ↓
LLM infers project-specific source/sink semantics
   ↓
Static Taint Analysis
   ↓
Vulnerability Paths

#公开结果

在论文使用的 CWE-Bench-Java 120 个真实、人工验证漏洞上，论文报告：

这些数字属于论文实验结果，应在复现时关注模型版本、数据集定义和实现配置。

#研究意义

IRIS 很清楚地说明：

#局限

资料：IRISICLR 2025；IRIS GitHub★ 404

#8.5 JITVul论文：真实漏洞提交历史与 Agent 上下文（ACL 2025）

#研究问题

函数级漏洞数据集通常缺少真实软件演进上下文，能否使用漏洞引入提交和修复提交评估 LLM/Agent？

#数据与任务

JITVul 包含大量真实 CVE 的提交级数据。公开论文描述了 1,758 对提交，覆盖 91 类漏洞类型。

#关键结论

能够主动获取跨过程上下文的 ReAct 类 Agent，通常优于只看局部片段的普通 LLM，但仍存在明显不稳定性。

#研究意义

JITVul 强化了一个越来越明确的结论：

资料：JITVulACL 2025

#8.6 RepoAudit：仓库级自主探索（2025）

RepoAudit 将漏洞检测视作一个 Agent 在仓库中的探索过程。

#方法特点

#研究意义

它推动研究从：

“给模型一段代码”

转向：

“让模型决定下一步应该查什么，并用工具核验”

这也是 Agent 与普通 LLM 漏洞分类器的本质区别之一。

资料：RepoAudit PaperarXiv · Preprint · 2025

#8.7 QLPro：自动生成项目特定静态分析规格（2025）

#研究问题

CodeQL 等工具强大，但项目特定 taint specification 和查询规则需要大量专家工作，能否由 LLM 自动生成？

#方法

QLPro 面向完整开源项目：

#研究意义

QLPro 表明 LLM 与 SAST 的结合不一定是：

SAST Alert → LLM Filter

也可以是：

LLM → Generate Static Analysis Specification → SAST Executes

#局限

资料：QLPro PaperarXiv · Preprint · 2025

#8.8 LLMxCPG论文：CPG 引导的大模型上下文（2025）

LLMxCPG 将 Code Property Graph 与 LLM 结合，用 CPG 切片减少代码规模并保留漏洞相关上下文。

论文报告其切片可大幅减少待分析代码，并在多个设置中改善漏洞检测表现。

#研究意义

其核心价值不是具体 F1，而是提供了清晰的方向：

也就是说，不应仅按文本相似度找代码，而应按：

选择上下文。

资料：LLMxCPGarXiv · Preprint · 2025

#8.9 OpenAnt：可达性裁剪与对抗验证（2026）

#核心问题

真实仓库太大，候选误报太多，如何让 Agent 聚焦攻击相关代码并主动证伪？

#方法

  1. 识别攻击入口；
  2. 计算可达代码单元；
  3. Defender 形成漏洞假设；
  4. Attacker 主动挑战；
  5. 动态环境验证。

#研究意义

OpenAnt 把验证定义为“对发现结论发起攻击”，而不是“让第二个 Agent 重复审查”。

资料：OpenAnt PaperarXiv · Preprint · 2026

#8.10 ESAA-Security：事件溯源式可审计 Agent（2026）

#研究问题

自由形式 Agent 过程难以审计、重放和比较，如何把安全 Agent 变成确定性程度更高的流水线？

#方法

论文使用多个任务和安全领域讨论其架构。

#研究意义

ESAA 将重点从“推理多聪明”转为：

这对于课程要求的“可审计、可验证、可复现”尤其重要。

资料：ESAA-SecurityarXiv · Preprint · 2026

#8.11 LLM-based Vulnerability Detection at Project Scale论文（2026）

#研究设计

该工作是 2026 年重要的项目级实证研究之一，比较：

#主要发现

论文报告：

  1. LLM 检测器总体召回并不理想；
  2. 但能够发现一些传统工具未发现的独特漏洞；
  3. 两类方法在真实项目中都可能产生大量误报；
  4. 主要根因包括跨过程推理浅、source/sink 识别错误；
  5. LLM 方法可能消耗几十万到上亿 Token，并需要多小时到多天。

#研究意义

这是对“LLM 一定比传统 SAST 强”这一简单叙事的重要纠偏。

真正合理的结论是：

LLM ≠ SAST Replacement
LLM + Program Analysis + Verification
更值得研究

资料：LLM-based Vulnerability Detection at Project ScalearXiv · Preprint · 2026

#8.12 Sifting the Noise论文：LLM Agent 过滤 SAST 误报（2026）

#研究问题

SAST 误报率高，Agent 能否通过跨文件推理、工具使用和迭代分析过滤误报？

#评测

研究比较 Aider、OpenHands、SWE-agent 等框架，在 OWASP Benchmark 和真实 Java 项目上进行评测。

#论文报告结果

在最佳配置下：

但论文同时强调：

#研究意义

它表明“验证 Agent”确实有价值，但验证器本身也需要评测，不能默认可信。

资料：Sifting the NoisearXiv · Preprint · 2026

#8.13 VulWeaver：确定性图与 LLM 语义联合（2026）

VulWeaver 关注传统静态分析图不完整、LLM 上下文不充分的问题。

#方法

  1. 构建增强统一依赖图（UDG）；
  2. 使用确定性规则与 LLM 语义推断补全关系；
  3. 从图中提取显式上下文；
  4. 补充定义、声明、用途等隐式上下文；
  5. 使用漏洞类型专家指南进行推理；
  6. 多数投票增强稳定性。

#论文报告

论文报告在 PrimeVul4J 上达到较强 F1，并在真实 Java 项目和工业代码中发现多项开发者确认的问题。这些数字属于作者实验结果，应结合代码和数据进一步复现。

#研究意义

VulWeaver 代表：

资料：VulWeaverarXiv · Preprint · 2026

#8.14 codebadger论文：通过 MCP 把 Joern 暴露给 LLM（2026）

codebadger 直接回应了大模型项目级分析的三个难点：

其做法是提供高层 MCP 工具：

#研究意义

这代表一种很实际的工具接口思想：

资料：codebadger PaperarXiv · Preprint · 2026

#8.15 Revelio：成本优化的 Agentic 内存安全漏洞检测（2026）

#研究问题

内存安全漏洞即便在经过大规模 fuzz 和人工审计的成熟项目中仍持续存在。直接使用大模型进行仓库级漏洞检测面临三方面挑战：

#方法

Revelio 提出一种代价可控的 Agentic 检测框架，核心设计包括：

  1. 幻觉抑制：Agent 不直接输出漏洞判断，而是生成可执行的 Proof-of-Vulnerability 载荷，通过 ASan 等确定性 Sanitizer 复现确认；
  2. 成本优化：使用廉价 LLM 配合轻量静态分析形成漏洞候选并优先级排序，仅将高价值候选交给昂贵模型；
  3. 验证管道：漏洞只有在 Sanitizer 复现后才进入报告，未复现结果不上榜。

#论文报告的实证

#研究意义

Revelio 是 2026 年最直接印证本报告核心结论的实证工作之一：

资料：Revelio PaperarXiv · Preprint · 2026

#8.16 Make Agent Defeat Agent：对抗式检测的学术支撑（USENIX Security 2025）

#研究背景与目标域说明

Make Agent Defeat Agent: Automatic Detection of Taint-Style Vulnerabilities in LLM-based Agents（Fengyu Liu、Yuan Zhang、Hao Chen 等，复旦大学 + UC Davis）发表于 USENIX Security 2025。

目标域说明：论文的直接检测对象是 LLM Agent 本身（污点从恶意 prompt 流向敏感操作），而非通用开源应用代码。因此它更贴近选题二的问题域。将其纳入本调研的原因在于其方法论对选题一的验证智能体设计具有直接可迁移性。

#方法与迁移价值

论文的核心方法是"让一个 Agent 主动挑战另一个 Agent 的假设"：

Finder Agent 提出污点候选
        ↓
Attacker Agent 主动构造反例
        ↓
沙箱验证
        ↓
经受住反例的发现才进入报告

这与本调研第 3.7 节 OpenAnt 的 Defender/Attacker 对抗验证、第 13.4 节的对抗式独立验证方向属于同一研究谱系。由于本文是 USENIX Security 顶会论文，为该方法论提供了明确的学术背书，可作为选题一验证智能体设计的可引用依据。

#研究意义

即便目标域不同，其研究结论仍支持本报告的两个判断：

  1. 多 Agent 系统的价值不在数量，而在角色对抗性（第 14.1 节）；
  2. 同模型、同上下文的多 Agent 复核容易产生相关性幻觉（第 12.3 节），必须让某个 Agent 主动扮演反方。

资料：Make Agent Defeat Agent — USENIXUSENIX Security 2025

#8.17 KernelGPT：LLM 辅助内核 Fuzzing 规格生成

Kernel Fuzzing 的一个核心人工成本是为 syzkaller 编写系统调用描述。

KernelGPT 探索使用 LLM 从内核源代码和文档中生成 syscall specification，再交给 syzkaller 执行。

#研究意义

这是“LLM + Fuzzer”的典型正确分工：

LLM
→ 生成难以人工规模化维护的语义规格

syzkaller
→ 大规模覆盖率引导执行与 Crash 发现

不是让 LLM 模拟 Fuzzer。

#8.18 论文路线总结

四条方法演进路线
路线 A

程序分析增强语义

CodeQL / Joern + LLM Source/Sink Semantics

GPTScan、IRIS、QLPro

路线 B

程序结构约束上下文

CPG / Dependency Graph / Reachability → Targeted Context → LLM

LLMxCPG、VulWeaver、codebadger、OpenAnt

路线 C

发现与验证分离

Finder → Independent Verifier → Runtime Evidence

OpenAnt、VVAH、Cloudflare Harness、Sifting the Noise

路线 D

完整漏洞生命周期

Discover → PoC → Impact → Patch → Regression Validation

AIxCC、CyberGym-E2E、Codex Security、Claude Security

从上述研究可以看到四条清晰演进线：

#路线 A：程序分析增强语义

CodeQL / Joern
      +
LLM Source/Sink Semantics

代表：GPTScan、IRIS、QLPro。

#路线 B：程序结构约束上下文

CPG / Dependency Graph / Reachability
      ↓
Targeted Context
      ↓
LLM

代表：LLMxCPG、VulWeaver、codebadger、OpenAnt。

#路线 C：发现与验证分离

Finder
  ↓
Independent Verifier
  ↓
Runtime Evidence

代表：OpenAnt、VVAH、Cloudflare Harness、Sifting the Noise。

#路线 D：完整漏洞生命周期

Discover
  ↓
PoC
  ↓
Impact
  ↓
Patch
  ↓
Regression Validation

代表：AIxCC、CyberGym-E2E、Codex Security、Claude Security 等。

#9. 工业界与大型研究实践

本章中的系统不一定开源，但其工程实践和公开研究对理解前沿趋势十分重要。所有扫描规模和漏洞数量均为机构官方报告，不视为独立第三方实验结论。

#9.1 Google Project Zero：Naptime 与 Big Sleep

#Project Naptime

Google Project Zero 在 2024 年公开 Naptime，目标是让 LLM 模拟人工漏洞研究员的迭代过程：

Hypothesis
   ↓
Inspect Code
   ↓
Run Tool
   ↓
Observe Evidence
   ↓
Refine Hypothesis

其核心思想是为模型提供：

#Big Sleep

后续 Big Sleep 报告发现了 SQLite 中一个可利用的 stack buffer underflow，并在正式版本发布前得到修复。

#研究意义

这一系列工作证明：

资料：Project Naptime；From Naptime to Big Sleep

#9.2 DARPA AI Cyber Challenge实践（AIxCC）

AIxCC 是自动化网络防御领域的重要大型竞赛，目标是利用 AI 自动发现并修复开源软件漏洞。

其关键任务不是单纯扫描：

Find
 ↓
Prove / Score
 ↓
Patch

涉及真实关键开源软件和大规模自动化 Cyber Reasoning Systems。DARPA 在 2025 年决赛后公开表示，参赛系统能够发现和修补真实世界漏洞，且最终系统被开放源代码。

#历史意义

AIxCC 可以视作 CGC 的现代延续：

2016 CGC
Fuzzing + Symbolic Execution + AEG

2025 AIxCC
LLM + Program Analysis + Fuzzing + Patching

资料：DARPA AIxCC；2025 Results

#9.3 Cloudflare Vulnerability Discovery Harness实践 与 Validation System

2026 年 6 月，Cloudflare 公开其漏洞研究 Harness 工程经验。

#两阶段结构

Vulnerability Discovery Harness (VDH)
                +
Vulnerability Validation System (VVS)

Discovery 阶段包含多个角色，例如：

Validation 阶段则独立检查 Finding，并主动尝试推翻结论。

#关键工程经验

  1. Discovery 与 Validation 分离；
  2. 可以使用不同模型降低相关性幻觉；
  3. 长任务需要持久化状态；
  4. 角色之间不共享无限上下文；
  5. 报告生成不一定需要模型；
  6. 失败应反馈到后续任务和 Prompt。

#研究意义

Cloudflare 的实践说明 Harness 的工程质量可能比单次模型能力更决定真实效果。

资料：Build your own vulnerability harness

#9.4 OpenAI Codex Security实践

2026 年 3 月，OpenAI 公开 Codex Security research preview。

其公开流程包括：

  1. 构建项目上下文；
  2. 生成可编辑的项目特定威胁模型；
  3. 按真实风险搜索漏洞；
  4. 在适当情况下进行沙箱验证；
  5. 生成 PoC；
  6. 提议修复。

OpenAI 后续公开文章进一步强调，复杂漏洞不一定是纯 source-to-sink 数据流问题，很多漏洞源于“安全约束看似存在但实际上不成立”。这反映了 LLM 语义推理相对传统 SAST 的潜在优势。

#官方自报数据

OpenAI 公开了扫描规模、噪声下降和高危发现等数据。这些数字可以反映产品实践规模，但属于厂商自报，不应直接替代独立 benchmark。

资料：Codex Security；Why Codex Security Doesn't Include a SAST Report

#9.5 Anthropic Claude Security实践 / Project Glasswing实践

Anthropic 在 2026 年公开 Claude Code Security、Claude Security 和 Project Glasswing 相关研究。

其公开能力包括：

Anthropic 还公开了 Claude 发现 0-day、Firefox 合作和协调披露等案例。

#研究意义

这些工作说明前沿模型在：

方面能力明显提升。

但与 Codex Security 相同，公开漏洞数量和修复数字属于官方报告，学术研究仍需要独立、可重复 benchmark。

资料：Claude Code Security；LLM-discovered 0-days；Project Glasswing

#9.6 Anthropic Defending Code Reference Harness：可复现的工程教训

Anthropic 除 Claude Security 产品外，还以 MIT 许可开源了 Defending Code Reference Harness 参考实现，并公开了对应的工程博客。相比第 3.9 节侧重系统架构的介绍，本节侧重其可迁移的工程教训——这些结论多数由多家合作团队的实践积累得出，与本报告的判断存在明确对应关系。

#9.6.1 六阶段方法论对应课程要求

阶段关键操作对应课程要求
Threat Model从代码/文档/CVE 历史蒸馏"bug-shape hints"，写入 THREAT_MODEL.md报告部分的"漏洞列表 + 严重等级"
SandboxgVisor + 网络白名单 + 依赖 pin沙箱化验证
Discovery按攻击面分区并行 Agent，结构化输出扫描智能体
Verification独立 Verifier + 对抗 Prompt + 强制 PoC验证智能体 + 误报过滤
Triage按根因去重，按前提条件排序严重度修复建议前置
Patching编译 → PoC 失效 → 回归 → 再攻不破四级校验漏洞自动利用与证据链

#9.6.2 若干工程结论

Anthropic 蒸馏出的工程教训中，以下几条与本报告的观察高度一致：

#9.6.3 官方公开数据（自报）

这些数字属于官方自报，仍需通过独立 benchmark 复核，但作为工程实践的规模参照有其价值。

资料：Defending Code Reference Harness GitHub★ 6.4k；官方博客

#9.7 Visa VVAH 的企业开源意义

VVAH 与纯产品不同，它公开了参考实现，因此特别值得关注。

它说明企业级 Agent 安全研究开始关注：

其公开局限也说明，企业本身并不认为 LLM 候选可以不经验证直接成为最终漏洞。

#9.8 GitHub Security Lab：声明式安全 Agent 工作流

GitHub Security Lab Taskflow 的重要性在于：

这种方法有利于：

#10. 漏洞研究评测基准与数据集

Benchmark 任务地图
检测与定位CWE-Bench-Java、JITVul

Recall、Precision、定位准确率、演进上下文

复现与差分Vul4J、Magma

Proof-of-Vulnerability、Ground Truth Bug、修复前后对比

PoC 与利用CyberGym、CVE-Bench、ExploitGym、ExploitBench

PoC 生成、Web 利用、能力分级

端到端与高难度CyberGym-E2E、SEC-bench Pro

发现→PoC→Patch，复杂真实目标

基础能力NIST SARD / Juliet

CWE 基础测试，但不能代表真实大型仓库

高质量调研不能只比较“发现多少个漏洞”。不同系统的任务定义差异极大：有的做函数分类，有的做仓库级发现，有的只生成 PoC，有的要求实际利用，有的进一步要求修复。因此，必须先明确 benchmark 在测什么。

#10.1 CWE-Bench-Java

#基本情况

CWE-Bench-Java 包含 120 个真实 CVE，主要覆盖 4 类 CWE，包括：

数据提供：

#适合任务

#局限

资料：CWE-Bench-Java GitHub★ 106

#10.2 Vul4J

Vul4J 是 Java 真实漏洞可复现数据集。

公开数据包含：

其重要价值是提供：

Vulnerable Version
       +
Fixed Version
       +
Proof-of-Vulnerability Test

#适合任务

#注意事项

公开仓库也提醒，随着依赖和构建环境变化，部分历史漏洞可能逐渐难以复现。因此，benchmark 本身也需要环境版本管理。

资料：Vul4J GitHub★ 133

#10.3 JITVul

JITVul 的核心是提交历史和真实软件演进。

#适合任务

它比纯函数分类数据更贴近真实开发过程，但不直接提供完整漏洞利用环境。

#10.4 CyberGym

CyberGym 是自动 PoC 生成研究的重要 benchmark。

#公开规模

#基本任务

Vulnerability Description / Repository
          ↓
Agent Generates PoC
          ↓
Execute in Environment
          ↓
Judge Success

#研究意义

CyberGym 表明：

论文还报告在评测过程中发现了新的真实问题。

资料：CyberGymarXiv · Preprint · 2025；CyberGym GitHub★ 503

#10.5 CyberGym-E2E

CyberGym-E2E 将任务扩展为完整生命周期：

Discovery
  ↓
PoC
  ↓
Patch

公开论文覆盖：

#研究意义

它纠正了“只会验证已知漏洞就是自动漏洞研究”的误解。端到端系统需要：

  1. 自己发现；
  2. 自己证明；
  3. 自己修复；
  4. 避免回归。

资料：CyberGym-E2EarXiv · Preprint · 2026

#10.6 CVE-Bench

CVE-Bench 聚焦真实 Web 漏洞 Agent 评测。

#公开特点

#适合任务

资料：CVE-BencharXiv · Preprint · 2025；uiuc-kang-lab/cve-bench★ 248

#10.7 ExploitGym

ExploitGym 关注一个经常被忽略的问题：

Proof of Vulnerability
        ≠
Exploit

#研究任务

评估 Agent 能否从漏洞线索进一步实现真实安全影响。

#核心观念

漏洞利用应分层：

Crash
  ↓
Controllable Crash
  ↓
Exploit Primitive
  ↓
Security Impact
  ↓
Full Exploit

论文最新版本公开的任务规模达到数百个实例（论文摘要报告 898 个）。

#研究意义

它推动评价指标从“有没有崩”转向“攻击者获得了什么能力”。

资料：ExploitGymarXiv · Preprint · 2026

#10.8 ExploitBench基准

ExploitBench 提出能力分级的 Exploitation 评测思想，通过多个具有不同能力层级的 Flag 判断 Agent 到底获得了：

这种方法比单一二元成功/失败更适合研究自动 Exploit。

资料：ExploitBencharXiv · Preprint · 2026

#10.9 SEC-bench Pro

SEC-bench Pro 面向更高难度、真实且持续演进的漏洞研究任务。

公开资料描述其包含 V8、SpiderMonkey 等复杂目标中的 183 个验证漏洞，并强调 benchmark 的持续演化。

#研究价值

#意义

它说明当前先进 Agent 距离稳定、通用的自主漏洞研究员仍有明显距离。

资料：SEC-bench ProarXiv · Preprint · 2026

#10.10 Magma

Magma 是真实漏洞 Fuzzing Benchmark。

其关键优势是：

因此比“Crash 数量”更科学。

#适合任务

资料：Magma

#10.11 NIST SARD 与 Juliet

传统静态分析基准的代表是 NIST SARD 和 Juliet Test Suite。

#SARD

NIST 2025 年 IR 8561 描述 SARD 已包含超过 45 万个带缺陷程序，覆盖：

并覆盖 150 多类弱点。

#Juliet

Juliet 是 SARD 中最著名的测试套件之一，包含大量：

#适合任务

#局限

不能只使用 Juliet 就声称系统能发现真实开源项目漏洞，因为：

Synthetic Test Case
        ≠
Large Real Repository

资料：NIST IR 8561NIST IR 8561 · 2025；SARD

#10.12 Benchmark 对比

Benchmark 核心任务 规模/特点 是否真实项目 是否动态 Oracle 适合评价
CWE-Bench-Java 项目级检测 120 CVE / 4 CWE 是 主要否 Recall、定位、上下文
Vul4J Java 漏洞复现 79 漏洞 / 51 项目 是 有 PoV 差分验证、修复
JITVul 提交级检测 1,758 提交对 是 否 演进上下文
CyberGym PoC 生成 1,507 漏洞 / 188 项目 是 是 验证能力
CyberGym-E2E 发现→PoC→Patch 920 / 139 项目 是 是 全生命周期
CVE-Bench Web 漏洞利用 40 个关键 CVE 是 是 Web Agent
ExploitGym PoV→Exploit 数百实例 是 是 可利用性
SEC-bench Pro 高难度漏洞研究 复杂引擎、持续演化 是 是 真实 0-day 能力
Magma Fuzzing 真实注入漏洞 是 Ground Truth Fuzzer
SARD/Juliet 静态分析测试 45 万+程序 混合 通常否 CWE 基础能力

#11. 2025-2026 年最新研究动态

#11.1 动态一：从 LLM-only 转向 Neuro-Symbolic

早期路线：

Code → LLM → Vulnerable?

当前路线：

Program Analysis
      +
LLM Semantic Reasoning
      +
Dynamic Execution

代表工作：

#原因

LLM 擅长：

工具擅长：

二者互补。

#11.2 动态二：上下文选择比上下文数量更重要

项目级实证研究显示，大规模 LLM 检测会遭遇：

因此研究开始从：

Whole Repository Prompt

转向：

Attack Surface
   ↓
Reachability
   ↓
Program Slice
   ↓
Security Context Package

代表：Vulnhuntr、OpenAnt、LLMxCPG、codebadger、VulWeaver。

#11.3 动态三：文本 RAG 转向程序结构检索

普通代码 RAG 通常基于：

安全研究需要的是：

因此：

#11.4 动态四：发现与验证分离

当前越来越多系统采用：

Discovery
   ↓
Structured Finding Contract
   ↓
Independent Validation

代表：

#原因

如果同一个 Agent 同时负责发现和确认，它容易为自己的假设寻找支持证据，而忽视反例。Anthropic Harness 官方数据显示，引入独立 Verifier 可使非可利用发现减少约 50%，Verifier 同时强制构造 PoC 时误报率可接近 0；Make Agent Defeat Agent 也在 LLM Agent 污点检测场景中给出了相同结论的顶会实证。

#11.5 动态五：验证器从“同意”转向“证伪”

弱验证：

Finder: 有漏洞
Verifier: 我也认为有

强验证：

Finder 提交 Claim
        ↓
Verifier 寻找：
- 不可达路径
- 非攻击者输入
- 有效 Sanitizer
- 权限限制
- 默认配置关闭
- 环境不成立

这是 OpenAnt、Cloudflare、Anthropic Defending Code Reference Harness 和 Make Agent Defeat Agent 等公开实践与论文中共同强调的趋势。

#11.6 动态六：从二元漏洞判断转向可利用性分级

传统：

Vulnerable / Safe

更合理：

Pattern
  ↓
Reachable
  ↓
Attacker Controlled
  ↓
Triggered
  ↓
Impact Confirmed
  ↓
Exploit / Reproducible

ExploitGym、ExploitBench 等 benchmark 正在推动这种变化。

#11.7 动态七：LLM Judge 转向 Deterministic Oracle

错误的验证方式：

PoC output:
"Exploit successful"

LLM:
“成功”

更可靠的验证：

当前高质量 benchmark 基本都在强化动态 Oracle。Revelio（第 8.15 节）以 7 个持续 fuzz 5–8 年的高质量项目 + ASan 强制复现的组合，用约 $300 的总花费定位到 19 个未知内存漏洞，是这一趋势的最新实证之一。

#11.8 动态八：模型竞争转向 Harness 竞争

安全 Agent 的效果不仅取决于：

还取决于：

Cloudflare、VVAH、Taskflow Agent 和 OpenAnt 都体现这一点。

#11.9 动态九：One-shot Fuzz Harness 转向闭环生成

早期：

LLM → Harness → Run Once

新方向：

Generate
  ↓
Compile
  ↓
Repair
  ↓
Fuzz
  ↓
Coverage
  ↓
Analyze Gaps
  ↓
Refine Harness

Fuzz Introspector、AFL++、libFuzzer 为这种闭环提供确定性反馈。

#11.10 动态十：LLM 自动生成程序分析规格

当前研究正在探索：

代表：

这类工作能够降低专家规则开发成本，但生成规格本身必须编译、执行和验证。

#11.11 动态十一：从单仓库转向跨仓库与依赖可达性

真实软件通常是：

Application
   ↓
Framework
   ↓
Library
   ↓
Native Dependency

仅知道“依赖有 CVE”不够，还需要判断：

因此 SBOM/SCA 与程序可达性结合是值得关注的方向。

#11.12 动态十二：从发现漏洞转向修复与回归验证

AIxCC、CyberGym-E2E、Codex Security、Claude Security 等都把研究延伸到：

Discover
  ↓
Validate
  ↓
Patch
  ↓
Regression Test

未来“发现多少漏洞”将不再是唯一指标，修复正确性和不引入新问题同样重要。

#12. 当前领域的核心难题与研究空白

核心难题矩阵
上下文与语义大型仓库上下文爆炸、危险代码不等于漏洞、相关性幻觉

验证与 PoC验证 Agent 自身误判、PoC 生成瓶颈、自动 Exploit 定义不清晰

复现与评测结果不可复现、Benchmark 与真实研究存在差距、成本与可扩展性

#12.1 大型仓库上下文爆炸

#问题

直接把仓库文件全部输入模型会导致：

#尚未完全解决

现有方法包括：

但不同语言、框架和动态特性使“最佳上下文选择”仍是开放问题。

#12.2 危险代码不等于漏洞

例如：

os.system(cmd)

仅看到 sink 不足以证明 RCE。

必须回答：

  1. cmd 是否攻击者可控？
  2. 调用路径是否可达？
  3. 是否经过净化？
  4. 是否需要管理员权限？
  5. 默认配置是否启用？
  6. 实际能否产生安全影响？

当前很多 LLM 检测器仍会在这里产生误报。

#12.3 相关性幻觉

多个 Agent 使用相同：

可能重复相同错误。

因此“3 个 Agent 投票”不一定是真正独立验证。

#12.4 验证 Agent 自身也会误判

Sifting the Noise 证明 Agent 可以显著降低 SAST 噪声，但也指出激进过滤可能删除真实漏洞。

因此验证器需要：

不能把 Verifier 视作神谕。

#12.5 PoC 生成仍是瓶颈

CyberGym 等 benchmark 表明：

是不同难题。

因此：

Finding ≠ PoC
PoC ≠ Exploit
Exploit ≠ Reproducible Evidence

#12.6 自动 Exploit 的任务定义不清晰

Web 路径遍历与内存破坏漏洞的“利用”完全不同：

因此通用 Exploit Success 指标不合理。

#12.7 结果不可复现

Agent 运行受：

影响。

没有事件日志、Artifact Hash、容器镜像和 Replay 命令，就很难称为可复现研究。

#12.8 Benchmark 与真实研究存在差距

Synthetic benchmark 容易；真实 0-day Hunting 难。

Known CVE PoC 生成容易泄露先验；Blind Discovery 更难。

因此需要同时使用：

#12.9 成本与可扩展性

项目级研究显示 LLM 漏洞检测可能消耗非常高的 Token 和时间。

研究不能只报告 Accuracy，还应报告：

#13. 值得关注的创新方向

本章以研究问题为主，不预设具体系统实现。每个方向分别分析已有基础、尚未解决的问题、可能的创新点和可评测方式。

#13.1 攻击面感知的上下文选择

#背景

全仓库 LLM 输入成本高，随机 RAG 又可能丢失真实调用路径。Vulnhuntr、OpenAnt、LLMxCPG 和 codebadger 都表明，安全分析需要结构化上下文。

#研究问题

如何自动识别：

并构造最小但充分的安全上下文？

#可研究方法

#潜在创新

不是简单“减少 Token”，而是建立：

#可评测指标

#13.2 LLM 自动推断项目特定 Source、Sink 与 Sanitizer

#背景

IRIS、QLPro 等工作说明项目语义规格是传统静态分析的重要瓶颈。

#研究问题

如何识别框架或项目自定义函数：

get_user_payload() → Source?
execute_job()     → Sink?
escape_custom()   → Sanitizer?

#潜在创新

#关键问题

LLM 生成的 Source/Sink 不能直接作为事实，需要：

#13.3 LLM 自动生成和修复静态分析查询

#背景

CodeQL 查询编写需要较强专业知识。QLPro、QLCoder、CQLLM 类工作正在探索自动生成查询。

#研究问题

如何让 Agent 从：

生成可以执行的 CodeQL 查询？

#研究难点

#有价值的闭环

Generate Query
     ↓
Compile
     ↓
Run on Positive/Negative Cases
     ↓
Analyze Results
     ↓
Repair Query

这比一次性代码生成更具研究价值。

#13.4 对抗式独立验证

#背景

OpenAnt、VVAH、Cloudflare 都强调发现与验证分离，Anthropic Defending Code Reference Harness 进一步以定量数据佐证独立 Verifier + 强制 PoC 可将误报率压至接近 0，Make Agent Defeat Agent（USENIX Security 2025）在 LLM Agent 污点检测场景给出了该方法论的顶会实证。

#研究问题

如何避免 Verifier 只是重复 Finder 的偏见？

#可能方法

#Finding Contract 示例

{
  "claim": "attacker-controlled input reaches shell execution",
  "cwe": "CWE-78",
  "entry_point": "...",
  "source": "...",
  "sink": "...",
  "call_path": [],
  "preconditions": [],
  "expected_impact": "...",
  "falsification_conditions": []
}

#研究价值

可以专门研究：

#13.5 可利用性分级而非二元分类

#背景

ExploitGym 和 ExploitBench 等研究说明，漏洞存在与成功利用之间存在多个能力层级。

#一种可研究的分级方式

#V0：Candidate

存在危险模式或可疑语义。

#V1：Reachable

攻击入口能够到达安全敏感操作。

#V2：Attacker-Controlled

攻击者输入真实影响关键操作。

#V3：Triggered

构造输入能够触发异常或目标行为。

#V4：Impact-Confirmed

确定性证据证明真实安全影响。

#V5：Differentially Reproducible

漏洞版本稳定成功，修复版本稳定失败，并可多次重放。

#研究意义

这种分级比：

Vulnerable = true

更能描述证据强度。

#可研究问题

#13.6 漏洞类型专用的确定性 Runtime Oracle

#背景

LLM 自我判断 PoC 成功不可靠。

#SQL Injection Oracle

可以使用：

#Command Injection Oracle

使用随机 Canary Token，验证受控副作用，例如：

#Path Traversal Oracle

运行时随机生成：

/secret/canary-<uuid>

只有越权读取成功才能获得该值。

#SSRF Oracle

内部 Mock Service 生成唯一 nonce，只有目标程序主动请求才判定成功。

#Auth Bypass Oracle

对比：

访问受保护资源的结果。

#Memory Safety Oracle

Revelio（第 8.15 节）在 7 个持续 fuzz 5–8 年的成熟项目上以 ASan 复现为唯一判定条件，用约 $300 总花费发现 19 个未知内存安全漏洞，是该 Oracle 设计路径在 2026 年最直接的工程实证。

#创新价值

建立漏洞类别—验证器—Oracle映射是当前自动验证系统的重要研究空间。

#13.7 差分漏洞验证

#基本思想

使用同一个 PoC：

Vulnerable Commit
PoC = Success

Fixed Commit
PoC = Fail

#价值

差分验证可以减少：

#可扩展方向

Vul4J、CVE 修复提交等数据非常适合该研究。

#13.8 可重放证据链与 Event-Sourced Audit

#背景

ESAA-Security 和 Cloudflare 的状态管理实践说明，Agent 长任务需要持久化。

#可记录事件

RepositoryCheckedOut
ParserCompleted
CandidateGenerated
PathQueried
VerifierDecision
PoCCompiled
SandboxStarted
RuntimeEventCaptured
VerdictIssued

#每个事件可包含

#研究问题

#13.9 LLM 自动生成 Fuzz Harness

#背景

大量库无法获得高质量 Fuzzing，原因不是缺少 Fuzzer，而是缺少 Harness。

#研究流程

API / Function Target
       ↓
LLM Generate Harness
       ↓
Compile
       ↓
Repair Errors
       ↓
Run Fuzzer
       ↓
Measure Coverage
       ↓
Refine

#关键研究指标

#高价值方向

#13.10 Fuzzing 与 LLM 的闭环协同

除了 Harness，还可以研究：

关键原则仍然是：

#13.11 跨仓库与供应链可达性

#背景

Trivy 等工具可以发现：

Dependency X version Y has CVE

但真实风险取决于：

Application Entry
      ↓
Calls Vulnerable API?
      ↓
Attack Input Reaches It?

#研究方向

这是 SCA 与代码分析结合的重要方向。

#13.12 自动生成安全 Threat Model

#背景

VVAH 和 Codex Security 都强调项目特定威胁模型。

#研究问题

如何自动从代码提取：

#风险

自动 Threat Model 也可能遗漏关键资产或错误判断信任边界。

#可评测方法

#13.13 专项安全工作流（Taskflow）

通用 Prompt 很难同时覆盖：

因此可研究：

Vulnerability Class
      ↓
Specialized Workflow
      ↓
Specialized Evidence Contract

例如：

GitHub Taskflow Agent 是这一方向的重要参考。

#13.14 多模型异构协作

当前多 Agent 往往只是同一个模型的多个角色。

更值得研究的是：

#研究问题

#13.15 验证器的自我评测与置信校准

如果 Verifier 会误删真实漏洞，则需要评估：

可以允许 Verifier 输出：

Confirmed
Rejected
Insufficient Evidence

而不是强制二元判断。

#13.16 从漏洞报告生成到科学证据对象

传统报告字段：

更适合自动化漏洞研究的 Evidence Object 可以包含：

这使漏洞 Finding 从文本结论转为可计算、可比较的研究对象。

#14. 综合批判性综述

#14.1 “多 Agent”本身已经不是创新

目前已有大量系统采用：

Recon Agent
Audit Agent
Verify Agent
Report Agent

因此仅增加 Agent 数量不能证明研究价值。

真正有意义的问题是：

#14.2 “使用最新模型”不是方法创新

模型更新很快。如果研究贡献只是：

换成更强模型 → 指标提高

则结果难以持续。

更稳定的贡献是：

#14.3 SAST 与 LLM 不是替代关系

项目级实证研究表明：

更可信的研究方向是：

SAST / CPG / Fuzzing
          +
LLM Semantics / Planning
          +
Dynamic Verification

#14.4 发现能力与证据质量必须分开评价

一个系统可能：

另一个系统可能：

因此应该分别评价：

#14.5 自动 PoC 与自动 Exploit 应严格区分

#PoC

证明漏洞现象或安全影响。

#Exploit

获得特定攻击能力，例如：

很多系统把“构造触发请求”称为 Exploit，但在内存安全研究中这可能只达到 Crash/PoV。

报告中应准确使用术语。

#14.6 工程成熟度与学术证据强度应分开

例如：

因此比较系统时最好设置两个维度：

#Engineering Maturity

#Evidence Strength

不要把 GitHub Star 数量当成学术证据。

#14.7 2026 年最新结果需要防止“宣传数字误读”

OpenAI、Anthropic、Cloudflare 等机构公开了大量：

这些数据具有重要工程参考价值，但通常：

因此报告应写作：

而不是：

#14.8 当前最薄弱的环节是验证，不是发现

现代 LLM 很容易生成大量“看起来合理”的 Finding。

困难在于证明：

Attacker Control
   +
Reachability
   +
No Effective Defense
   +
Runtime Impact

因此漏洞验证、Oracle、差分实验和证据回放比增加一个扫描 Agent 更具有研究价值。

Anthropic Defending Code Reference Harness 的公开博客对该判断给出了同方向的工程佐证：截至 2026 年 5 月 22 日，Anthropic 自扫累计披露 1,596 个漏洞，但仅有 97 个完成修补——"发现的产能远超验证与修补的产能" 已经不是理论推测，而是被大厂运营数据直接印证的产业现实。

#14.9 真实研究将越来越依赖 Harness

未来高水平系统的差异可能更多来自：

而不是单一模型排行榜。

#15. 次要部分：工具组合与研究实验的通用启示

本节不是最终系统定位，也不要求照此实现，仅作为调研后得到的工具关系总结。

#15.1 不同工具的事实能力

工具类别主要输出的“事实”
Semgrep规则命中、危险 API、局部污点
CodeQL语义路径、跨过程数据流
Joern程序图、调用关系、切片
AFL++/libFuzzer覆盖率、触发输入、Crash
KLEE/angr路径约束、满足输入
Nuclei模板请求与 Matcher 结果
sqlmapSQLi 专项动态结果
CommixCommand Injection 专项结果
ASan/UBSan运行时错误类型
Tracee进程/文件/网络行为
CASRCrash 去重与根因信息
rr可重放执行轨迹
Trivy已知依赖风险与 SBOM

#15.2 通用研究链路

从技术关系看，比较自然的研究链路是：

候选发现
    ↓
程序结构与路径事实
    ↓
语义分析
    ↓
独立验证
    ↓
专项动态工具
    ↓
确定性 Oracle
    ↓
证据与回放

但具体课程实现应根据：

再选择，不宜为了工具数量而全部集成。

#16. 结论

本次调研覆盖了大模型智能体代码审计、传统程序分析、模糊测试、符号执行、漏洞验证、PoC/Exploit、运行时取证、沙箱和评测基准等多个方向。

综合来看，可以得出以下结论。

第一，LLM 并没有替代传统漏洞研究技术。 当前最具说服力的研究普遍采用混合方法：程序分析提供结构和路径，LLM 提供项目语义与假设，动态执行提供事实。

第二，项目级上下文是核心瓶颈。 真实仓库无法依赖函数级分类或全文 Prompt。攻击面、可达性、程序切片、CPG 和高层程序分析工具接口正在成为重要基础设施。

第三，验证正在取代发现成为主要难点。 现代模型可以快速生成大量候选，但真正证明攻击者可控、路径可达、缺少有效防御并产生实际安全影响仍然困难。

第四，自动漏洞利用需要分级。 Crash、PoV、Exploit Primitive 和 Full Exploit 是不同能力层级。不同漏洞类型也需要不同的确定性 Oracle。

第五，Harness 正在成为竞争核心。 2026 年的 OpenAnt、VVAH、Cloudflare Harness、Anthropic Defending Code Reference Harness、RAPTOR、Shannon、Taskflow Agent 等工作共同说明，工具编排、上下文路由、状态管理、验证协议和反馈闭环可能比单一模型选择更重要。

第六，可复现性和证据链是当前系统的重要研究空白。 事件溯源、Artifact Hash、容器环境、动态日志、差分版本和 Replay 应当成为高质量自动化安全研究的重要评价维度。

最后，从研究趋势看，未来一段时间最值得持续跟踪的方向包括：

这些方向共同反映了领域正在从“AI 给出一个漏洞答案”走向“AI 在工具和证据约束下完成可验证的漏洞研究过程”。

#参考资料

核心阅读 / Annotated Bibliography

以下条目从原报告“阅读优先级”和正文反复引用资料中抽取，用于快速复核论证主线。说明只依据本文已有描述，不扩展新的论文贡献。

  1. IRISICLR 2025论文 · 关联章节 2, 8

    用于说明 LLM 与程序分析互补，尤其是语义规格和静态路径事实的分工。

  2. OpenAntarXiv · Preprint · 2026论文 / 系统 · 关联章节 3, 8, 11

    用于说明可达性裁剪、对抗式验证和发现-验证分离的研究方向。

  3. LLM-based Vulnerability Detection at Project ScalearXiv · Preprint · 2026论文 · 关联章节 8, 11

    用于讨论项目级漏洞检测中上下文获取和仓库规模带来的困难。

  4. Sifting the NoisearXiv · Preprint · 2026论文 · 关联章节 8, 11

    用于支持误报过滤、验证分离和证据质量评价相关论述。

  5. DeepAudit★ 6.6k官方项目 · 关联章节 3

    代表面向代码审计的多智能体系统，用于比较沙箱 PoC 与报告生成链路。

  6. AgentStalker★ 128官方项目 · 关联章节 3

    用于说明静态建模、攻击图和动态验证结合的系统路径。

  7. Visa VVAH★ 645官方项目 · 关联章节 3, 9

    用于说明 Threat Model First 和企业级阶段化 Harness 设计。

  8. Cloudflare Vulnerability Harness机构技术文章 · 关联章节 9

    用于说明 Discovery Harness 与 Validation System 分离的工程实践。

  9. CyberGymarXiv · Preprint · 2025论文 / Benchmark · 关联章节 10

    用于讨论真实目标中的 PoC 生成和漏洞研究任务评测。

  10. CWE-Bench-Java★ 106Benchmark · 关联章节 10

    用于说明 Java CWE 检测与定位任务的评测方式。

  11. Code Property GraphIEEE S&P 2014经典论文 · 关联章节 4, 8

    用于建立程序结构化上下文的基础概念。

  12. CodeQL Data Flow Analysis官方文档 · 关联章节 4

    用于说明数据流、污点分析和变体分析在 LLM Agent 中可承担的事实计算任务。

  13. AFL++ Documentation官方文档 · 关联章节 4, 13

    用于说明覆盖率反馈、Fuzz Harness 和闭环执行的工具基础。

  14. Fuzz Introspector官方文档 · 关联章节 4, 13

    用于分析 Fuzz 覆盖缺口和 Harness 质量。

  15. ESAA-SecurityarXiv · Preprint · 2026论文 · 关联章节 3, 8, 13

    用于说明事件溯源式 Agent 架构和可重放证据链。

  16. CyberGym-E2EarXiv · Preprint · 2026论文 / Benchmark · 关联章节 8, 10

    用于讨论发现、PoC、修复和回归验证的端到端评测。

  17. Anthropic Defending Code Reference Harness★ 6.4k官方项目 · 关联章节 3, 9, 11, 14

    用于说明 7 Agent 架构、六阶段漏洞研究流程、gVisor 沙箱与官方自报复现数据。

  18. RevelioarXiv · Preprint · 2026论文 · 关联章节 8, 11, 13

    用于讨论廉价 LLM 与 ASan 强制复现结合的内存安全漏洞检测路线。

  19. Shannon★ 45.5k官方项目 · 关联章节 3

    用于比较白盒 AI Pentester、静态/动态分析协同和“未证 PoC 即弃”的验证约束。

完整资料

以下保留原报告完整资料分组，用于逐项核查来源。

#A. 经典程序分析、Fuzzing 与自动利用

  1. Yamaguchi et al. Modeling and Discovering Vulnerabilities with Code Property Graphs. IEEE S&P 2014.

Yamaguchi et al. Modeling and Discovering Vulnerabilities with Code Property Graphs. IEEE IEEE S&P 2014

  1. Cadar et al. KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs. OSDI 2008.

Cadar et al. KLEEOSDI 2008

  1. Joern Documentation.

访问资料

  1. CodeQL Data Flow Analysis.

访问资料

  1. Semgrep Taint Analysis.

访问资料

  1. AFL++ Documentation.

访问资料

  1. LLVM libFuzzer.

访问资料

  1. syzkaller.

google/syzkaller★ 6.3k

  1. boofuzz.

访问资料

  1. WinAFL.

googleprojectzero/winafl★ 2.6k

  1. Fuzz Introspector.

访问资料

  1. angr.

访问资料

  1. Triton.

JonathanSalwan/Triton★ 4.2k

  1. SymCC.

eurecom-s3/symcc★ 868

  1. rex.

angr/rex★ 653

  1. Mechanical Phish.

访问资料

  1. Mechanical Phish: Resilient Autonomous Hacking.

Mechanical PhishIEEE Security & Privacy · 2018

#B. LLM/Agent 漏洞发现系统与论文

  1. GPTScan.

GPTScanICSE 2024

  1. IRIS.

IRISICLR 2025

  1. JITVul.

JITVulACL 2025

  1. RepoAudit.

RepoAuditarXiv · Preprint · 2025

  1. QLPro.

QLProarXiv · Preprint · 2025

  1. LLMxCPG.

LLMxCPGarXiv · Preprint · 2025

  1. OpenAnt.

OpenAntarXiv · Preprint · 2026

  1. ESAA-Security.

ESAA-SecurityarXiv · Preprint · 2026

  1. LLM-based Vulnerability Detection at Project Scale.

LLM-based Vulnerability Detection at Project ScalearXiv · Preprint · 2026

  1. Sifting the Noise.

Sifting the NoisearXiv · Preprint · 2026

  1. VulWeaver.

VulWeaverarXiv · Preprint · 2026

  1. codebadger.

codebadgerarXiv · Preprint · 2026

  1. Revelio: Cost-Efficient Agentic Memory Safety Vulnerability Detection For Repository-Scale Codebases.

RevelioarXiv · Preprint · 2026

  1. Liu et al. Make Agent Defeat Agent: Automatic Detection of Taint-Style Vulnerabilities in LLM-based Agents. USENIX Security 2025.

Liu et al. Make Agent Defeat AgentUSENIX Security 2025

  1. DeepAudit.

lintsinghua/DeepAudit★ 6.6k

  1. AgentStalker.

Gach0ng/AgentStalker★ 128

  1. OpenSecurity.

zylc369/OpenSecurity★ 34

  1. Sandyaa.

securelayer7/sandyaa★ 233

  1. Vulnhuntr.

protectai/vulnhuntr★ 2.7k

  1. Visa VVAH.

visa/visa-vulnerability-agentic-harness★ 645

  1. Anthropic Defending Code Reference Harness.

anthropics/defending-code-reference-harness★ 6.4k

  1. Anthropic, Defending Code with Claude — Reference Harness Design Blog.

anthropics/defending-code-reference-harness

  1. Shannon — Autonomous White-box AI Pentester (Keygraph).

KeygraphHQ/shannon★ 45.5k

  1. Tencent AI-Infra-Guard — Full-Stack AI Red Teaming Platform.

Tencent/AI-Infra-Guard★ 4.1k

  1. RAPTOR.

gadievron/raptor★ 3.3k

  1. PentestGPT.

GreyDGL/PentestGPT★ 14.1k

  1. GitHub Security Lab Taskflow Agent.

访问资料

#C. 工业界与大型研究实践

  1. Google Project Zero, Project Naptime.

访问资料

  1. Google Project Zero, From Naptime to Big Sleep.

访问资料

  1. DARPA AI Cyber Challenge.

访问资料

  1. DARPA AIxCC Results.

访问资料

  1. Cloudflare, Build your own vulnerability harness.

访问资料

  1. OpenAI, Codex Security.

访问资料

  1. OpenAI, Why Codex Security Doesn't Include a SAST Report.

访问资料

  1. Anthropic, Claude Code Security.

访问资料

  1. Anthropic, LLM-discovered 0-days.

访问资料

  1. Anthropic, Project Glasswing.

访问资料

#D. 漏洞验证、利用与运行时工具

  1. Nuclei.

projectdiscovery/nuclei★ 29.5k

  1. Nuclei Templates.

projectdiscovery/nuclei-templates★ 12.6k

  1. OWASP ZAP.

访问资料

  1. sqlmap.

sqlmapproject/sqlmap★ 37.8k

  1. Commix.

commixproject/commix★ 5.8k

  1. Metasploit Framework.

rapid7/metasploit-framework★ 38.5k

  1. pwntools.

Gallopsled/pwntools★ 13.6k

  1. Trivy.

aquasecurity/trivy★ 36.8k

  1. AddressSanitizer.

访问资料

  1. UndefinedBehaviorSanitizer.

访问资料

  1. CASR.

ispras/casr★ 355

  1. rr.

rr-debugger/rr★ 10.6k

  1. Tracee.

aquasecurity/tracee★ 4.5k

  1. nsjail.

google/nsjail★ 4k

  1. gVisor.

访问资料

  1. Ghidra.

NationalSecurityAgency/ghidra★ 70.5k

  1. Qiling.

qilingframework/qiling★ 6k

#E. Benchmark 与数据集

  1. CWE-Bench-Java.

iris-sast/cwe-bench-java★ 106

  1. Vul4J.

tuhh-softsec/vul4j★ 133

  1. CyberGym.

CyberGymarXiv · Preprint · 2025

  1. CyberGym-E2E.

CyberGym-E2EarXiv · Preprint · 2026

  1. CVE-Bench.

CVE-BencharXiv · Preprint · 2025

  1. ExploitGym.

ExploitGymarXiv · Preprint · 2026

  1. SEC-bench Pro.

SEC-bench ProarXiv · Preprint · 2026

  1. Magma.

访问资料

  1. NIST, The Software Assurance Reference Dataset, IR 8561.

NIST, The Software Assurance Reference Dataset, IR 8561NIST IR 8561 · 2025

  1. NIST SARD.

NIST SARD

  1. ExploitBench.

ExploitBencharXiv · Preprint · 2026

附录：实体索引

系统

GitHub Security Lab Taskflow Agent Visa Vulnerability Agentic Harness ESAA-Security AgentStalker OpenSecurity GhidrAssist PentestGPT DeepAudit Vulnhuntr RepoAudit GhidraMCP GhidraGPT OpenAnt Sandyaa RAPTOR VVAH Anthropic Defending Code Reference HarnessShannonAI-Infra-Guard

工具

UndefinedBehaviorSanitizer Metasploit Framework Fuzz Introspector AddressSanitizer DongTai IAST OWASP ZAP libFuzzer syzkaller pwntools boofuzz Semgrep Radare2 Binwalk WinAFL LibAFL CodeQL Bandit Triton Ghidra Cutter Qiling Nuclei sqlmap Commix Tracee nsjail gVisor gosec AFL++ Joern SymCC Trivy UBSan KLEE angr ASan CASR rex

论文

LLM-based Vulnerability Detection at Project Scale Sifting the Noise codebadger VulWeaver KernelGPT GPTScan LLMxCPG JITVul QLPro IRIS RevelioMake Agent Defeat Agent

基准

OWASP Benchmark CWE-Bench-Java SEC-bench Pro CyberGym-E2E ExploitBench ExploitGym PrimeVul4J CVE-Bench NIST SARD CyberGym Juliet Vul4J Magma

实践

Cloudflare Vulnerability Discovery Harness Anthropic Claude Security DARPA AI Cyber Challenge OpenAI Codex Security Project Glasswing Mechanical Phish Project Naptime Big Sleep AIxCC