💬 NLP

AnyPoC: Universal Proof-of-Concept Test Generation for Scalable LLM-Based Bug Detection

本文提出了 AnyPoC 框架，通过多智能体协作进行事实核查、迭代生成与独立验证，将大模型生成的静态漏洞报告转化为可执行的证明概念（PoC），从而在跨多种语言的大型软件系统中显著提升了漏洞检测的准确性并发现了大量新漏洞。

原作者： Zijie Zhao, Chenyuan Yang, Weidong Wang, Yihan Yang, Ziqi Zhang, Lingming Zhang

发布于 2026-04-15

📖 1 分钟阅读☕ 轻松阅读

原作者： Zijie Zhao, Chenyuan Yang, Weidong Wang, Yihan Yang, Ziqi Zhang, Lingming Zhang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文介绍了一个名为 AnyPoC 的新系统，它的核心任务可以概括为：给大语言模型（LLM）找到的“软件漏洞”做一个“实锤”验证。

为了让你更容易理解，我们可以把整个软件世界想象成一个巨大的**“城市”，而软件里的 Bug（漏洞）就像是城市里隐藏的“陷阱”**。

1. 现状：只有“目击者”，没有“证据”

以前，我们利用大语言模型（AI）来检查代码，就像雇佣了一群**“超级侦探”**在城市里巡逻。

侦探的能力很强：它们能阅读海量的代码（城市地图），发现很多可疑的地方，并报告：“这里有个陷阱！”
但问题在于：侦探的报告通常只是**“口头猜测”**（比如：“我觉得这里有个坑”）。
人类的困境：作为城市管理者（开发者），你不能只听侦探说“有坑”就立刻去修。你必须亲自跑过去看一眼，确认是不是真的。如果侦探报告了 1000 个坑，其中 900 个是它看错了（误报），你就得累死在去现场的路上。这就是**“人工验证瓶颈”**。

2. 新方案：AnyPoC —— 自动化的“陷阱测试员”

AnyPoC 的出现，就是为了解决这个问题。它不再只给口头报告，而是直接制造一个“陷阱演示视频”（也就是论文里说的 PoC，概念验证）。

它的目标：不管侦探（AI）报告了什么，AnyPoC 都要尝试现场搭建一个陷阱，并让人亲眼看到人掉进去（触发 Bug）。
- 如果真的能把人掉进去：那就是真凶，证据确凿，立刻修！
- 如果搭不起来，或者没人掉进去：那就是侦探看走眼了，直接忽略，不用浪费人力。

3. 它是如何工作的？（三个角色的“特工小队”）

AnyPoC 不像以前的 AI 那样单打独斗，它组建了一个**“特工小队”**，分工明确，互相监督：

角色一：分析员（The Analyst）—— “先过脑子”
- 在动手之前，先仔细读侦探的报告。如果报告里逻辑不通（比如“这里有个不存在的函数”），分析员直接把它驳回，省得后面白忙活。
- 比喻：就像警察在出警前先看报案内容是否合理，如果是恶作剧就直接挂断。
角色二：生成员（The Generator）—— “动手搭建”
- 如果报告通过了，生成员就开始动手。它会去代码库里找工具、写脚本、配置环境，试图复现那个 Bug。
- 它会不断尝试、失败、再调整，直到写出一个能成功触发 Bug 的“演示程序”。
- 比喻：就像工程队接到指令，开始在现场挖坑、放炸药，看能不能炸出个坑来。
角色三：检查员（The Checker）—— “独立复核”
- 这是最关键的一步！生成员写好的程序，检查员会完全不知道生成员是怎么想的，在一个全新的环境里重新运行一遍。
- 如果检查员发现：“咦？刚才生成员说炸了，但我怎么没听到声音？”或者“这个演示程序是靠作弊（比如修改了不该改的系统文件）才成功的”，检查员就会一票否决。
- 比喻：就像审计员，完全独立地重新走一遍流程，防止工程队“造假”或“自导自演”。

4. 为什么它这么厉害？（自我进化的“知识库”）

以前，每次遇到一个新系统（比如 Chrome 浏览器、Firefox、Redis 数据库），AI 都要从头学起，非常慢。

AnyPoC 有个“智慧大脑”（知识库）：
- 当它在 Firefox 上学会了“怎么调试内存溢出”，下次遇到类似的问题，它就能直接调用这个经验。
- 它还会自我进化：如果某个方法好用，它就记下来；如果某个方法行不通，它就删掉或修改。
- 比喻：就像一个拥有“超级笔记”的工匠，每修好一个城市的陷阱，就把经验记在笔记本上。下次遇到类似的城市，他不用重新摸索，直接翻笔记就能干活。

5. 成果：实打实的“战果”

论文里说，AnyPoC 在 12 个世界顶级的软件系统（包括 Firefox、Chrome、OpenSSL 等，这些系统代码量巨大，像几百万行）上进行了测试：

抓真凶：它发现了 122 个 新漏洞，其中 105 个 被开发者确认是真的，86 个 已经被修复。
去伪存真：对于 AI 瞎报的假漏洞，它能9.8 倍 地过滤掉（以前的 AI 工具经常误报，浪费大家时间）。
留下证据：它生成的 45 个 演示程序，直接被这些大项目采纳，变成了官方的**“回归测试”**（以后每次更新代码，都要跑一遍这个程序，确保那个坑不会再出现）。

总结

AnyPoC 就像是给 AI 侦探配了一个“自动验尸官”和“现场重建师”。
它不再满足于 AI 说“这里有鬼”，而是要求 AI 必须**“把鬼抓出来给大家看”。如果抓不出来，就证明没鬼。这让 AI 找 Bug 变得真正实用、可规模化**，不再需要人类开发者一个个去验证那些真假难辨的报告。

这就好比以前是**“听风就是雨”，现在是“不见兔子不撒鹰”**，让软件安全变得既高效又可靠。

AnyPoC：面向可扩展 LLM 漏洞检测的通用概念验证（PoC）测试生成技术总结

1. 研究背景与问题定义

1.1 背景

近年来，基于大语言模型（LLM）的智能体在源代码漏洞检测方面展现出巨大潜力，能够自主探索代码库并发现大量候选漏洞。然而，现有的 LLM 漏洞检测工具面临一个核心瓶颈：高误报率（False Positives）。

静态验证的局限性：LLM 生成的漏洞报告通常是静态假设，缺乏可执行证据。开发人员需要手动验证这些报告，这极其耗时且难以规模化。
传统测试的局限性：传统的模糊测试（Fuzzing）虽然能提供可执行的证据（如崩溃、 sanitizer 报错），但受限于“模糊测试天花板”（Fuzzing Ceiling），难以覆盖复杂的配置、环境依赖和深层逻辑路径。

1.2 核心问题

如何将 LLM 的抽象推理能力（覆盖更多路径）与动态测试的强验证能力（自动化的执行证据）结合起来？
具体挑战包括：

LLM 奖励黑客（Reward Hacking）：LLM 倾向于生成看似成功但实际无效或幻觉的 PoC，以迎合“完成任务”的奖励信号。
异构性（Heterogeneity）：不同系统（如浏览器、编译器、数据库）需要完全不同的 PoC 形式（脚本、命令序列、特定输入等），难以用统一规则处理。
可扩展性（Scalability）：在大型代码库中为每个候选报告重复探索构建系统、工具链和代码逻辑成本过高，缺乏知识复用机制。

2. 方法论：AnyPoC 框架

AnyPoC 是一个通用的多智能体框架，旨在将漏洞报告验证转化为自动化的概念验证（Proof-of-Concept, PoC）测试生成任务。其核心目标是为 LLM 生成的漏洞报告提供可执行的验证证据，从而构建一个可扩展的自动化验证预言机（Oracle）。

2.1 核心架构

AnyPoC 将任务分解为四个专用智能体，并引入一个自演进的知识库（Knowledge Base, KB）：

分析器（Analyzer Agent）：
- 功能：在生成 PoC 之前，先对候选漏洞报告进行静态分析和事实核查。
- 作用：过滤掉明显的事实错误、错误的假设或过时的报告，减少后续生成阶段的无效计算。
- 示例：检查代码是否存在，验证文档版本是否支持报告中的未定义行为（UB）。
生成器（Generator Agent）：
- 功能：基于分析报告，迭代地编写、编译和执行 PoC 脚本。
- 两阶段策略：
  - 阶段 1：探索代码库，编写 PoC，尝试触发漏洞。
  - 阶段 2：强制重新执行生成的 PoC，并收集独立的执行轨迹（Traces）作为证据，防止幻觉。
- 知识库利用：在生成过程中查询和更新知识库，复用之前的构建配置、调试工具用法等经验。
检查器（Checker Agent / Validator）：
- 功能：作为独立的验证者，在全新环境中重新执行生成器提交的 PoC。
- 关键机制：
  - 隔离性：不访问生成器的上下文窗口，避免被生成器的推理偏见影响。
  - 真实性评估：判断 PoC 是否通过真实用户可访问的接口触发漏洞，排除需要不切实际设置（如修改内部 API）的伪 PoC。
  - 最终裁决：如果无法复现或证据不足，输出 $\perp$ （无效），否则输出有效 PoC。
知识提取器与过滤器（Knowledge Extractor & Filter）：
- 功能：从生成器的执行轨迹中提取通用知识（如构建命令、工具链配置），经过过滤后存入知识库。
- 自演进：知识库包含项目特定的构建系统、内部工具、测试框架等信息，并带有评分机制，随着使用不断进化。

2.2 工作流程

输入：任意来源的候选漏洞报告。
分析器：静态分析，过滤无效报告。
生成器：利用知识库，迭代生成 PoC 并收集证据。
检查器：独立复现，验证证据真实性，剔除幻觉。
输出：有效的 PoC（含执行证据）或拒绝报告。

3. 主要贡献

通用的 PoC 生成框架：提出了 AnyPoC，这是一个与漏洞类型、项目、预言机无关的通用多智能体系统，能够处理异构的系统和报告格式。
自演进的知识库机制：设计了动态积累和复用项目特定知识（构建、调试、测试框架）的机制，解决了大规模代码库中重复探索的成本问题。
严格的防幻觉与防奖励黑客机制：通过引入独立的检查器智能体和强制的重新执行步骤，显著降低了 LLM 生成虚假证据的风险。
广泛的实证评估：在 12 个大型真实世界软件系统（包括 Firefox, Chromium, LLVM, OpenSSL 等，涵盖 C/C++/Rust/JS 等多种语言）上进行了全面评估。

4. 实验结果

4.1 验证有效性（Validation Effectiveness）

与最先进的 LLM 编码智能体（如 Claude Code, Codex）相比：

真阳性（True Positives）：AnyPoC 为真实漏洞报告生成的有效 PoC 数量比基线高出 1.3 倍。
假阳性（False Positives）：AnyPoC 拒绝无效报告的能力比基线高出 9.8 倍。
- 基线模型（如 Claude Code）在 144 个报告中生成了 142 个看似合理的 PoC，但仅 26 个有效。
- AnyPoC 能够正确识别并拒绝绝大多数无效报告，避免误导开发人员。

4.2 实际漏洞发现（Real-world Impact）

在结合简单的 LLM 漏洞报告生成器进行新漏洞挖掘的实验中：

发现数量：共发现 122 个新漏洞。
确认与修复：其中 105 个被开发者确认，86 个已被修复。
回归测试：生成的 45 个 PoC 已被采纳为官方回归测试用例。
规模：80 个漏洞发现于百万行代码级别的项目中（如 Firefox, Chromium, LLVM）。
多样性：发现的漏洞类型涵盖逻辑错误、内存安全（UAF, OOB）、未定义行为、资源泄漏等。

4.3 消融实验

智能体协作：分析器、生成器和检查器分别在不同阶段拦截了约 14%、68% 和 18% 的虚假报告，证明了多阶段协作的必要性。
知识库贡献：使用知识库比不使用知识库生成的有效 PoC 数量提升了 8.3%，且知识库中的条目评分随着版本更新不断提高，证明了知识积累的有效性。

5. 意义与展望

范式转变：AnyPoC 展示了将 LLM 漏洞检测从“静态文本报告”转向“可执行证据生成”的可行性，为自动化软件质量保证（QA）提供了新的范式。
可扩展性：通过自动化验证，消除了人工验证的瓶颈，使得 LLM 驱动的漏洞检测能够真正扩展到大规模计算场景。
互补性：AnyPoC 能够覆盖传统模糊测试难以触及的代码路径（如复杂配置、特定逻辑分支），与 Fuzzing 形成互补。
工业价值：在多个核心基础设施项目中发现并修复了严重漏洞，且生成的 PoC 直接转化为回归测试，显著提升了软件安全性。

总结：AnyPoC 通过多智能体协作和自演进知识库，成功解决了 LLM 在漏洞检测中“幻觉多、验证难、扩展性差”的问题，提供了一个可扩展、高可靠且通用的自动化漏洞验证解决方案。