## 摘要 一个漏洞扫描器把召回从 39% 拉到 80%，误报也跟着涨，而且超过一半的「抓对了」其实是蒙对的。这篇 **DREA**（Decoupled Reasoning and Exploration Agents，解耦推理与探索智能体）是 arXiv 2026 的论文。做法很干脆：安全推理交给贵的大模型，翻仓库交给本地小模型。在自建基准 RepoPairBench 上，配对正确率从 19–26% 提到 30–42%，可计费 API 成本降到原来的 1/16 到 1/48。如果你在做代码安全、也在给 LLM 智能体算成本，这篇的两个数字值得记住。 **视频讲解**：[点击观看 B 站视频](https://www.bilibili.com/video/BV1GZJB62EW4) 章节时间轴： - 00:35 作者介绍 - 00:58 研究背景与动机 - 01:54 相关工作 - 02:25 方法 - 03:41 实验设计 - 04:43 实验结果 - 07:22 局限性 - 07:51 要点总结 - 08:25 参考文献 [TOC] ## 论文基本信息 | 项目 | 内容 | |---|---| | 标题（英文） | DREA: Decoupled Reasoning and Exploration Agents for Repository-Level Vulnerability Detection | | 标题（中文） | DREA：解耦推理与探索智能体的仓库级漏洞检测 | | 作者 | Mingyang Sun, Guozhu Meng | | 机构 | 中国科学院信息工程研究所 · 中国科学院大学网络空间安全学院 | | 会议 | arXiv 2026 | | arXiv | [arXiv:2607.13439](https://arxiv.org/abs/2607.13439) | | 项目网站 | [github.com/huhusmang/DREA](https://github.com/huhusmang/DREA) | ## 背景与动机 这一节回答一个问题：为什么只盯着一个函数看不出来漏洞。 真实漏洞很少老老实实待在一个函数里。权限检查可能写在另一个模块，参数校验在调用方，项目级配置藏在配置文件里。只把一个函数喂给模型，这些证据根本不在视野中。 论文举的例子是 CVE-2021-43781，出问题的项目叫 invenio-drafts-resources。漏洞函数 `publish` 其实调用了权限检查 `require_permission(identity, "publish")`。函数级分析器看到这一行，就判定「已鉴权」。缺口藏在函数之外：这次检查没有绑定到 `id_` 选中的那份草稿对象上，它只验证了一个全局能力。 DREA 靠三个跨文件事实还原了攻击路径。第一，同项目的 `read_draft`、`edit`、`delete_draft` 都传了 `record=draft` 做对象级鉴权。第二，默认的 `can_publish` 策略是最宽松的「任意用户」。第三，目标调用偏偏漏掉了 `record` 参数。官方补丁正是补上这个参数。 论文开篇还用了一个审计员的隐喻来定题。它说现实中的漏洞审计本来就是假设驱动的：审计员先立一个怀疑，再挑着追数据流、校验逻辑和权限检查，去证实或推翻它。随后论文用一句反问收口：能不能让检测从「静态上下文增强」换成「假设驱动的仓库探索」。 已有做法的问题正在这里。VulEval、ReposVul 这类工作会用调用图、依赖切片来补上下文，规则是固定的。固定规则给出的上下文，与当前那条安全假设无关。 ## 研究主线：从问题到结论  **图 4：研究主线。问题出在函数级看不到跨文件证据，结论落在推理瓶颈上。** ## 基准/方法设计 这一节讲清楚 DREA 到底怎么分工。 DREA 由两个智能体组成。**Planner** 用强推理模型，从目标函数出发识别安全敏感操作，形成初始漏洞假设，再决定下一步要什么证据。**Explorer** 是本地部署的轻量模型，用的是 4-bit 量化的 GLM-4.7-Flash，跑在单张 A800 上，支持 256K 上下文。它只负责检索事实，不做漏洞判定。 判决有硬约束。判 `VULNERABLE`，必须给出从攻击者可控输入到危险操作的触发路径。判 `BENIGN`，必须论证相关操作已经被充分防护。这逼着模型把话说实，而不是凭感觉给个标签。  **图 1：DREA 架构。Planner 不断修正安全假设，把取证请求交给本地 Explorer；Explorer 用只读工具在仓库里导航，回传结构化发现。** 配套基准叫 **RepoPairBench**。它从 NVD 里取带 CVE 编号的修复提交，用 PyDriller 抽出函数级 diff。每对样本有三件套：父版本里的漏洞函数、修复后的函数、以及还原整个工程所需的仓库地址与提交哈希。时间窗锁定 2021 到 2025 年的 Python 漏洞，理由是 Python 维护活跃、修复提交量大，而且跨文件判断的问题足够多。最终 100 对样本覆盖 48 个 CWE 类别，展开成 200 个分类实例。 每一对都准备两份仓库快照：修复提交的父版本，和修复提交本身。漏洞函数在修复前状态下评测，修复后的函数在修复后状态下评测。这样上下文和代码版本始终对得上。 ## 分类全景  **图 5：四条技术路线的分野。前三条检索的是静态可抽取的上下文，DREA 把探索方向交给安全假设。** ## 方法细节 这一节补充实现上的几个关键选择。 Explorer 只有四个只读工具：`ls`、`glob`、`grep`、`read_file`。工具集是刻意做小的，目的是不让它越界去做判定。 它的返回被组织成三类结构化发现。第一类是仓库上下文，比如相关文件、调用关系、模块结构与执行流。第二类是代码证据，也就是命中的代码片段与关键语句。第三类是安全发现，比如缺失的检查、不一致的授权写法、可疑的数据流链接。原始代码不会整坨塞回 Planner。 实验里每个样本大约跑 10 轮交互，证据够了就提前停。这个预算让贵的模型只花在推理上。 推理质量怎么判？论文用 LLM 当判官，判官选 GPT-4.1。选它的理由有两条：长而杂的输入下指令跟随稳定；它不在任何被测骨干里，避免模型偏爱自己的推理风格。判分看四件事：CWE 类别是否对齐、缺陷定位是否准确、根因是否抓住、利用机制是否成立。判定从严，识别出另一个「说得通」的漏洞也算理由错误。 判官本身也被校验过。作者按模型和方法分层抽了 50 例，请两位有五年以上漏洞分析经验的研究员独立标注。判官与两人的一致率是 96% 和 94%，Cohen's kappa 分别为 0.92 和 0.88。两位标注者彼此是 92%，kappa 为 0.84。 ## 实验设计与结果 这一节给出量化结果。 实验设三种 Planner 骨干：GPT-5.2、DeepSeek-V3.2、GLM-4.7。Explorer 固定为本地 GLM-4.7-Flash，这样检索端的差异被压掉，比较反映的是 Planner 行为。基线有三种：只给目标函数、给整个文件、以及「单智能体」——同一个骨干直接拿工具，但没有 Planner 与 Explorer 的分工。 主表用配对正确率（Pair-Correctness，P-C）当主指标。它要求一对样本的漏洞版和修复版全部判对，才算这一对正确。相比单点准确率，这个口径更难被「多报漏洞」刷分。 | 模型 · 方法 | Recall (%) | FPR (%) | P-C (%) | Youden's J (pp) | |---|---|---|---|---| | DeepSeek-V3.2 · DREA | 80.0 | 45.0 | **42.0** | **35.0** | | DeepSeek-V3.2 · 仅函数 | 39.0 | 32.0 | 19.0 | 7.0 | | GLM-4.7 · DREA | 59.0 | 38.0 | **34.0** | **21.0** | | GLM-4.7 · 仅函数 | 54.0 | 43.0 | 26.0 | 11.0 | | GPT-5.2 · DREA | 53.0 | 28.0 | **30.0** | **25.0** | | GPT-5.2 · 仅函数 | 42.0 | 25.0 | 21.0 | 17.0 | 三个骨干上 DREA 都拿到更高的 P-C 与 Youden's J。Youden's J 的定义是 $J=\mathrm{Recall}-\mathrm{FPR}$，它涨说明不是靠多报漏洞换分。DeepSeek-V3.2 的召回涨了 41 个百分点，误报只涨 13 个点。GLM-4.7 甚至在提高召回的同时，把误报从 43% 降到 38%。 消融实验只在一个骨干上做，因为每次跑一个样本要百万级 token。结果的分层很清楚。 | DeepSeek-V3.2 配置 | Recall (%) | FPR (%) | P-C (%) | API token (K) | |---|---|---|---|---| | DREA（Planner + Explorer） | 80.0 | 45.0 | **42.0** | 88 | | 单智能体（直接给工具） | 73.0 | 64.0 | 24.0 | 442 | | 整文件上下文 | 57.0 | 41.0 | 26.0 | 20 | | 仅函数 | 39.0 | 32.0 | 19.0 | 3 | 最值得看的是单智能体这一行。它的探索能力和 DREA 完全一样，却只拿到 24% 的 P-C，误报率高达 64%。原因是它把 442K token 的原始代码全塞进了上下文。整文件也不好过：只比仅函数高 7 个点，误报从 32% 升到 41%，说明无方向的上下文会引入噪声。 成本表回答「解耦值不值」。 | 模型 | 总 token | Planner token | API 占比 | 成本降幅 | |---|---|---|---|---| | DeepSeek-V3.2 | 1,397,669 | 87,847 | **6.3%** | 约 16 倍 | | GLM-4.7 | 1,560,519 | 32,557 | **2.1%** | 约 48 倍 | | GPT-5.2 | 345,691 | 8,357 | **2.4%** | 约 41 倍 | Explorer 承担了 93.7% 到 97.9% 的 token，全部跑在本地单卡上，不进 API 账单。Planner 只占 2.1% 到 6.3%。论文的口径很克制：只算可计费 API 成本，没有折算本地 GPU 开销。 类型层面的差异也很大。数据流型漏洞最好做。DeepSeek-V3.2 在 CWE-79 上到 69.2%，在 CWE-94 上到 71.4%。反序列化类的 CWE-502 跨模型是 42.9% 到 57.1%。缺防护型就吃力得多：CWE-284 跌到 0% 到 20%，CWE-20 停在 14.3% 到 28.6%。  **图 2：真阳分解。每根柱子分成「理由正确」与「Lucky Hit（标签对、理由错）」两段，柱上百分比为 Lucky Hit Rate。**  **图 3：按 CWE 类别分层的 P-C。上方数据流型漏洞一致优于下方缺防护型漏洞，括号内为该类别的对数。** 探索越多是不是越好？答案是否定的。DeepSeek-V3.2 的假阴样本平均花 170 万 token，比真阳的 124 万还多 37%。全部配置下，每样本 token 量与判对率的相关系数 $r\approx-0.34$。各结果类别的平均工具调用次数都在 9.2 到 10.0 之间，几乎没差别。 ## 结果对比总结  **图 6：同一骨干下的四种配置。DREA 拿到最高 P-C，同时只有 88K 的 API token。** ## 关键发现 - 假设驱动的探索确实赢过静态上下文：同一骨干下 P-C 从 19–26% 提到 30–42%，三个模型无一例外。 - 能力分工是降本关键：93.7% 到 97.9% 的 token 交给本地小模型，账单降到 1/16 到 1/48，而检测性能还在涨。 - 结构化证据比代码量重要：单智能体 442K token 只换到 24% P-C，DREA 用 88K 拿到 42%。 - 探索强度是难度的症状：失败的样本反而更长更贵，$r\approx-0.34$ 说明瓶颈在综合证据，不在查得多不多。 - 蒙对现象很普遍：真阳里 26% 到 55% 的理由不成立，DeepSeek-V3.2 达 55.0%，GPT-5.2 也有 32.1%。而且这不只是某个方法的问题，DREA 和仅函数基线都有。 - 从创新模式看，这篇踩中了两条线。一条是把「标签判对」与「理由成立」拆开测量的诊断设计。另一条是把探索请求分解，委托给专职求解器。诊断本身成了贡献。 ## 局限性 - 基准只有 100 对。作者自己说，这足够观察一致差异，但覆盖不了长尾漏洞模式；每一对都要有可还原的仓库快照、单函数修复和人工核验，扩不起来。 - 按 CWE 拆分后每组只剩 3 到 13 对，类别级结论的置信度有限。 - 判官的人工校验只覆盖 50 例。一致率虽高，规模仍然偏小。 - 成本口径只算 API token。本地 Explorer 的 GPU 开销没有折算进去；消融也只在一个骨干上完成。 ## 常见问题（FAQ） ### 我要复现这篇，得准备多少显存？ Explorer 是 4-bit 量化的 GLM-4.7-Flash，论文里跑在单张 A800、256K 上下文。Planner 走 API，本地不占显存。也就是说一张数据中心级卡就能起完整流水线。 ### 它和 VulnLLM-R、MulVul 这类智能体方法差在哪？ 差别在检索的源头。它们用智能体去取静态可抽取的上下文，比如预计算的调用图、CodeQL 查询结果、漏洞知识库。DREA 的 Explorer 直接在完整仓库上用通用只读工具，而且下一步看什么由 Planner 的安全假设实时决定。 ### 用本地小模型翻代码，会不会把效果拖下来？ 论文的答案是反过来。Explorer 固定成同一个轻量模型后，三个骨干的 P-C 都提升了。真正决定质量的是 Planner 的推理和「证据是否被过滤成结构化结论」，而不是检索模型有多大。 ### 成本降 16 到 48 倍这个数能当真吗？ 它的口径是可计费 API token。总 token 里只有 2.1% 到 6.3% 走付费模型，其余在本地。如果你把自建 GPU 的电费和维护算进去，倍数会明显缩水，但量级差异仍然在。论文自己也把这条写进了局限。 ### Lucky Hit 这个指标我能直接搬走吗？ 能，只要你的任务同时输出标签和理由。它的定义很朴素：真阳里理由不成立的比例，$1-\mathrm{LHR}$ 就是理由正确率。代价是需要一个可信的判官，而判官本身要拿人工标注校核。 说到底，这篇最值得带走的一句话是：卡住当前 LLM 的不是上下文长度，而是安全推理本身。想顺着往下看，可以先读 MulVul 这类多智能体检索工作，再看看用安全反馈做强化学习的 R2Vul 路线。 ## 参考链接 - [DREA 论文（arXiv:2607.13439）](https://arxiv.org/abs/2607.13439) - [DREA 代码与 RepoPairBench](https://github.com/huhusmang/DREA) - [PrimeVul：配对评测与代码模型能力边界（arXiv:2403.18624）](https://arxiv.org/abs/2403.18624) - [VulEval：仓库级漏洞检测评测（arXiv:2404.15596）](https://arxiv.org/abs/2404.15596) - [SWE-Agent：智能体导航仓库（arXiv:2405.15793）](https://arxiv.org/abs/2405.15793) - [VulnLLM-R：带智能体脚手架的漏洞检测（arXiv:2512.07533）](https://arxiv.org/abs/2512.07533) --- > 给大家推荐一款自用写文献综述、无虚构文献的 AI： > > 🌟 **复旦大学 FudanNLP 团队自研 [切问学术](https://qiewenpaper.com/zh?utm_source=bzkol&utm_content=baishi)** > > 官网：[qiewenpaper.com](https://qiewenpaper.com/zh?utm_source=bzkol&utm_content=baishi) > > 覆盖 **3.6 亿篇**可溯源真实中英文文献，能自动整合文献观点生成规范综述 > > 还能挖掘研究创新点、复现实验，配合视频教学，新手快速上手文献综述写作 --- > **🍀后记🍀** > > 博客的关键词集中在编程、算法、机器人、人工智能、数学等等，持续高质量输出中。 > > **🌸讨论QQ群**：[白拾的小屋](https://qun.qq.com/universal-share/share?ac=1&authKey=Suzrb5NKb9KulvZxFC8EMFvcd6jgVp%2B%2BnTG8h351HWQorXVfvI1n5QwEX5dlJyTh&busi_data=eyJncm91cENvZGUiOiI3NTAzNjU3MDAiLCJ0b2tlbiI6IlpFL2xLaGYxdXU4cWJPT2dJTkY3aExnWHNaQ1UrL3NJbWprenhLZitWUHVVNmhIR1M5SkZrS09SWmxKNlRreksiLCJ1aW4iOiIyMjc1OTYwNDg2In0%3D&data=hgymRnqgtjQPGoBKhZ8cEyznp0CMLWfCbG4rfiWIADCArVXw50a7c-Q4MWU2Eq3dwOUjG19hamAWQQU4lY-cOQ&svctype=4&tempid=h5_group_info) (750365700) > > **⭐B站账号**：[白拾的物理AI组会](https://space.bilibili.com/98639326)（活跃于知识区和动画区） > > **✨GitHub主页**：[YhbCode000](https://github.com/yhbcode000)（工程文件）