开源 C 静态分析器的误报–漏报前沿：以匹配判据敏感性分析重测 Juliet 基准上的已发表评测结论

1 · 研究问题

已发表评测报告的开源 C/C++ 静态分析工具（Clang Static Analyzer、cppcheck、Infer、CodeChecker）在 Juliet 测试集上的精确率与召回率数字，对"工具告警与基准 manifest 的匹配判据"（严格同行 / ±k 行 / 同函数 / 同文件）有多敏感？改变匹配判据是否足以改变工具之间的排名，从而使既有的"哪个工具更好"的结论不成立？

2 · 研究背景与空白

技术背景。 静态应用安全测试（SAST）工具在不运行程序的前提下，用抽象解释、符号执行或模式匹配寻找缓冲区溢出、空指针解引用、未初始化变量等缺陷。评价这类工具需要"标注了缺陷位置的代码"，业界标准是 NIST 的 Juliet 测试集（隶属 SARD，Software Assurance Reference Dataset）：Juliet C/C++ 含约 64,099 个测试用例、分布在约十万个文件中，每个用例按 CWE 分类，且成对给出 bad（含缺陷）与 good（已修复）两个函数，并附 manifest 标明缺陷的精确文件与行号。评测时把工具告警与 manifest 比对：位置匹配算真阳性，其他算假阳性。这里的关键——也是本课题的切入点——是"位置匹配"这个判据本身没有统一定义：告警报在缺陷行的上一行算不算命中？报在同一函数的另一行算不算？不同论文的选择不同，而这个选择直接决定了最终数字。这类课题完全绕开算力墙：静态分析是 CPU 上的符号推理，慢在分析器本身而不在硬件，且 Juliet 的单个测试用例都是几十行的小文件。

已有工作到哪一步。 已有多项系统评测：一项研究以 manifest 的精确文件与行号为判据，报告 Clang Static Analyzer 精确率极高（约 87%）但召回率很低（约 9%），且其覆盖的 CWE 类别极少（对某些测试集只支持 CWE-457 未初始化变量）；cppcheck 呈现"高精确率、中等召回率"；cppcheck、CodeChecker 与 Infer 属于检出漏洞最少的一组；SonarQube 的假阳性数约为 CodeQL 的 2.7 倍。综述性结论是"C 语言不存在单一最优的开源 SAST 工具"。近期还出现了 CASTLE 基准（arXiv:2503.09433），专门为静态分析器与大语言模型的 CWE 检测比较构造新数据集。同时，Juliet 作为基准的局限已被指出：合成代码模式单一、易被模式匹配"猜中"。

空白在于：全部已发表评测都固定了一种匹配判据，没有任何工作把"匹配判据"本身当作自变量做敏感性分析，因此没人知道这些被广泛引用的精确率/召回率数字有多脆弱。这个空白属于"评价维度的转换"，可靠性高，而且它有一个别的方向少有的优势：Juliet 的 good/bad 配对结构提供了一个判据无关的强证据——工具在 good（已修复）函数上发出的告警必定是真误报，与行号匹配方式无关。用这个不可争议的子集做锚点，就能定量测出各种匹配判据引入的偏置。学生课题做这件事的门槛很低（全部是脚本与批处理），且结论正负都成立。

3 · 可检验假设

• H1：把匹配判据从"严格同行"放宽到"同函数"，各工具的召回率提升幅度显著不同（提升幅度的极差 ≥ 15 个百分点），且至少发生一次工具排名翻转（按 F1 或精确率-召回率前沿上的支配关系判定）。
• H2：在判据无关的 good 函数子集上测得的真误报率，与用严格同行判据算出的假阳性率之间存在系统性偏差，偏差方向对所有工具一致（即严格判据系统性高估误报），偏差中位数 ≥ 10 个百分点。若偏差方向不一致，说明匹配判据的影响是工具特异的，这对"跨论文引用精确率数字"是一个更强的警告——同样是有效结论。

4 · 量化验收标准

1. 方法学校验（硬门槛）：用自建评测管线，在与已发表研究相同的 Juliet 子集与相同的匹配判据（严格文件+行号）下，重现至少两个工具（Clang Static Analyzer 与 cppcheck）的精确率与召回率，与已发表数值的绝对偏差 ≤ 5 个百分点；工具版本、编译数据库生成方式、启用的检查器清单必须与原文一致（原文未写明处须列为不确定项并做双版本对照）。这一步不过关，后续全部结论无效。
2. 判据敏感性扫描：匹配判据至少 5 档（严格同行 / ±2 行 / ±5 行 / 同函数 / 同文件），每档给出全部工具的精确率、召回率、F1 与前沿图；每档的差异必须给自助法（≥ 2000 次重采样，按测试用例重采样而非按告警重采样）95% 置信区间。
3. 分层报告：结果必须按 CWE 类别分层报告，不得只给汇总数字。理由写进正文：Juliet 各 CWE 的用例数量极不均衡，汇总数字实际上由用例最多的几类主导。同时报告每个工具"完全不支持"的 CWE 类别清单——覆盖面差异是排名的主要来源之一。
4. 不平衡口径：缺陷检测是极不平衡问题（Juliet 的 good/bad 配对使正负比例接近 1:1，但真实代码远非如此）。因此同时报告两套数字：Juliet 原生配对下的精确率/召回率，以及按 1:20、1:100 的正负比重采样后的 PR-AUC。明确写明不报 accuracy 及原因（配对结构下全部答"无缺陷"即可得 50%）。
5. 运行成本记录：记录每个工具在完整 Juliet 上的墙钟时间、峰值内存与超时/崩溃用例数（这也是从业者的实际选型依据），报中位数与 IQR，重复 ≥ 5 次。
6. 可复现性：全部批处理脚本、告警解析器（各工具输出格式不同，需统一为 SARIF 或自定义 JSON）、匹配判据实现、原始告警数据与统计脚本开源；一键重跑脚本；工具版本用容器镜像或明确的版本号锁定。

5 · 数据与工具

用途	来源 / 工具
基准数据集	NIST Juliet Test Suite for C/C++（v1.3，从 NIST SARD 站点 samate.nist.gov 免费下载，约 64,099 个用例 / 十万级文件 / 解压后数 GB），含 manifest.xml 标注缺陷位置与 CWE 编号。仅用于校验与对比，不计入本项目的数据贡献
补充基准	CASTLE 基准（arXiv:2503.09433 附带数据，开源许可与获取方式需核实）可作为第二数据集验证结论的可迁移性
静态分析器	Clang Static Analyzer（LLVM 官方，scan-build 或 clang --analyze，apt/brew 可装）；cppcheck（开源，含 --enable=all）；Infer（Meta 开源，二进制发行版）；CodeChecker（Ericsson 开源，Clang SA/tidy 的驱动与结果管理，可直接产出 SARIF）。全部为他人工具，标注为对照基准
编译数据库	bear 或 CMake 的 CMAKE_EXPORT_COMPILE_COMMANDS 生成 compile_commands.json（Juliet 的构建方式非标准，需核实是否需自行编写编译数据库生成脚本，这是本课题的已知工程难点）
告警格式统一	SARIF（OASIS 标准，Clang/CodeChecker 原生支持；cppcheck 有 XML 需自行转换；Infer 输出 JSON 需自行转换）——转换器需自行实现，须用人工核对的样本验证
统计与作图	Python + SciPy + scikit-learn（PR-AUC）+ Matplotlib
算力	纯 CPU。瓶颈是 I/O 与分析器本身：完整 Juliet 上 cppcheck 约数十分钟至数小时、Clang SA 与 Infer 可能达十余小时（具体数字需在第 1 阶段实测并记录，不得凭估计）。磁盘需 ≥ 30 GB 空闲。全部可夜间批跑，超出范围：需要构建整个真实开源项目（如 Linux 内核）的评测不在本课题范围内

6 · 方法路径

1. 装齐四个分析器与 Juliet，跑通每个工具在 10 个手挑用例上的分析，人工核对告警位置与 manifest，确认解析器无误；实测并记录各工具的完整运行成本。
2. 解决编译数据库问题（本课题的第一道工程关卡）：为 Juliet 的目录结构编写批量编译数据库生成脚本，并核实 Clang SA 与 Infer 是否能正确处理 Juliet 中的 #ifdef 变体（Juliet 用宏切换 good/bad 路径，若处理不当会系统性影响所有结果，必须在此步核实清楚）。
3. 实现统一的告警解析与 SARIF 转换，并用至少 50 条人工标注的告警验证转换正确性（给出明确、可复现的核对判据与核对记录）。
4. 完成方法学校验（验收第 1 条）：在严格同行判据下重现两个工具的已发表数字并归档差异分析。
5. 实现 5 档匹配判据并执行敏感性扫描，按 CWE 分层输出精确率/召回率/F1 与前沿图，全部带自助法置信区间。
6. 构造判据无关的锚点分析：只统计 good 函数上的告警（必为真误报），据此定量给出各判据的偏置方向与幅度，检验 H2。
7. 独立交叉校验：在 CASTLE 或 SARD 的另一子集上重跑判据敏感性扫描，验证结论是否跨数据集成立；并对随机抽取的 100 条告警做人工判读，给出"自动匹配 vs 人工判读"的一致率（Cohen's κ），量化自动评测本身的可靠性上界。

7 · 新颖性边界

本课题不声称：不开发新的静态分析器，不改进任何工具的算法，不声称哪个工具"最好"，不构造新的漏洞基准。Juliet、SARD、CASTLE 与全部四个分析器均为他人工作，明确标注为对照基准，不计入本项目贡献。

已有工作完成了什么：多项系统评测已在固定匹配判据下给出各工具在 Juliet 上的精确率/召回率，包括 Clang SA 精确率约 87%、召回率约 9%，cppcheck 高精确率中等召回，Infer/cppcheck/CodeChecker 检出数最少，SonarQube 误报数约为 CodeQL 的 2.7 倍，以及"C 语言无单一最优开源 SAST 工具"这一综述结论；CASTLE（2025）构造了新的 CWE 检测基准。这些数字本项目直接引用，不重复声称为发现。

本项目的贡献：把匹配判据本身作为自变量，测量既有精确率/召回率数字对它的敏感性，并用 Juliet 的 good/bad 配对结构构造一个判据无关的锚点来定量各判据的偏置。主结论是"这些被广泛引用的评测数字有多可信、排名是否稳健"，而不是任何新工具或新数据。

为什么有价值：静态分析工具的选型在工业界直接依赖这些公开数字。如果排名会随一个从未被讨论的方法学选择而翻转，那么整类评测都需要在报告结果时同时报告判据敏感性——这是一个可以立刻被后续研究采纳的方法学建议。

风险提示：若各判据下排名完全稳定，"结论稳健"同样是有价值的正面结论（它为既有文献提供了一次方法学背书），但必须给出置信区间证明本实验有能力分辨题设中 15 个百分点这一量级的差异。

8 · 决策门槛（go / no-go）

• 第 6 周：编译数据库与 #ifdef 处理必须核实完毕——这是需要提前确认而非边做边发现的头号风险项。若 Clang SA / Infer 无法正确分析 Juliet 的宏变体结构，降级路径 A：把 Juliet 用例预处理为"每个用例只保留 bad 或 good 一个变体"的展开版本（脚本可实现），并在正文声明该预处理及其对可比性的影响。主结论框架不变。
• 第 10 周：方法学校验硬门槛。若两个工具的精确率/召回率与文献偏差 > 5 个百分点，先排查工具版本、检查器启用清单、Juliet 版本三项；到第 13 周仍不过关则降级路径 B：放弃与外部文献的绝对数值对照，改为内部一致性校验——用人工标注的 200 条告警金标准（学生自建，须双人独立标注并报 κ）作为校验锚点，硬门槛替换为"自动管线与人工金标准的一致率 ≥ 90%"。主结论（判据敏感性）完全保留。
• 第 16 周：工具集必须锁定。若 Infer 或 CodeChecker 安装/运行失败，降级路径 C：工具集缩为 Clang SA + cppcheck + clang-tidy（三者均随 LLVM 发行，安装最稳），下限为 3 个工具——少于 3 个则"排名翻转"这一核心命题无从检验，此时须整体改投 K03。
• 第 30 周：判据敏感性扫描完成且 H1 有明确判定。若运行成本超预算（分析器跑不完），降级路径 D：把 Juliet 按 CWE 分层抽样为 30% 子集（分层抽样脚本与种子公开），保证每个 CWE 类别的用例数下限；抽样对精确率/召回率的估计误差用自助法量化并在正文报告。
• 预算裁剪顺序：补充数据集（CASTLE）→ 工具数量（下限 3）→ Juliet 抽样比例（下限 30%）→ （绝不裁剪）匹配判据档数与人工核对样本量。
• 选择前提：适合耐心好、擅长脚本与数据清洗、能忍受"大部分时间在处理格式与构建系统"的学生。本路线的科学内容清晰但工程杂活多，不适合期待算法推导的学生。

---