Vulnerability Detection with Interprocedural Context in Multiple Languages: Assessing Effectiveness and Cost of Modern LLMs

这是一份关于论文《Vulnerability Detection with Interprocedural Context in Multiple Languages: Assessing Effectiveness and Cost of Modern LLMs》（多语言中基于过程间上下文的漏洞检测：评估现代大语言模型的有效性与成本）的详细技术总结。

1. 研究背景与问题 (Problem)

• 现有研究的局限性：尽管大语言模型（LLM）在自动化漏洞检测方面展现出潜力，但大多数先前的研究仅关注单函数（Single-function）内的漏洞检测。这些研究忽略了过程间依赖（Interprocedural dependencies），即那些跨越多个函数的数据流和控制流引发的漏洞（如空指针解引用、由调用者参数引发的注入漏洞等）。
• 多语言与成本缺失：现有研究通常针对单一编程语言，忽视了现代软件开发中语言异构性的影响。此外，缺乏对 LLM 推理经济成本（Economic cost）和解释性（Explainability）的深入评估。
• 核心问题：
  1. 提供过程间上下文（调用者 Caller 或被调用者 Callee 的代码）是否能提高 LLM 检测漏洞的准确性？
  2. 不同编程语言（C, C++, Python）如何影响模型的有效性？
  3. 增加上下文带来的 Token 消耗增加是否带来了相应的性能提升（成本效益如何）？
  4. LLM 生成的漏洞解释是否准确且完整？

2. 方法论 (Methodology)

• 数据集：
  • 基于 ReposVul 数据集，从中筛选出 509 个 涉及过程间依赖的漏洞实例。
  • 涵盖三种语言：C, C++, Python。
  • 数据经过两阶段过滤：保留包含至少一个漏洞函数的条目，并利用抽象语法树（AST）构建调用者 - 被调用者关系。
• 评估模型：
  • 选取了四个现代 LLM：Claude Haiku 4.5, GPT-4.1 Mini, GPT-5 Mini, Gemini 3 Flash。
  • 选择标准：支持长上下文输入，且代表不同成本 - 性能特征。
• 实验设计（上下文配置）：
  针对每个目标函数，设计了三种输入配置进行对比：
  1. **Code Only **(CO)：仅提供目标函数代码。
  2. **Code + Callees **(CC)：目标函数 + 其直接调用的函数代码。
  3. **Code + Callers **(CK)：目标函数 + 直接调用它的函数代码。
• 评估指标：
  • 有效性：准确率（Accuracy）、F1 分数（由于数据集仅包含漏洞函数，准确率等同于召回率 Recall）。
  • 成本：基于官方 Token 定价计算的推理成本（USD）。
  • 解释质量：人工评估（RQ4），从正确性（Correctness）和全面性（Comprehensiveness）两个维度打分（0-2 分）。
  • 统计检验：使用 McNemar 检验和 Holm-Bonferroni 校正来评估不同上下文配置间的差异显著性。

3. 关键贡献 (Key Contributions)

1. 过程间上下文的实证评估：首次系统性地量化了过程间上下文（Caller/Callee）对多语言 LLM 漏洞检测性能的影响，挑战了“上下文越多越好”的假设。
2. 多语言与成本效益分析：在 C、C++、Python 三种语言上评估了模型表现，并首次将推理成本与检测性能结合，绘制了成本 - 性能权衡曲线。
3. 解释性质量评估：不仅关注分类结果，还通过人工评估量化了模型生成漏洞解释的准确性和完整性，揭示了检测能力与解释能力之间的耦合关系。
4. 开源复现包：提供了包含代码、数据、提示词模板和可视化仪表板的完整复现包。

4. 主要结果 (Results)

4.1 上下文对有效性的影响 (RQ1 & RQ2)

• 反直觉发现：增加过程间上下文并未 consistently 提高检测效果，反而在多种情况下显著降低了性能。
• 模型差异：
  • Claude Haiku 4.5 和 Gemini 3 Flash：对上下文变化具有鲁棒性，性能在不同配置下保持稳定（甚至 CO 配置下表现最佳）。
  • GPT 系列（特别是 GPT-4.1 Mini）：对上下文非常敏感。在 C 语言中，添加被调用者（CC）上下文导致 GPT-4.1 Mini 准确率从 75.6% 暴跌至 54.0%（下降约 25 个百分点）；添加调用者（CK）也导致显著下降。
• 语言差异：
  • C 语言：GPT 模型在增加上下文后性能显著下降，表明额外的上下文可能引入了噪声，干扰了模型推理。
  • Python：趋势类似但统计上不显著，可能因为 Python 函数封装性更好，过程间耦合较低。
  • C++：由于样本量过小（过滤后仅个位数），无法进行可靠的统计分析。

4.2 成本与效率 (RQ3)

• Token 消耗翻倍：添加过程间上下文（CC 或 CK）使 C 语言的 Prompt Token 数量几乎翻倍（从平均 2367 增至约 4785），导致推理成本相应增加。
• 性价比之王：
  • Gemini 3 Flash：提供了最佳的成本 - 性能平衡。在 C 语言中，以约 $0.50-$0.58/配置 的成本实现了 F1 ≥ 0.978 的高分。
  • Claude Haiku 4.5：检测性能略高，但成本是 Gemini 的两倍以上（约 $1.19-$1.38）。
  • GPT-4.1 Mini：虽然绝对成本最低（$0.19-$0.22），但在 C 语言中因性能大幅下降，整体性价比低。
• 结论：增加上下文并未带来成比例的性能提升，反而增加了成本。

4.3 解释质量 (RQ4)

• 整体表现：所有模型在解释质量上表现良好（平均分 > 1.83/2.0）。
• 最佳解释者：Claude Haiku 4.5 在解释的正确性和全面性上均领先，93.6% 的评估获得了满分（2,2）。
• GPT 模型的问题：GPT-4.1 Mini 和 GPT-5 Mini 的“零分”率（完全错误的解释）较高（6.1%-6.8%），而 Claude 和 Gemini 低于 1.2%。
• 耦合性：检测能力较差的模型（如 GPT 系列），其生成的解释质量也往往较差，表明内部推理的一致性决定了输出的可解释性。

5. 研究意义与启示 (Significance)

1. 打破“更多上下文即更好”的迷思：研究证明，盲目增加过程间上下文不仅不能提升检测率，反而可能因引入噪声导致模型性能下降，且显著增加成本。
2. 模型选择策略：
   • 若追求解释的完整性和准确性（如用于安全审计报告），首选 Claude Haiku 4.5。
   • 若追求成本与检测精度的最佳平衡（如大规模自动化扫描），首选 Gemini 3 Flash。
   • 若预算极度受限且可接受较低精度，可选 GPT-4.1 Mini，但需注意其在 C 语言中增加上下文会适得其反。
3. 工具设计建议：开发 AI 辅助安全分析工具时，应根据目标编程语言和所选模型的特性，动态调整上下文提供的粒度，而非默认提供全量调用链。
4. 未来方向：强调了在真实世界代码库中，检测能力与解释能力是紧密耦合的，提升模型的推理能力是同时改善分类和解释的关键。

总结：该论文通过严谨的实证研究指出，在现代 LLM 进行跨语言漏洞检测时，“少即是多”（在特定模型和语言下，仅使用目标函数代码往往比提供完整调用链更有效且更经济），并强调了根据具体应用场景（成本、精度、解释性）选择合适模型的重要性。