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. 指标规范
必须报告：
-
- 真实类别比例、时间范围、项目隔离和去重方法。
-
- Precision、Recall、F1、PR-AUC；不要只报 Accuracy。
-
- 每千行/每仓库误报、每日告警预算下的 recall。
-
- 漏洞级、路径级、文件级和语句级分别计分。
-
- 同一输入至少 3 次的稳定性与成对漏洞/修复一致性。
-
- token、金额、墙钟时间、工具调用数、失败/超时率。
-
- 报告可验证率：静态证明、测试、PoC、人工确认分别占比。
-
- 与纯 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
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论