AISLE联合中欧技术研究所和马萨里克大学推出了HoF-Bench，一个基于真实AI发现漏洞的基准测试。基准包含8个代码库的95个CVE（通用漏洞披露），在严格协议下，最便宜的配置只需66美元就找到了70个CVE，而GPT-5.6 luna需要128美元，只找到65个。所有检测器都不使用前沿模型，依靠的是开放的权重模型和专有小型模型。
从AISLE的280多个CVE中精选95个
AISLE的LLM分析器已在OpenSSL、curl、GnuTLS等78个开源项目中发现了280多个CVE。HoF-Bench从中选取了95个，分布在8个代码库中，每个代码库都固定在易受攻击的提交版本上。
基准的设计原则是严格：分析器只接收源文件和目标文件范围，不提供CVE标识符、描述、修复方案或预期机制。发现通过检测器盲态的前沿模型评判者评分，只有识别出相同代码路径、根本原因、攻击条件和影响的发现才算通过。这个设置的目的是避免模型从CVE描述中"猜测"答案，而是真正测试模型在源码中定位漏洞的能力。
10个检测器，都不使用前沿模型
HoF-Bench的10个检测器骨干包括5个开放权重模型（总参数规模21B到284B，激活参数3B到13B）和5个专有小型或"闪速"级模型。所有模型在固定框架中运行，包含4次重复传递、可选的生成上下文阶段和可重复的多轮分类阶段。
在整个研究中，没有任何前沿模型（如GPT-5.6、Claude Opus等）直接参与检测。前沿模型只被用作评判者，来判断检测器的发现是否准确。
这个分工安排本身就是一种方法上的选择。检测环节需要跑很多次、扫很多文件，是成本的主要来源；评判环节只在有候选结果时触发，调用量小得多。把贵的模型放在低频环节，把便宜的模型放在高频环节，成本结构才有优化空间。
图：HoF-Bench收录的高影响开源项目与漏洞样本分布。
价格与效果：小模型更好
实验最引人注目的发现是成本效益分析。在严格的重新发现协议下，最便宜的配置（使用开放权重小模型）只需66美元，就找到了70个CVE（95个中的68%）。而GPT-5.6 luna配置需要128美元，只找到65个。
这一结果挑战了"挖漏洞必须用前沿模型"的直觉。精心配置的小模型组合，在漏洞检测任务上可以比单一的大模型更有效，同时成本更低。对于那些需要频繁扫描代码库的安全团队来说，这是一个实际的考虑——不是每次扫描都需要调用最贵的模型。
图：不同模型组合在重复检测轮次下的漏洞发现率。
C语言代码是共同的盲区
分析所有模型都未发现的CVE，发现它们高度集中在C基础设施代码中。这意味着，无论是开放权重模型还是专有小模型，在处理C语言的指针操作、内存管理、底层系统调用等复杂模式时，都存在系统性困难。
这一发现指出了LLM在安全分析中的一个明确能力边界：对于C语言中的内存安全漏洞，当前模型的理解能力仍然有限。
图：加入上下文前后，各模型漏洞召回率与调用成本的关系。
7600条模型-CVE传递记录
HoF-Bench的完整实验生成了7600条模型-CVE传递记录，覆盖了所有检测器在不同配置下的表现。这些数据为比较漏洞扫描器的可靠性提供了基础：哪些模型在重复运行中表现稳定，哪些模型的结果波动较大；哪些模型产生了大量候选，哪些模型更精准但候选量少。
候选量这个维度在实际使用中的权重比想象的更高。安全团队真正付出的成本，很大一部分是人工审核每条报告所花的时间。一个召回率略低但候选干净的扫描器，可能比一个召回率更高、误报也更多的扫描器更受欢迎——前者的人工负担是可控的。
图：不同模型和上下文设置在各代码库上的召回表现。
一个可复现的漏洞检测基础设施，正在走向落地
HoF-Bench的完整数据集和代码已在GitHub和Hugging Face上开源。它提供了一个紧凑的测试平台，用于比较不同漏洞扫描器的表现、评估重复运行的可靠性、以及分析候选量对后期人工审核的影响。
需要说明的是，HoF-Bench中的所有CVE均为公开数据，不能排除训练数据污染的可能性。如果模型在训练时已经见过这些CVE的修复补丁或讨论，那么基准的结果可能偏乐观。但论文中的严格协议——不提供任何描述、修复或标识符——在一定程度上缓解了这个问题。
参考资料
https://arxiv.org/abs/2607.27030
