HoF-Bench：无需前沿大模型，轻量级AI复现68%真实开源CVE

HoF-Bench: Rediscovering Real AI-Discovered CVEs Without Frontier Models

论文原文 ↗ 论文发布 2026-07-29 解读发布 2026-09-11 解读：AI前沿分享

用大模型自动挖掘现实系统漏洞，已经从理论验证走向了工业披露。安全机构 AISLE 开发的 AI 分析器此前在 OpenSSL、curl、GnuTLS 和 Apache httpd 等知名开源基础设施中挖掘出超过 280 个 CVE 漏洞。这类基础项目往往经历了数十年的代码审查、模糊测试（Fuzzing）以及传统静态分析（SAST）工具的洗礼，却仍然留有 AI 能察觉的隐秘缺陷。

ArXiv URL：https://arxiv.org/abs/2607.27030v1

然而，一个关键的工程与科学疑问随之浮现：这些曾经被 AI 找出来的真实安全漏洞，究竟需要多么庞大、昂贵的前沿模型（Frontier Models）才能复现？如果把代码范围圈定在出现漏洞的目标文件，市面上那些每百万输入 Token 仅需几美分的轻量级模型或开源稀疏混合专家（MoE）模型，是否同样具备挖掘 CVE 级别漏洞的能力？

来自 AISLE 与马萨里克大学的研究团队推出了全新基准 HoF-Bench（得名于 AISLE 的名人堂公开榜单），给出了一个出人意料的答案。在严格限定漏洞代码路径、根本原因、触发条件和安全影响四项要素必须完全匹配的前提下，完全不依赖任何前沿大模型，仅靠激活参数在 3B 到 13B 之间的开源模型或轻量专有模型，搭配极简扫描脚手架，就能重新找回多达 68%（65/95）的真实 CVE。这项研究不仅为衡量大语言模型在真实代码库中的静态分析能力提供了一个低门槛的测试床，更揭示出决定漏洞挖掘成败的关键并不在模型参数量，而在编程语言的语义复杂度与扫描系统的架构设计。

真实代码环境中的严格再发现协议

学术界以往的漏洞检测基准多基于代码片段、单个函数或人工合成用例，例如 Juliet 或 PrimeVul 等。这类评估方式虽然廉价且易于校验，却剥离了现实软件审计中最核心的上下文交互：跨文件的状态传递、依赖配置项的执行路径，以及只能在调用端辨识的信任边界。

HoF-Bench v1 则从真实软件仓库切入，选取了 8 个涵盖 C、PHP 和 JavaScript 的开源项目，锁定了 95 个已公开且被官方归因于 AI 挖掘的 CVE。为了让外部团队在单个下午就能跑完评估，基准采用了“固定提交”（Pinned Commit）设计——每个代码仓库只检出一个特定历史版本，分析器在运行时能够看到该版本完整的仓库文件，同时被显式分配 1 到 7 个目标文件作为分析焦点。

这种“给定源码目标范围”（Source-Conditioned）的设定相当于给模型提供了一个先验定位指引。目标文件代码中位数约为 911 行，直接打包送入分析器的提示词中。但在此之外，分析器对所有评估端信息一无所知：它接触不到 CVE 编号、漏洞官方描述、修复补丁提交记录或预期的漏洞代码片段。

为了防范大模型在安全报告中常用的“模糊话术”和碰巧猜中漏洞类别的作弊现象，评估系统引入了极其苛刻的盲审机制。评判端使用前沿模型充当裁判，在抹去检测器身份、轮次和环境参数的情况下，对生成的分析报告与 CVE 真实细节做逐项比对。分析器要想拿分，提交的报告必须同时满足四个维度的严格一致：精确命中相同的漏洞代码路径或组件、相同的根本成因、完全一致的攻击者控制条件或信任边界，以及同等的安全危害。单纯指明文件附近或说出类似“此处存在缓冲区溢出”等空泛分类，均被直接判定为未命中。

轻量级与开源模型的表现

在整个检测实验中，研究团队严格排除了参数量巨大且推理昂贵的前沿模型。进入评测面板的 10 款检测基座被划分为两类：

开源稀疏 MoE 模型：共 5 款，总参数量在 21B 到 284B 之间，但在推理时每个 Token 仅激活 3B 到 13B 参数，均采用宽松的开源协议。
商业轻量级模型：共 5 款，均属于云厂商的“Flash”或“Mini”级别轻量服务，输入 Token 价格在每百万 0.03 美元至 1.50 美元之间。

测试流程将每个检测模型置于固定的极简扫描脚手架中，历经 4 次独立重复扫描、可选的上下文生成阶段，以及多轮分类过滤（Triage），累计沉淀了 7,600 次模型与 CVE 的检测记录。

实验数据表明，轻量级模型完全具备穿透生产级代码的能力。在 4 轮重复扫描（pass@4）的合并视角下，10 个模型家族中有 6 个在 95 个真实 CVE 中找回了 50 个以上。表现最好的单模型达到了 65 个（68% 的严格召回率）。这意味着，发现真实世界开源项目中的深层漏洞，并不存在“非前沿大模型不可”的绝对技术壁垒；廉价算力在被合理组织的扫描流程中，已经能覆盖过半已被披露的复杂漏洞。

系统维度的收益取舍：重复扫描与多样性

虽然轻量模型的最终覆盖面令人瞩目，但单次运行的不可靠性依然非常明显。没有任何一个轻量模型能在单次扫描中直接达成上述召回率。

统计显示，单次扫描的平均召回率仅相当于 4 轮合并召回率的 68%。在所有成功复现漏洞的模型-漏洞组合中，有高达 62% 的案例仅在 4 次重复运行中的 1 到 3 次中被成功捕获。换言之，大模型分析器在代码审计场景下存在极大的随机性。将扫描轮次从 1 轮增加到 4 轮，不同模型能稳定多捡回 12 到 20 个真实 CVE。

更有价值的发现体现在模型多样性对单一重复的碾压优势。如果我们将 4 次扫描的预算分散给不同的轻量模型——例如让 GPT-5.6 luna、DeepSeek V4 Flash、GPT-5.4 mini 和 Gemini 3.5 Flash 各跑一次，其严格召回表现不仅超越了绝大多数模型自身的 4 次扫描总和，而且整体检出集显著扩大。不同模型在代码理解上的注意力分布和推理逻辑存在固有的盲区差异，这种盲区互补带来的增益，远远超过对着同一个模型反复摇号。

与重复扫描带来的显著增益相反，许多在直觉上被认为至关重要的系统层设计，在严谨评估下却收效甚微：

自动化上下文生成（Generated Context）：让模型在正式分析前通过仓库全局检索生成辅助调用上下文，虽然将全模型集体漏报的极端死角从 16 个缩减到了 11 个，但整体严格召回率仅仅微弱提升了 2.2 个百分点。与此同时，它导致去重后的漏洞候选簇从 1,664 个激增至 2,088 个，相当于让人工安全工程师每确认一个真漏洞需要额外排查近 20% 的候选告警。额外上下文引入的大量信息，往往在辅助了少量边缘 case 的同时，放大了误报噪音。
深层分类过滤（Triage Depth）：将最初的一轮过滤机制升级为三轮独立审查外加仲裁者裁决，对于最终严格判定的数量改变不足数个百分点，反倒大幅推高了 API 的调用开销。在漏洞挖掘系统中，多轮推演带来的额外清洗成本与其换来的准确度收益极不对称。

编程语言决定挖掘难度

当剖析各个漏洞的具体命中率时，HoF-Bench 呈现出了极强的结构性分化。模型的检出率高低，几乎不取决于模型的具体品牌，也不主要由 CVE 的 CWE 类型决定，而是受到目标代码所用编程语言的强力支配。

上图揭示了不同语言和仓库在检测难度上的巨大鸿沟。在 10 款轻量级模型的反复扫描下，各个语言的严格召回率呈现出断崖式分层：

JavaScript 项目：各模型的单模型召回率普遍落在 71% 至 100% 之间。
PHP 项目：召回率稳定在 50% 至 73% 之间。
C 语言项目：召回率直接骤降至 16% 至 62%，中位数仅为 31%。

在全量基准中，有 21 个漏洞被所有 10 款模型全部命中，而其中 18 个属于 JavaScript 或 PHP 编写的 Web 应用程序，如 OpenEMR 中的典型 SQL 注入缺陷。相反，在所有模型经过多次扫描依然集体交白卷的 11 个“硬核漏洞”中，有 9 个集中在 C 语言基础设施中（如 curl 涉及状态机流转的证书校验逻辑缺陷）。

这种差距即使在控制漏洞类别后依然不可撼动。以横跨三门语言的 37 个身份认证与权限绕过（Auth）漏洞为例，平均每个 JavaScript 漏洞能被 8.1 个模型找到，PHP 漏洞为 5.8 个，而 C 语言漏洞仅能被 3.0 个模型识别。

二项逻辑回归模型分析显示，编程语言所能解释的模型表现差异，是漏洞分类（CWE）解释度的两倍以上；代码目标文件的长度也展现出显著的负相关性（代码规模与检出率的 Spearman 相关系数达到 $\rho=-0.47$，而在 C 语言内部更是达到 $-0.53$）。这意味着，并非模型“不懂缓冲区溢出或逻辑分支”，而是面对 C 语言中那些高度依赖隐式内存布局、手动资源追踪、复杂前置状态约束以及庞大代码上下文的系统级交互时，轻量级模型的逻辑展开能力会被迅速消耗殆尽。

工业落地与自动化代码审计的边界

HoF-Bench 的实验结果重构了软件工程团队对 AI 辅助代码安全分析的固有认知。

它明确证实了利用廉价模型搭建实用级 SAST 分析器的可行性。以往企业往往受困于大参数前沿模型高昂的 Token 费用和有限的速率配额，难以为全量代码库落地持续审计；而实验证明，在极简的脚手架下，通过调度百亿参数量级的开源 MoE 或轻量商业接口，并保留 3 到 4 轮的并发抽样，就能在极低成本下捕获大量曾由顶级系统发现的高危漏洞。更重要的是，在严苛的分类过滤把关下，每抓取一个真实 CVE 平均只需要人工团队复核 3 到 4 个高置信度候选，完全处于可用区间。

然而，这也划定了当前轻量大模型静态审计的技术红线。以 curl 和 OpenSSL 为代表的底层 C/C++ 系统级基础设施，依然存在大量大模型无法穿透的语义迷雾。那些涉及复杂异步调用时序、宏展开状态隐藏以及多重指针漂移的漏洞，单靠纯文本层面的自回归推演很难被准确定位。

这表明，未来的 AI 漏洞挖掘体系不能寄希望于用一套通用的 Prompt 去通吃所有技术栈。面对高级系统软件，必须将大模型与确定性的控制流分析、符号执行和引导式模糊测试进行深度混合绑扎；而在业务层应用广泛的 Web 和脚本语言场景下，由多款异构轻量级模型构建的低成本多轮并发系统，已经足以充当随时待命的坚固第一道防线。