技术摘要：从判定到诊断：针对拉取请求（Pull Request）的可归因安全审查

1. 问题定义：判定–诊断（Verdict–Diagnosis, VD）差距

目前的自动化代码审查工具主要根据其是否能对恶意拉取请求（PR）发出“拦截”（blocking）判定的能力来进行评估。然而，本文指出这种评估范式存在一个关键缺陷：审查器可能会因为错误的原因而正确地拦截了 PR。例如，拦截可能是由无关的问题（如格式错误或非关键性警告）触发的，而非由导致该 PR 不安全的特定漏洞引起的。

这种差异被称为判定–诊断（VD）差距。

• 判定（Verdict）： 批准或拦截 PR 的决策。
• 诊断（Diagnosis）： 对特定漏洞的具体识别及其支持证据。
• 差距（The Gap）： 正确的拦截判定配合错误的或缺乏证据支持的诊断。在这种情况下，修复工作会被误导，导致实际的漏洞仍未得到解决。

本文认为，现有的基准测试和评估指标无法区分一个系统仅仅是“拦截”了代码，还是正确地“诊断”了底层的安全缺陷。此外，许多漏洞（特别是涉及缺失必要防护措施的“缺失型”缺陷）需要来自仓库中未改动部分的证据，而标准的基于 diff 的分析往往会忽略这一点。

2. 方法论

2.1 MALPR-BENCH：一种基于机制的基准测试

为了衡量 VD 差距，作者引入了 MALPR-BENCH，该基准测试旨在分别评估三个不同的维度：

1. 判定正确性 (V)： 系统是否拦截了 PR？
2. 目标漏洞识别 (I)： 系统是否正确识别了特定的漏洞机制？
3. 证据验证 (E)： 系统是否将其诊断建立在具体的、可审计的仓库事实（代码位置、未改动文件等）之上？

构建方式：

• 规模： 包含来自 44 个仓库、8 个语言家族的 89 个恶意 PR 和 50 个良性控制案例。
• 来源：
  • 挖掘历史： 从项目历史中恢复不完整的修复记录。
  • 基于公告衍生： 根据公开的安全公告构建恶意状态（池 A：不完整的修复；池 B：反向执行）。
  • 真实世界发现： 作者的工具发现的此前未公开的漏洞。
• 地面真值（Ground Truth）： 每个案例都包含一个“冻结准则”，规定了目标漏洞、所需的证据链以及接受的描述。这使得能够精确评定一次审查是否具有“可归因性”（即 $A = V \land I \land E$）。
• 缺陷分类： 案例被分为存在型（Present-type）（不安全行为在 diff 中可见）或缺失型（Absence-type）（缺失了必要的安全防护）。证据位置被分为 L0（仅限 diff）到 L2b（在无关文件中存在语义对应关系）。

2.2 PRGUARD：一种可归因的安全审查器

为了解决 VD 差距，作者提出了 PRGUARD，该系统将漏洞识别与证据验证分离。与直接从 diff 跳到判定的端到端模型不同，PRGUARD 通过一个分阶段的流水线运行：

• 第 0 阶段（结构化收集）： 在进行任何模型推理之前，确定性地收集变更代码周围的结构化上下文（调用者、被调用者、导入项）。
• 第 1 阶段（变更特征化）： 模型描述变更中与安全相关的行为，但暂不提出具体的漏洞。
• 第 2 阶段与 2.5 阶段（证据获取）：
  • 路径 1（知识驱动）： 使用从开发案例中提取的机制知识库（KB），通过类型化关系（如 SIBLING-ENDPOINT）检索特定的仓库证据。
  • 路径 2（代码驱动）： 基于变更代码的结构构建仓库路径的工作列表，独立于知识库。
• 第 3 阶段（候选构造）： 基于收集到的证据，构建具体的候选漏洞。
• 第 4 阶段（证据验证）： 通过另一个独立的模型调用，针对收集到的仓库证据测试候选漏洞。它验证安全关键前提（攻击者控制、可达性、缺失防护）。候选结果被标记为已验证（VALIDATED）、降级（DOWNGRADED）或拒绝（REJECTED）。
• 第 5 阶段（审查综合）： 确定性策略将验证结果映射到判定（拦截、评论、批准），并合成包含具体代码位置的审查报告，以解释已验证的发现。

3. 核心贡献

1. 提出了 VD 差距的概念： 本文定义并表征了正确拦截判定与正确诊断之间的差异，认为当前的评估指标掩盖了这一失效模式。
2. MALPR-BENCH： 一个系统的评估框架和基准测试，它将判定正确性、漏洞识别和证据验证分离，并使用预设的准则作为地面真值。
3. PRGUARD： 一种可归因的 PR 安全审查器架构，它将假设生成与证据验证解耦，并能检索 diff 之外的上下文。
4. 实证验证： 证明了将识别与验证分离可以提高诊断的可归因性，特别是对于需要跨文件上下文的缺失型缺陷。

4. 结果

4.1 在通用覆盖挑战集上的表现

在 31 个留存的恶意 PR（19 个自我泛化案例 + 12 个发现案例）上，针对 CodeRabbit（一款广泛部署的商业 AI 审查器）进行评估：

• 拦截性能： 两个系统取得了相似的拦截率（CodeRabbit: 24/31; PRGUARD/DeepSeek: 22/31）。
• 漏洞识别 (I)： PRGUARD/DeepSeek 识别出的目标漏洞比 CodeRabbit 多出 1.38 倍（22 vs. 16）。
• 缺失型缺陷： 在 14 个需要防护措施缺失的案例中，两个系统都拦截了 9 个 PR。然而，PRGUARD/DeepSeek 在 9/14 的案例中识别出了目标漏洞，而 CodeRabbit 仅在 3/14 的案例中识别出来（差距为 3 倍）。
• 可归因拦截 (A)： PRGUARD/DeepSeek 实现了 19/31 的可归因拦截，而 CodeRabbit 为 16/31。
• 证据位置： 在 7 个需要触及文件之外证据（L2a/L2b）的案例中，CodeRabbit 未能识别出目标，而 PRGUARD 在大多数情况下取得了成功。

4.2 全流程评估

在 63 个留存的恶意案例（排除发现层以避免偏差）上进行评估：

• 池 B（反向执行）： 两个后端（GPT-5.5 和 DeepSeek）均识别出了所有 37 个目标漏洞（I=37/37）。然而，证据验证 (E) 表现各异（GPT-5.5 为 26/37，DeepSeek 为 34/37），凸显了识别并不保证有效的证据落地。
• 良性控制： PRGUARD 显示出较低的误报率（在 50 个良性控制中拦截 4–5 次），与 CodeRabbit（在 6 个控制中的一个子集中拦截 0 次）相当。

4.3 真实世界发现

应用于生产环境仓库时，PRGUARD 在五个广泛使用的项目中发现了 12 个此前未公开的、带有概念验证（PoC）支持的漏洞。

• PRGUARD 和 CodeRabbit 在此发现层级中均拦截了 10/12 个 PR。
• 然而，PRGUARD 产生了 10/12 个可归因拦截，而 CodeRabbit 仅产生了 4/12 个，这表明相同的判定总量可能会掩盖在诊断质量上 2.5 倍的差异。

5. 重要性与主张

本文主张，判定–诊断差距是当前自动化安全审查的一个根本性限制。如果一个“成功的”拦截不能正确识别并证实漏洞，那么它是无效的，因为这会导致修复工作方向错误。

• 可归因性是关键： 作者认为安全审查必须是可归因的——判定必须基于特定的仓库证据，以验证所识别的机制。
• 关注点分离： 结果表明，将识别候选漏洞的任务与验证其证据的任务分离，可以提高诊断的可靠性，特别是对于需要跨文件上下文的复杂缺陷。
• 局限性： 本文承认 PRGUARD 并非万能药。它将提示注入（prompt injection）和判断错误视为残余的攻击面。对现实世界漏洞的发现展示了其能力，但并未声称能估算在任意 PR 上的召回率，因为候选流经过了人工验证的过滤。

总之，这项工作将评估重点从“是否拦截？”转向了“是否基于正确的原因并提供证明进行拦截？”，从而引入了一种衡量和减轻误诊安全审查风险的方法论和工具集。