文章总结： 本文梳理LLM代码审计评测集，指出旧基准因数据泄漏严重高估模型能力，严格测试下SOTA模型表现接近随机。建议构建L0至L5的金字塔评测体系，强调使用时间切分防泄漏、报告PR-AUC与告警预算下的召回率，并结合PoC验证与成对一致性检测，将LLM作为静态分析辅助而非替代。 综合评分： 94 文章分类： 代码审计,AI安全,漏洞分析,安全工具,安全建设

LLM 代码审计：评测集与实验矩阵

原创

Purpleroc Purpleroc

Purpleroc的札记

2026年7月19日 15:30 广东

在小说阅读器读本章

去阅读

核心原则：函数二分类、语句定位、仓库级审计、漏洞验证和补丁修复是不同任务，分数不能横向混用。本文为Codex自动整理生成，希望对你有启发～

1. 关键评测集

| 评测集 | 年份 | 对象/粒度 | 规模与覆盖 | 典型验证 | 优点 | 主要风险/局限 | 证据 | | — | — | — | — | — | — | — | — | | Devign | 2019 | C/C++ 函数二分类 | FFmpeg、QEMU 等真实提交 | 标签分类 | 经典、易比较 | 老数据；函数上下文不足；重复和标签噪声 | B | | Big-Vul | 2020 | C/C++ 函数二分类/行定位 | 公开 CVE 修复提交，大规模 | 分类 F1、行定位 | 使用广、便于训练 | 自动挖掘标签噪声、重复、随机切分泄漏；类别分布常被人工平衡 | B | | ReVeal | 2020 | C/C++ 函数级 | Chromium、Debian 项目 | 分类指标 | 关注不平衡 | 项目和语言覆盖有限 | B | | DiverseVul | 2023 | C/C++ 函数级 | 18,945 个易受攻击函数，150 个项目、295 类 CWE（论文口径） | 分类 | 项目/CWE 多样性更好 | 仍以函数和提交推断标签为主 | B | | VulBench | 2024 | CTF + 真实漏洞，函数/片段 | 多来源漏洞样本 | 检出率、分类 | 同时含 CTF 与真实案例，适合测推理 | 规模较小；CTF 与生产漏洞分布不同 | B | | LLM4Vuln 数据 | 2024 | 智能合约漏洞推理 | 75 个 Code4rena 高风险真值；4,950 个受控场景 | 知识、上下文、推理因素消融 | 能解耦 RAG/上下文/模型推理 | 仅智能合约；75 个根样本 | A | | PrimeVul | 2024/ICSE 2025 | C/C++ 函数级、漏洞/修复对 | 约 7k 漏洞函数、229k 良性函数，140+ CWE | 时间切分、去重、paired、VD-Score | 真实不平衡、严格去重、时间切分；揭示旧基准虚高 | 仍以函数为主；C/C++；数据挖掘标签并非逐项人工验证 | A | | VulDetectBench | 2024 | 识别→分类→定位五级任务 | 公开基准；评测 17 个模型 | 五类递进任务准确率 | 不只测二分类，暴露深层定位能力 | 任务构造和自动判分仍可能简化现实 | A-/B+ | | CWE-Bench-Java | 2024/ICLR 2025 | Java 仓库级污点漏洞 | 120 个经人工核验的真实漏洞 | 已知 CVE、路径/报告验证 | 人工核验、可跑完整仓库、适合神经符号系统 | 规模小；集中在 Java 和污点类 CWE | A | | ReposVul | 2024 | 仓库级、多粒度 | 真实 CVE、代码上下文和修复 | 漏洞分类/定位 | 保留跨函数上下文 | 运行成本高，成对修复评估有限 | B+ | | VulEval | 2024/2025 | 仓库级 | 真实仓库漏洞 | 检出/定位 | 跨过程上下文 | 计算昂贵、覆盖与评测协议仍有限 | B | | JITVul | 2025 | 函数 + 引入/修复提交对 + 仓库上下文 | 879 CVE、91 类漏洞 | vulnerable/fixed pair，LLM vs ReAct agent | 成对样本能测模型是否理解细微修复；支持上下文检索实验 | 以已知 JIT 提交为中心；并非开放世界扫描 | A | | SecVulEval | 2025 | C/C++ 语句级 + 上下文 + 理由 | 25,440 函数、5,867 个唯一 CVE，1999–2024 | 漏洞语句且理由正确的 F1 | 细粒度、上下文丰富、规模大 | 仍从已知 CVE/函数出发；C/C++；自动/半自动标注误差需持续审计 | B+（预印本） | | CVE-Bench | 2025 | 仓库级漏洞修复 | 真实仓库/CVE、容器化任务 | 测试通过与补丁正确性 | 接近软件工程代理流程 | 修复能力不等于发现能力；测试完备性限制结论 | A | | SEC-bench | 2025 | 真实软件安全代理任务 | OSV/CVE 构建可复现实例 | PoC 生成、补丁、容器执行 | 以可执行结果而非文本判断；自动构建流水线 | 可稳定构建的 CVE 存在选择偏差 | A-/B+ | | VulnRepairEval | 2025 | Python 真实 CVE 修复 | 从 400+ CVE、约 2,500 来源筛到 23 个带工作 PoC 的 CVE | 原 PoC 必须失败、回归测试通过 | 验证严格、容器化、可审计 | 样本仅 23；Python；“通过 PoC”不代表完全修复 | B+ | | A.S.E / AICGSecEval | 2025 | 仓库级安全代码生成/修复 | 真实 CVE 仓库；29 CWE；多语言 | 容器、静态+动态、构建与稳定性 | 国内公开、工程约束真实、验证混合 | 更偏安全生成/修补而非未知漏洞发现 | B+ | | SecCodeBench V2 | 2026 | Agent 安全代码生成 | Python/Java/C/Go/JS；人工质量控制 | 分级 CWE、pass@1、加权安全分 | 关注污染、无效题、严重度与原生/安全提示模式 | 生成安全性不能替代审计检出评测 | B+ |

2. 关键实验结果（只在同任务内解释）

| 工作 | 实验设计 | 结果 | 正确解读 | | — | — | — | — | | PrimeVul | 相同方向的代码模型在 BigVul 与更严格 PrimeVul 上比较 | SOTA 7B 在 BigVul F1 68.26%，PrimeVul F1 3.09%；严格设置下 GPT-3.5/GPT-4 接近随机 | 旧函数级随机切分分数严重高估生产能力；真实类别不平衡时误报预算是核心约束 | | VulDetectBench | 17 个开闭源模型、五个递进任务 | 基础识别/分类可超过 80%，更具体的深层分析任务低于 30% | “知道有漏洞”与“定位并给出可执行证据”差距巨大 | | IRIS | CWE-Bench-Java；CodeQL 与 LLM+CodeQL 神经符号流程 | CodeQL 检出 27/120；IRIS+GPT-4 检出 55/120；平均 FDR 改善 5 个百分点；另发现 6 个未知漏洞 | LLM 最有价值的位置之一是补全静态分析规格和上下文判断，而非替代数据流引擎 | | RepoAudit | 15 个真实系统；路径敏感按需探索 + validator | Claude 3.5 Sonnet 发现 38 个真实 bug；平均每项目 0.44 小时、2.54 美元；项目方材料报告精度约 78.43% | 代理+记忆+验证器能以较低成本做仓库级分析；但样本项目少、目标 bug 类型和人工确认流程会影响外推 | | JITVul | 879 CVE 的引入/修复对；普通 LLM、CoT 与 ReAct agent | ReAct 使用跨过程上下文后优于单轮 LLM；两类方法仍会误判防护逻辑或前后不一致 | 工具化检索有效，但 agent loop 本身不保证正确；成对一致性应成为硬指标 | | SecVulEval | 语句定位且理由必须正确 | 最佳 Claude 3.7 Sonnet F1 23.83% | 语句级“定位+正确解释”仍远未达到全自动审计要求 | | LLM4Vuln | 75 个真漏洞 × 知识/上下文/提示组合 = 4,950 场景 | 结论强调正确漏洞知识和相关上下文显著影响推理，模型间差异并非唯一因素 | 平台需要知识、上下文检索和结构化输出的独立可测模块 | | 多语言 SVD 基准 | Python 8,260、Java 7,505、JavaScript 28,983 个漏洞函数；微调与集成 | 论文报告微调、平衡和集成可改善结果 | 应重点核验跨项目/时间切分；数据再平衡的高分不代表生产告警精度 | | SecVulEval/PrimeVul 共同结论 | 更严格标签、去重、时间切分、细粒度/真实分布 | 成绩显著低于旧基准 | 基准设计对结论的影响可能大于换一个模型 |

3. 建议的内部“金字塔评测”

| 层级 | 目的 | 样本 | 核心指标 | 放行门槛建议 | | — | — | — | — | — | | L0 单元能力 | 测 CWE 知识、source/sink/sanitizer 识别 | Juliet/SARD 小片段 + 自建对抗变体 | 分类、定位、结构化输出合法率 | 只用于回归，不作为生产效果宣传 | | L1 函数真实分布 | 测低基率下告警能力 | PrimeVul 时间切分、严格去重 | PR-AUC、precision@告警预算、VD-Score、paired accuracy | 先满足团队每日可处理告警量 | | L2 仓库已知漏洞 | 测跨文件/跨过程发现 | CWE-Bench-Java、JITVul、自建历史 CVE | CVE recall、路径完整率、误报/千行、成本/CVE | 与 CodeQL/Semgrep 等单独及联合基线比较 | | L3 可执行验证 | 测报告是否可证伪 | 带 PoC 的 CVE、SEC-bench/VulnRepairEval 风格容器 | PoC 成功率、复现率、非破坏性验证率 | 高危报告必须带可重放证据或强静态证明 | | L4 盲测生产回放 | 测真实价值 | 时间截断后的内部提交/漏洞；隐藏标签 | 首报命中率、漏报率、MTTT、人工分钟/真阳性、成本 | 双盲、禁止训练污染；至少跨 3 个语言栈 | | L5 在线运营 | 测持续价值 | 真实 PR/仓库 | 接受率、修复率、撤回率、复发率、SLA、token/扫描 | 灰度放量；高危自动阻断须有确定性验证 |

4. 指标规范

必须报告：

1. 1. 真实类别比例、时间范围、项目隔离和去重方法。
2. 2. Precision、Recall、F1、PR-AUC；不要只报 Accuracy。
3. 3. 每千行/每仓库误报、每日告警预算下的 recall。
4. 4. 漏洞级、路径级、文件级和语句级分别计分。
5. 5. 同一输入至少 3 次的稳定性与成对漏洞/修复一致性。
6. 6. token、金额、墙钟时间、工具调用数、失败/超时率。
7. 7. 报告可验证率：静态证明、测试、PoC、人工确认分别占比。
8. 8. 与纯 SAST、纯 LLM、混合系统、人工审计基线比较。

不应使用的“漂亮但危险”的指标：平衡测试集 Accuracy、随机函数切分 F1、只对已知漏洞位置提问后的命中率、LLM-as-judge 单一裁决、只展示成功案例。

5. 数据污染与标签审计清单

• • 按 CVE 公布时间和模型知识截止时间做时间外测试。
• • 训练/验证/测试按项目和提交谱系隔离，不只按函数随机拆分。
• • 对函数、修复前后版本、克隆/派生仓库做语法和语义去重。
• • 同时保留 vulnerable/fixed pair，模型必须一正一负且理由与 diff 一致。
• • 抽样人工复核自动挖掘标签，报告置信区间和标注者一致性。
• • 构造语义保持重写、死代码、变量改名和无关上下文干扰，检测记忆而非推理。
• • 自建隐藏集；公开集用于回归而非最终选型。

6. 主要来源

• • PrimeVul / ICSE 2025
• • VulDetectBench
• • IRIS / CWE-Bench-Java
• • RepoAudit
• • JITVul / ACL 2025
• • SecVulEval
• • LLM4Vuln
• • SEC-bench
• • VulnRepairEval
• • AICGSecEval
• • SecCodeBench

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Purpleroc的札记 Purpleroc Purpleroc《LLM 代码审计：评测集与实验矩阵》