VLoc Bench released: evaluating Agent vulnerability localization capability in complete repositories

论文试图解决大语言模型智能体在缺乏代码位置先验时，能否仅凭抽象漏洞弱点类型在整个代码仓库中自主定位漏洞实现文件的问题。

• 场景与现实需求：在现实软件安全应急中，防御者接到漏洞公告或弱点排查需求时，必须先在陌生的完整代码仓库中找出需要调查和修复的具体实现文件，这直接影响补丁范围与衍生影响分析。
• 现有评测的局限：现有安全基准大多预先给出待检测的代码片段或函数，退化为漏洞识别任务；或直接评估利用与生成补丁等下游行为，将定位过程隐藏在执行反馈中或显式提供文件线索。
• 核心观察与假设：作者认为漏洞定位与漏洞检测是不同维度的能力，且定位与防御性克制互为补充；实用的防御辅助系统不仅要在漏洞存在时找出受影响文件，还必须在漏洞已被修复的代码上避免误报。
• 基准方案提出：论文提出了漏洞定位基准 VLoc Bench，包含来自 290 个仓库的 500 个真实漏洞任务，为智能体提供只读终端交互环境，分别测试修复前快照的定位能力与修复后快照的误报抑制能力。
• 威胁模型设定：根据论文第 3.1 节，评测采用面向防御者的设定：
  • 目标：识别防御者调查与修复该弱点所需修改的代码文件。
  • 知识：仅获知通用的 MITRE CWE 弱点类别描述，不提供 CVE 编号、漏洞公告文本、修复提交或代码行提示。
  • 能力：仅具有隔离沙箱中的只读终端命令权限，禁止写操作、网络访问与代码执行。
  • 受害系统：覆盖 6 种包生态的真实开源仓库修复前与修复后快照。

软件工程领域的仓库级定位

• 检索与探索智能体：ContextBench（2026）、CodeGrep（2026）与 SWE-Explore（2026）研究智能体如何在代码仓库中定位与报告相关的文件或上下文；作者指出这类任务始于具体的软件缺陷或工单报告，通常包含特定于仓库的故障线索，而安全定位需要根据抽象漏洞语义进行搜索。
• 代码图与排序方法：LocAgent（2025）、CoSIL（2025）与 CORE-Bench（2026）探索利用图结构或分块检索代码位置；作者指出这些基准默认缺陷必然存在，未提交定位仅被视为定位失败，未考虑安全场景中无漏洞情况下的克制。

安全领域中的漏洞检测与下游任务

• 代码片段级检测：PrimeVul（2025）、JitVul（2025）与 SecVulEval（2025）评估模型对已选出的代码片段、函数或提交是否包含漏洞的判断能力；作者指出这仅测量漏洞识别，回避了在全仓库中检索候选代码的前置步骤。
• 执行驱动的利用与修复：CyberGym（2026）、Vul4Py（2026）与 ExploitGym（2026）通过运行测试、触发崩溃或生成利用来评估能力；作者指出在缺少漏洞特定证据时，漏洞发现会成为主要瓶颈，但这些评测未将定位本身作为独立评分对象。

真实漏洞的定位与代码搜索

• 不同粒度的漏洞定位：RustMizan（2026）、CWE-Bench-Java（2025）、VulnGym（2026）与 AutoTrace（2026）尝试对真实漏洞的数据流路径、触发语句或入口点进行定位；作者指出它们多从修复提交、公告文本或特定函数出发，并非在整库尺度下仅凭 CWE 描述开展定位。
• 漏洞缺席与修复验证：Bessey 等人（2010）、DREA（2026）与 BountyBench（2025）关注静态分析或智能体在补丁代码上的误报问题；作者指出安全分析工具必须处理漏洞已修复或不存在的情况，但此前未在仓库级定位任务中联合评估定位与克制。

评测基准与对比基线

• 基线与基准设置：论文以自建的 VLoc Bench 为基准，评测了包括 GPT-5.5、Gemini 3 Pro、GLM-5.2 在内的 27 个语言模型，并对比了 Semgrep、Semgrep-CWE、CodeQL 和 Horusec 共 4 款静态代码分析工具。

作者将 VLoc Bench 定位为在不提供代码位置线索的情况下，在完整仓库尺度上同时评估文件级漏洞定位性能与修复后快照验证行为的评测基准（据 Table 1 注）。

论文提出了 VLoc Bench 基准，通过成对构建真实漏洞修复前后的代码仓库快照，在只读终端环境中仅向模型提供抽象 CWE 弱点描述，分别评测漏洞定位与修复后验证两项互补能力。

基准构建与任务来源

• 数据来源与筛选：从 GitHub Security Advisories（GHSA）中提取 2016 至 2026 年间披露的漏洞，排除仅修改测试/文档/CI/锁定文件的任务、私有或删除的仓库、补丁涉及超过 50 个文件的任务以及缺乏 CWE 分类的条目，最终保留 500 个任务。
• 成对快照设计：每个任务包含修复前（pre-push）与修复后（post-push）两个提交快照；修复前快照包含漏洞，修复后快照包含修复实现，完整保留目录结构与源码。
• 真值文件标注：通过补丁差异确定真值文件，利用路径启发式规则过滤测试和文档路径（如 test/、docs/、*_test.*、*.md 等），仅保留被补丁修改的实现源文件。

交互协议与评测沙箱

• 输入限制：智能体仅接收通用的 CWE 描述（例如 CWE-79 的标准定义），论文隐匿了公告文本、CVE 编号、严重程度分级、受影响版本和文件线索。
• 受限终端接口：智能体通过只读终端命令（如 ls、find、grep、sed、cat）探索仓库，禁止文件写入、网络访问和进程执行；任务预算设为最多 15 次终端命令和 20 轮生成，连续 3 轮未调用工具将被强制终止。
• 隔离沙箱环境：每个任务在独立的 Ubuntu 24.04 Docker 容器中执行，分配 2 个 CPU 核心、4 GB 内存，网络完全禁用，单条命令超时 10 秒；仓库以只读方式挂载于 /repo/，任务结束后销毁容器以防止跨任务信息泄露。

评估阶段与判定指标

• 两阶段评估流程：
  1. Phase A（定位）：智能体在修复前快照中探索，通过调用 submit_vulnerable_files 提交排序的文件路径列表；若调用 submit_no_vulnerability_found 或耗尽预算则判定错误。
  2. Phase B（验证）：智能体在修复后快照中接收相同的 CWE 描述，正确行为是调用 submit_no_vulnerability_found 确认无漏洞；提交任何文件路径均视为假阳性。
• 核心计算公式： Phase A 使用提交文件与真值文件的文件级 F1 分数评测定位效果： File F1 = (2 · Precision · Recall)/(Precision + Recall) 其中精准率 Precision 与召回率 Recall 均按集合交集除以对应文件总数计算；提交路径视为无序集合。 Phase B 则使用真阴性率评测模型在已修复代码上的克制能力： TNR = (|tasks correctly declared clean|)/(|total Phase B tasks|) 该指标反映模型正确判断已修复仓库中不存在该漏洞的比例。

实验设置

• 被测系统：包含 8 款闭源前沿模型（GPT-5.5 xhigh、GPT-5.5 default、Gemini 3 Pro、Gemini 2.5 Flash、GPT-5 Mini、Gemini 3.1 Flash Lite、GPT-5、GPT-5 Nano）、9 款大参数开源模型（GLM-5.2、Gemma-4-31B、Qwen3.5-27B、Qwen3.5-122B、Qwen3.5-35B-A3B、GPT-OSS-20B、GPT-OSS-120B、MiniMax-M2.7、Llama-3.3-70B）、7 款小参数开源模型（CodeScout-14B、Qwen3.5-9B、Gemma-4-E2B、Gemma-4-E4B、Granite-4.0-350M、Granite-4.0-Micro、Granite-4.0-1B）、3 款专用模型（Antares-3B、Antares-1B、Antares-350M）以及 4 款静态分析工具（Semgrep、Semgrep-CWE、CodeQL、Horusec）。
• 数据集与规模：VLoc Bench 的 500 个真实漏洞任务，覆盖 Go（215 个）、Maven（104 个）、npm（88 个）、pip（52 个）、Rust（40 个）和 Composer（1 个）共 6 个包生态，涵盖 147 种 CWE。
• 评测指标：Phase A 评测文件级 F1（File F1）、精准率（Precision）、召回率（Recall）及弃权率（Abstain Rate）；Phase B 评测真阴性率（TNR）。
• 评审与判定方式：采用基于补丁修改文件列表的确定性代码匹配计算 F1，Phase B 依据是否调用无漏洞提交函数判定，无需额外模型评审；采样温度设为 0.3，单轮最大补全长度 16,384 token。
• 样本量与重复次数：每个系统在全部 500 个任务上独立重复运行 3 次，报告指标的宏平均值（Macro-average）。

主结果

主结果汇总于下表（选取各类代表性模型与工具，据 Table 2 与 Table 3）：

Swipe horizontally to read the table

(注：表中省略了同系列的 GPT-5.5 default、Gemini 2.5 Flash、Qwen3.5 系列、Granite 系列等其余 20 款模型及 3 款静态工具，完整数据见 Table 2 与 Table 3)

• 整体定位难度较高：表现最高的前沿系统 GPT-5.5 (xhigh) 的 File F1 为 0.229，且全场仅有 5 款模型系统的 File F1 达到 0.18 以上（Table 2）。
• 定位与验证表现出现脱节：Phase A 定位分数较高的模型在 Phase B 的 TNR 普遍偏低（如 GPT-5.5 xhigh 的 TNR 为 0.279，Antares-3B 为 0.034），而在 Phase A 得分靠后的系统往往呈现出高 TNR（如 Granite-4.0-1B 达到 1.000，GPT-5 Nano 达到 0.868）（Table 3）。
• 参数规模非决定性因素：在通用开源模型中，参数量与 File F1 的 OLS 拟合相关系数为 r=0.50（Figure 2）；微调专用模型 Antares-3B（3B 参数）取得了 0.223 的 File F1，高于多数大参数通用模型（Table 2）。

仓库难度与特征回归分析

• 测了什么：使用 52 个仓库结构与漏洞元数据特征（Lasso 回归），以及包含 15 个模型特征的联合回归（67 个特征），分析任务固有难度的来源（第 5.1 与 5.2 节）。
• 实验结果：纯仓库特征回归在 5 折交叉验证下达到 R^2=0.164，代码集中度 top5_loc_share 系数为 +0.082（更易），压缩体积 log10_zip_size_kb 系数为 -0.037（更难），Go 生态 eco_go 系数为 -0.017（Table 4）；联合回归中仓库结构特征的权重绝对值之和为 0.285，是模型类别权重（0.063）的 4.5 倍（Figure 3）；纯模型特征回归的交叉验证 R^2 为 0.007（Table 5）。
• 作者解读：仓库结构是决定定位难度的主要来源，代码分布分散、目录层次深以及 Go 语言项目更难定位；模型属性虽影响平均表现，但几乎无法预测具体哪个任务会被解决。

仓库规模与未解决任务分解

• 测了什么：按仓库体积切分区间统计全模型平均 File F1，并统计所有模型均未命中的任务分布（第 5.3 节）。
• 实验结果：小于 100 KB 的仓库平均 File F1 为 0.598（n=20），而大于 10 MB 的仓库平均 File F1 降至 0.058（n=223），两者相差约 10 倍（Figure 4）；全基准中有 38.4% 的任务在全部 27 款模型中的 File F1 均为 0，其中大型 Go 和 Maven 仓库分别占该未解决子集的 47% 和 31%。
• 作者解读：搜索空间扩大直接削弱了定位信号；当前模型在大型复杂项目上存在持久的难以处理的硬核任务集。

失败模式与行为分析

• 测了什么：将约 38,500 次非满分运行按追踪行为分类，统计失败原因分布及命令使用关联（第 5.4 与 5.5 节）。
• 实验结果：未提交文件（Abstained）占 59.1%，提交文件错误占 40.9%；最主要的二级失败模式为用尽预算（Exhausted budget，32.3%）与完全找错文件（Wrong files，27.4%）（Table 6）；平均命令数与平均 File F1 的 Pearson 相关系数为 r=0.72（p<0.001）。
• 作者解读：失败主要源于长时间搜索未收敛或误报；有效定位需要长程探索、定向代码检索与稳定的工具交互配合。

其他消融与分析

• Lasso 惩罚形式变体：Elastic Net（l1-ratio=0.5）下仓库结构与模型类别的权重比为 5.7 倍；置换重要性下两者比值为 3.2 倍（第 5.2 节）。
• 推理努力程度对比：GPT-5.5 在 xhigh 设置下 File F1 为 0.229，在 default 设置下为 0.221（Table 2）。
• 规则特化变体：Semgrep 默认规则下 File F1 为 0.086，指定 CWE 规则的 Semgrep-CWE 下 File F1 降至 0.052（Table 2）。
• 单任务评测成本与时间：Antares-350M 在单张 H100 上耗时约 11 分钟、花费 0.60 美元；GPT-5.5 xhigh 经 API 耗时约 5 小时、花费 141.00 美元（Table 8）。

负面结果与例外

• 通用代码能力未转化为安全定位优势：Llama-3.3-70B 出现 75.3% 的过早终止（Premature termination），File F1 仅 0.012（Table 2、Table 7）；Granite-4.0-1B 和 Granite-4.0-Micro 的 File F1 均为 0.000（Table 2）。
• 模型验证普遍失真：针对漏洞定位训练的专用模型在修复后快照上大量报出不存在的漏洞文件，Antares-3B 的 TNR 为 0.034，Antares-1B 仅为 0.008（Table 3）。

作者指出的局限与后续方向

• 真值文件范围局限：在 Phase A 中，补丁修改的实现文件虽然提供了可复现的定位目标，但可能无法涵盖与该漏洞相关的所有文件（第 7 节）。
• 已修复快照缺乏全局安全性保证：在 Phase B 中，已打补丁的快照仅确认了所记录的特定漏洞已被修复，并不代表该仓库不存在其他漏洞；这限制了对 Semgrep、CodeQL 等通用静态分析工具的评估，因为这些工具在基准目标之外的检出在缺乏额外基准真值（Oracle）的情况下无法判定对错（第 7 节）。
• 验证阶段的弃权判定混淆：Phase B 的真阴性统计将模型的主动弃权与生成超限、API 报错或模型拒答等未产生提交的失败情况合并在了一起（第 7 节）。
• 引入不同层次的任务上下文：作者计划后续扩展 VLoc Bench，从当前的仅提供 CWE 描述逐步增加更详细的漏洞信息，以测试额外安全上下文对定位表现的影响（第 7 节）。
• 增强 Phase B 的结果验证方式：作者计划后续通过人工复核、概念验证（PoC）或其他行为判定基准，对模型在 Phase B 提出的额外检出进行验证，从而将真实漏洞发现与误报区分开来（第 7 节）。
• 对中间安全能力的内在评估：作者认为漏洞定位仅是安全分析工作流的一个阶段，未来基准应将此类中间分析能力与端到端外在评估相结合（第 7 节）。

实验覆盖范围

• 被测系统覆盖：实验测试了 27 款语言模型和 4 款静态代码分析工具；未包含 Anthropic 的 Claude 系列模型，作者在附录 D 说明因超出评测预算而未纳入。
• 生态与语言分布：评测覆盖 Go、Maven、npm、pip、Rust 和 Composer 共 6 个生态系统，其中 Go 语言占比 43%，Composer 仅包含 1 个任务（第 3.1 节）。
• 弱点类别与严重程度：涵盖 147 种 CWE 弱点，CVSS 等级集中在 High（44%）与 Medium（39%），Critical 占 11%，Low 占 6%（第 3.1 节）。
• 交互与资源约束：所有模型均固定在只读终端接口、最多 15 次命令和 20 轮生成、单条命令 10 秒超时、2 核 4 GB 内存的无网络 Docker 容器中评测（第 3.2 节）。
• 模型未提交语义的不可分性：论文通过命令数和提交状态对失败进行确定性划分，但未直接识别追踪背后的语义意图，例如无法区分搜索失败是源于对 CWE 理解有误还是目录选择不当（第 5.5 节）。

• 研究定位：针对大模型智能体在安全分析中往往跳过代码排查直接评测下游行为的现状，论文提出了评估全仓库尺度下弱点定位与修复后验证能力的基准 VLoc Bench。
• 核心问题：现有安全基准多预选代码片段或由测试用例驱动下游利用与修复，使得智能体在未知代码库中仅凭抽象弱点类别能否独立找准漏洞代码这一防御关键能力缺乏客观度量。
• 基准方法：基准基于 500 个真实漏洞构建成对的前后快照，在只读终端沙箱中仅向智能体提供 CWE 类别描述；分别在修复前快照测试其检出补丁文件的 File F1，并在修复后快照测试其判断漏洞已消除的真阴性率（TNR）。
• 核心实验发现：
  1. 定位整体难度大：在 27 款语言模型中，表现最高的 GPT-5.5 (xhigh) 在 Phase A 仅取得 0.229 的 File F1，且全基准有 38.4% 的任务所有模型均未定位成功（Table 2，第 5.3 节）。
  2. 定位与克制出现权衡：定位得分较高的模型在已打补丁的快照上表现出明显的误报倾向，GPT-5.5 (xhigh) 的 TNR 仅为 0.279，微调模型 Antares-3B 的 TNR 仅为 0.034（Table 3）。
  3. 仓库结构主导任务难度：回归分析结果中仓库结构特征对难度解释的权重是模型类别权重的 4.5 倍（Figure 3），大于 10 MB 的仓库平均 File F1（0.058）仅为小于 100 KB 仓库（0.598）的约十分之一（Figure 4）。
• 作者结论与启示：作者认为漏洞定位是一项独立于通用代码能力的仓库级安全分析技能；构建实用的防御型智能体不仅需要提升长程目标检索与工具交互水平，更必须将修复后识别无漏洞、避免告警疲劳的克制能力作为首要考量。