漏洞定位基准：在仓库规模上衡量 agent 安全分析
来自 arXiv · 期号 2026-09-15
摘要
安全评测通常看 agent 能不能发现、复现或修好漏洞，但很少问它能不能找到漏洞在哪。 VLoc Bench 把这个问题单独拎出来测：给 agent 一个漏洞类型（CWE 描述）和一份陌生仓库的快照，只给只读终端权限，让它找出受影响的文件。基准包含 290 个仓库的 500 个真实漏洞，覆盖 6 个包生态和 147 个 CWE 类别。 结果不乐观：最强系统 File F1 只有 0.229，38.4% 的任务没有任何模型能正确定位。而且定位能力强不代表修复后行为可靠——能找出漏洞文件的系统，在已修补的仓库上仍然会报出不存在的位置。 论文把漏洞定位定义为一个独立于检测和修复的仓库级能力，并提供了一个测试 agent 该什么时候报告、什么时候该停下来的场景。
深读
导读 漏洞定位是安全 agent 的一项基础能力，但现有评测几乎都绕过了它，直接跳到检测、复现或修复。VLoc Bench 把这个问题单独拎出来测：给 agent 一个漏洞类型描述和一份陌生仓库的快照，只给只读终端权限，看它能不能找出受影响的文件。结果不乐观，最强系统 File F1 只有 0.229，近四成任务没有任何模型能正确定位。这篇论文为安全 agent 评测补上了关键的一块拼图。 关键信息 - 基准包含 500 个真实漏洞，来自 290 个仓库，覆盖 6 个包生态（npm、PyPI、Maven 等）和 147 个 CWE 类别。 - 每个任务提供漏洞修复前后的两份仓库快照：在未修复版本上 agent 必须返回受影响的文件，在已修复版本上 agent 必须判断漏洞已不存在。 - 评测了 27 个语言模型和 4 个静态分析工具，统一使用同一个 agent 接口。 - 最强系统 File F1 仅 0.229，38.4% 的任务没有任何模型能正确定位。 - 定位能力强不意味着修复后行为可靠：能找出漏洞文件的系统，在已修补的仓库上仍然会报告不存在的位置。 逐节讲解 问题定义：漏洞定位是独立能力 现有安全评测主要测 agent 能否发现、复现或修复漏洞，但很少问它能不能找到漏洞在哪个文件里。论文把「漏洞定位」定义为一个独立的仓库级能力：给定一个弱点类别（CWE 描述）和一个不熟悉的仓库，识别出与该弱点相关的实现文件。这个能力与检测和修复是正交的，能修好一个漏洞不代表能在一堆文件里把它找出来。 基准设计：修复前后的对照 VLoc Bench 包含 500 个真实漏洞，每个漏洞对应一个仓库在安全修复前后的快照。在未修复版本上，agent 只拿到 CWE 描述和只读终端权限，必须返回受影响的文件；在已修复版本上，agent 必须判断该漏洞已不存在。这种对照设计让评测能同时测定位能力和「该停的时候停」的能力，后者在现有评测中几乎被完全忽略。 评测结果：定位很难，且定位强不等于行为可靠 27 个语言模型和 4 个静态分析工具在统一 agent 接口下评测。仓库级漏洞定位仍然困难：最强系统 File F1 只有 0.229，38.4% 的任务没有任何模型能正确定位。更关键的是，定位能力强不意味着修复后行为可靠，能找出漏洞文件的系统，在已修补的仓库上仍然会报告不存在的位置。这说明安全 agent 的「何时该报告」和「何时该停止」是一个独立于定位能力的维度，需要专门的评测场景来研究。 值得注意 论文只给出了摘要，没有展开具体的方法细节（如 agent 的搜索策略、工具调用方式、模型间的性能排名等）。摘要中提到的「27 个语言模型和 4 个静态分析工具」没有列出具体名称和版本，File F1 的计算方式也未说明。这些细节需要阅读全文才能获得。