HoF-Bench：不用前沿模型重新发现 AI 发现的真实 CVE

核心问题：一个 LLM 漏洞分析器发现过某个 CVE 之后，另一个（更便宜的）分析器能否仅从漏洞版本源码再次找到它——现有基准不直接测这一点。

• 场景与动机：作者称 AISLE 的 LLM 分析器已在 OpenSSL、curl、GnuTLS 等经过多年人工评审、fuzzing 和商业静态分析的项目中发现 280 余个 CVE（截至 2026 年 7 月 Hall of Fame 列出 287 个、覆盖 78 个项目），由此引出"能否被再次发现"的评测问题。
• 现有基准的不足：作者称许多安全基准测的是片段分类、补丁生成、漏洞利用复现或人造漏洞应用，不直接衡量扫描器报告是否能在真实复杂软件中认出 CVE 级的 bug。
• 论文提出什么：HoF-Bench v1——95 个公开 AI 发现 CVE、8 个固定在漏洞 commit 的仓库；任务是 source-conditioned 的（提供目标文件，测分析与重发现，而非全仓库自主定位）；另配一个严格的红iscovery 协议和一项 10 个检测模型的对照研究。
• 任务设定（非威胁模型）：扫描器获得仓库源码和 1–7 个目标文件的范围，但得不到 CVE 编号、描述、修复 commit 或预期漏洞片段；评分要求严格的漏洞同一性（同一代码路径、根因、攻击条件、影响），仅靠文件邻近或漏洞类别不得分。
• 量化问题：非前沿 LLM 分析器能重新发现这批 CVE 的多大比例，以及哪些系统选择（重复扫描、生成上下文、triage 深度、模型组合）影响结果。

片段/函数级基准

• Devign（2019）、Big-Vul（2020）、PrimeVul（2025）——聚焦函数或代码变更级别的漏洞检测；Juliet（2012）提供合成测试用例；SARD（2025）覆盖从合成程序到生产应用。
• Snyk VulnBench JS 1.0（2026）——在 10 个小型 JavaScript 夹具上测 LLM 评审的可重复性，对照一个 SAST 工具自己的参考发现。作者称这类目标使评测便宜、可检查，但很少要求生产代码中评审真正追查的证据（跨文件状态、配置、调用侧才可见的信任边界）。

仓库级基准

• RepoPairBench（论文引为 DREA，2026）——100 个 Python 漏洞/修复对，检查模型理由是否匹配文档记录的机制；JITVul（2025）——将函数关联到引入与修复 commit，覆盖 879 个 CVE。
• RealVuln（2026）——在 26 个人造漏洞 Python 仓库上比较规则 SAST、通用 LLM 和安全专用扫描器；BountyBench 与 SEC-bench（均 2025）——延伸到漏洞利用、PoC 生成和修补等生命周期阶段。

普查式工作

• Berkeley Vulnerability Initiative 的 Agentic Vulnerability Coverage Map（Villa 等，2026）——每日多厂商普查 agentic 系统被归因的 CVE。作者称普查回答"agentic 系统在野外发现了什么"，HoF-Bench 回答"给定扫描器能否再次找到固定集合"，两者问题不同。

基线与对比设置：论文未将外部工具作为基线跑分；对照是在同一参考扫描器脚手架内替换 10 个检测模型（Table 1），并比较重复 pass、context 开/关、triage 深度等条件。

本文定位：作者称 HoF-Bench 处于片段分类与完整漏洞利用之间的空档：修复前的生产快照、只对严格 CVE 同一性给分、重复 pass 使可靠性可测；且上述仓库级基准均为单语言，HoF-Bench 跨 C、PHP、JavaScript 三种语言。

整体思路：把"能否再次找到同一个 CVE"做成一个可复跑的基准 HoF-Bench，再用一个刻意最小化的参考扫描器（源自 AISLE 已开源的 nano-analyzer）作为固定仪器，只换检测模型和评测条件。

基准构建

• 选题来源：从 AISLE 公开 Hall of Fame 归因的 CVE 中，选取至少有 5 个披露且能落到同一漏洞快照的仓库；无法关联到仓库、无法在共同 commit 验证或需要不同快照的记录被排除。
• 规模与构成：95 个 CVE、8 个仓库（OpenSSL、curl、GnuTLS、Apache httpd、pearweb、FOGProject、OpenEMR、WeKan），每仓库一个扫描 commit；31 个多文件案例；覆盖 39 个 CWE，最多的是 CWE-79（9 例）、CWE-89（8）、CWE-863（8）、CWE-284（7）、CWE-476（6）。
• 字段分离：scanner-visible（任务 ID、仓库、commit、语言、目标文件、scope mode）与 evaluator-only（CVE ID、预期路径、行范围、机制、影响、代码片段、CWE/严重性、修复元数据）分开；清单对 ground truth 做了泄漏测试（附录 A，Table 4）。

任务定义

• 输入：整个仓库的固定 commit + 1–7 个目标文件（由 ground truth 导出、含主漏洞文件，作者称其为 substantial localization oracle）；目标文件中位数 911 行，受 300,000 字符上限截断。
• 不提供给扫描器：CVE 编号、漏洞描述、修复 commit、预期漏洞片段。
• 主要结果：strict rediscovery——发现必须命中同一漏洞代码路径/组件、根因、攻击者可控条件或信任边界、安全影响四个维度。

参考扫描器流程

• 三个阶段：可选的 context 构建（生成安全简报：组件用途、外部可达入口、信任边界、安全相关数据/控制流，可请求至多 3 次窄范围仓库搜索）→ 检测（输出结构化候选发现）→ 怀疑式 triage（3 个顺序评审轮 + 1 个 arbiter，arbiter 看发现、源码和全部评审后基于代码证据做最终 valid/invalid 判定，而非计票）。
• 约束：每 pass 最多 5 个原始发现，结构化输出重试有界；每轮 triage 判定都落盘，使更浅的 triage 策略可回放。
• 定位：作者称脚手架是受控比较工具，不作为贡献主张；外部工具（SAST 或 agentic）也可对 8 个快照跑并用同一评审打分。

评测协议

• 运行规模：每模型对 95 个 CVE 跑 4 次重复 pass，context 开/关两档，共 7,600 条 pass 记录。
• 评审：固定自动化 LLM 评审（GPT-5.6 terra，仅作评审、从不在检测环节使用前沿模型），看到 ground truth 但对检测器身份、context 条件和 pass 编号盲；输出 match / partial / no match / insufficient evidence 四档。
• 指标：主指标为 strict recall；success@k 定义为随机 k 个 pass 子集中至少发现一次的期望 CVE 数，对全部子集取平均以避免 pass 顺序依赖；pass@4 为四个 pass 的并集。因每个任务都是正例且未匹配发现未独立标注，作者强调这只是 recall 指标，不把未匹配发现称为假阳性。
• 评审负担估计：对 triage 后的发现按"同一评审可执行问题"做语义去重（确定性相似规则 + LLM 评审裁决模糊对），按模型和 context 条件分别统计去重簇数除以严格重发现 CVE 数。

实验设置

• 被测模型：10 个检测骨干，5 个开放权重 MoE（GPT-OSS 20B、GPT-OSS 120B、DeepSeek V4 Flash、Qwen 3.6 35B A3B、Mistral Small 4；总参数 21B–284B、激活 3–13B）和 5 个专有 small/flash 档（GPT-5.4 nano、Gemini 2.5 Flash、GPT-5.4 mini、GPT-5.6 luna、Gemini 3.5 Flash；尺寸未披露），输入价 $0.03–$1.50/百万 token（Table 1）。
• 基准：HoF-Bench v1，95 个 CVE、8 个仓库、三种语言（C 45、PHP 26、JavaScript 24）。
• 评审：GPT-5.6 terra 作为盲评审（对检测器身份、context、pass 编号盲），四档判定；strict match 才计入主指标。
• 指标：strict recall / pass@4（95 个 CVE 上）、success@k、每个重发现 CVE 的去重发现簇数；Wilson 95% 区间仅作描述。
• 运行量：7,600 条 pass 记录（95 × 10 × 2 × 4）；triage 深度变体通过回放已存评审判定评估，不重跑。
• 重复次数：每模型每条件 4 次 pass；论文未报告评审判定的人工一致性审计。

主结果

据 Table 2（pass@4 严格重发现数，满分 95；"Best result"列为最佳百分比及 95% Wilson 区间）：

表格较宽，可左右滑动

模型	Ctx	No ctx	Best result
GPT-5.6 luna	65	65	68.4% (58.5–76.9)
DeepSeek V4 Flash	62	56	65.3% (55.3–74.1)
GPT-5.4 mini	58	57	61.1% (51.0–70.2)
Gemini 3.5 Flash	56	53	58.9% (48.9–68.3)
GPT-OSS 120B	52	48	54.7% (44.7–64.4)
Qwen 3.6 35B A3B	50	49	52.6% (42.7–62.4)
GPT-5.4 nano	46	47	49.5% (39.6–59.4)
Gemini 2.5 Flash	47	42	49.5% (39.6–59.4)
GPT-OSS 20B	40	40	42.1% (32.7–52.2)
Mistral Small 4	38	36	40.0% (30.7–50.1)

• 作者解读：6 个模型在某一四 pass 条件下达到至少 50 个 CVE；从 1 个 pass 到 4 个 pass 平均每模型多发现约 12–20 个 CVE；单次 pass 平均只恢复四 pass 所覆盖 CVE 的 68%。
• 不稳定性：两种 context 条件下，62% 的成功模型–CVE–条件单元只在 4 次相同 pass 中的 1–3 次被发现（Figure 3 给出 success@k 曲线）。

模型多样性与组合

• 测了什么：把同样 4 次 pass 分给不同模型，与单模型重复比较。
• 结果：四个领先模型各取 1 个 pass 的组合期望覆盖 68 个 CVE（Table 2 portfolio 行，对 256 种组合取平均，作者标注为探索性分析），高于最强单模型 GPT-5.6 luna 四 pass 的 65；全部 40 次 context 运行的并集达 84/95（两种条件合计 85）；12 次 pass 分给三个便宜模型以 $66 找到 70 个 CVE，对比四次 GPT-5.6 luna pass 的 65 个、$128。
• 作者解读：不同模型发现不同的 bug，盲区只部分重叠，多样性优于重复。

context 与 triage 深度的影响

• context：pass@4 下有 context 的严格重发现为 514/950 个模型–CVE 单元（54.1%），无 context 为 493/950（51.9%）；配对差 +21/950（2.2 个百分点，CVE-bootstrap 95% 区间 [−6, 47]）；被所有模型漏掉的 CVE 从 16 降到 11，但去重后发现数从 1,664 升到 2,088，平均每个重发现 CVE 的发现数从 3.4 升到 4.1。作者称大部分新增发现只增加评审工作量。
• triage 深度：从单轮评审改为三轮加 arbiter，重发现的模型–CVE 结果总数仅从 974 变到 1,007；回放中 645 个被完整协议拒绝的"模拟幸存"发现经同一盲评审补判，70 个 strict match、28 个 partial（附录 B）。作者列出两点保留：后轮评审是在看到前轮内容后生成的，且未为两轮规则模拟 arbiter，回放估计的是已记录评审的过滤行为而非完整反事实重跑。

语言与难度结构

• 按语言（Table 3，context 条件）：JavaScript 24 个 CVE 的中位模型召回 81%、最佳 100%、0 个被所有模型漏掉；PHP 26 个中位 63%、最佳 73%、2 个全漏；C 45 个中位 31%、最佳 62%、9 个全漏。有 context 时 21 个 CVE 被所有模型发现、11 个无一发现（无 context 为 22 和 16）；21 个全中发现里 18 个是 JavaScript 或 PHP，11 个全漏里 9 个是 C。
• 类内对照：37 个授权/认证类 CVE（唯一跨三种语言的大类）中，平均每个 JavaScript CVE 被 8.1 个模型发现、PHP 5.8、C 3.0；二项回归中语言解释的偏差是漏洞类别的两倍以上；源码规模独立预测难度（总体 ρ = −0.47，C 内部 −0.53）。
• 作者解读：作者认为大型、有状态的 C 基础设施代码与漏洞机制无关地更难；并明确说原因只能推测——JavaScript/PHP 的信任边界通常在目标文件内可见，而 C 案例依赖跨多次调用组装的状态，证据常在检测器视野之外。

其他消融与分析

• 可靠性模型（附录 C，Table 5）：Rasch Beta-Binomial 为优选模型；Beta-Binomial 变体比二项变体 ELPD 好 100 以上，2PL 判别参数无增益（∆ELPD = 5.6，dSE = 6.3）。
• 分析器强度排序（Figure 5）：Rasch logit 尺度上 GPT-5.6 luna（无 context）最高，Mistral Small（无 context）最低，区间为 95% 可信区间。
• 成本–重发现（Figure 6）：按每基准 CVE 的归属 API 成本（对数轴）对 pass@4 严格重发现作图，作者称 context 通常增加的成本超过其带来的召回，且注明这是实验性记账视角而非生产定价主张。
• 失败案例：作者称共同漏掉的包括 curl 的证书验证状态 bug，全中发现的包括一个 OpenEMR SQL 注入。

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

• 来源与任务条件（Discussion）：HoF-Bench 是 AISLE-conditioned 且 source-conditioned，8 个仓库不代表所有软件；它采样的是 Villa 等普查的 agentic-CVE 总体中单一厂商的一片，作者建议读者对照该普查判断代表性。
• 只测 recall（Discussion）：每个任务都是正例且提供由 ground truth 导出的目标文件，研究估计的是目标条件下的 recall，不是全仓库定位、精度或假阳性率；未匹配发现是未验证，不是假阳性。
• 单一脚手架（Discussion）：10 个检测骨干共享同一脚手架、提示词族、triage 设计和评审，结果应视为同一分析器的 10 种配置，不是 10 个独立产品的比较。
• 污染与评审可靠性（Discussion）：CVE 已公开，训练数据污染无法排除；评审和语义去重是自动化的、未经人工审计；评审模型与多个检测器同厂商家族，盲评不能排除同族评分偏好。
• 跨任务语义指派（§4.3）：当前实现不做跨任务语义指派，作者将其列为局限。
• 后续方向（Discussion）：作者认为基准适合未来做微调实验（原始轨迹含提示词、回复、发现和评审标签），同时指出微调可能降低方差和 schema 失败，也可能让模型过拟合提示词风格或评审偏好。

实验覆盖范围

• 被测检测模型为 10 个（5 个开放权重 MoE、5 个专有 flash 档），评审模型为 GPT-5.6 terra；前沿模型不在检测环节使用。
• 基准覆盖 8 个仓库、95 个 CVE、C/PHP/JavaScript 三种语言；每模型每条件 4 次 pass，共 7,600 条 pass 记录。
• 流程变量评测包括 context 开/关两档和 triage 深度（单轮 vs 三轮加 arbiter，经回放评估）；模型组合分析为探索性。
• 论文未报告评审判定与人工评审的一致性，也未报告对评审提示词的敏感性测试。
• 论文讨论了传统 SAST 与 agentic 工具作为外部工具接入同一评审的用法，但本文实验未运行这类外部工具。

一篇基准论文：作者从 AISLE 公开 Hall of Fame 归因的 CVE 中构建 HoF-Bench v1，回答"一个 LLM 分析器发现过的真实 CVE，另一个不带前沿模型的分析器能否从漏洞版本源码再次找到"。

• 问题：现有漏洞基准多测片段分类、补丁或人造漏洞，不直接衡量扫描器在真实仓库快照中认出 CVE 级漏洞的能力。
• 方法：95 个 CVE 固定在 8 个仓库（OpenSSL、curl、GnuTLS、Apache httpd、pearweb、FOGProject、OpenEMR、WeKan）的漏洞 commit；扫描器只见源码和 1–7 个目标文件，不见 CVE 编号、描述或修复；GPT-5.6 terra 作盲评审，按代码路径、根因、攻击条件、影响四维度判 strict match；10 个非前沿检测模型（5 开放权重 MoE + 5 专有 flash 档）在固定脚手架下各跑 4 pass × context 两档，共 7,600 条记录。
• 主要结果：最高 pass@4 严格重发现为 GPT-5.6 luna 的 65/95（有/无 context 均同，Table 2）；6 个模型在某一条件下达到至少 50 个；从 1 到 4 个 pass 平均多发现约 12–20 个 CVE；四模型各一 pass 的组合期望覆盖 68 个，超过最强单模型的 65；context 只把 950 个单元中的重发现从 493 提到 514，同时去重发现数从 1,664 升到 2,088；triage 从单轮加到三轮加 arbiter 仅把重发现结果从 974 变到 1,007。
• 难度结构：有 context 时 21 个 CVE 被所有模型发现、11 个无一发现；11 个全漏中 9 个是 C，C 语言中位召回 31%（Table 3）；语言在回归中解释的偏差是漏洞类别的两倍以上。
• 作者结论：作者认为漏洞发现是系统问题而非单次模型调用，扫描器评测应报告多次运行的累计结果和送审发现量；剩余空间集中在大型有状态的 C 基础设施代码，原因作者称只能推测。
• 边界：作者强调这是厂商构建的基准（全部作者隶属 AISLE），只测目标条件下的 recall，评审未经人工审计，已公开数据、清单和原始运行记录以供独立审计。