翻译：Code Change Intention, Development Artifact and History Vulnerability: Putting Them Together ...

代码变更意图、开发工件与历史漏洞：通过LLM整合它们以进行漏洞修复检测

Code Change Intention, Development Artifact and History Vulnerability: Putting Them Together for Vulnerability Fix Detection by LLM

摘要

在开源软件中检测漏洞修复提交对于维护软件安全至关重要。为了帮助开源软件识别漏洞修复提交，已开发出多种自动化方法。然而，现有的方法如 VulFixMiner 和 CoLeFunDa 仅关注代码变更，忽略了来自开发工件的重要上下文信息。像 Vulcurator 这样的工具虽然整合了问题报告，但未能充分利用不同开发工件（例如，拉取请求和历史漏洞修复）之间的语义关联。此外，这些工具无法识别纠缠提交中的漏洞修复，并且缺乏解释性，限制了其实际应用价值。
因此，为了解决这些局限性，我们提出了 LLM4VFD，一种新颖的框架，利用经过链式思维推理和上下文学习增强的大语言模型（LLMs）来提高漏洞修复检测的准确性。
LLM4VFD 包含三个组成部分：1. 代码变更意图，通过链式思维推理分析提交摘要、目的及其潜在影响；1. 开发工件，整合相关问题报告和拉取请求的上下文；1. 历史漏洞，检索类似的过往漏洞修复以丰富上下文。更重要的是，在预测的基础上，LLM4VFD 还提供详细的分析和解释，以帮助安全专家理解决策背后的逻辑。
我们使用新收集的数据集 BigVulFixes 对 LLM4VFD 与最先进的技术（包括基于预训练语言模型的方法和普通 LLMs）进行了评估。实验结果表明，LLM4VFD 的性能显著优于现有最佳方法，提升幅度达 68.1%–145.4%。此外，我们还对安全专家进行了用户研究，结果显示 LLM4VFD 生成的分析提高了漏洞修复识别的效率。

1 引言

软件开发高度依赖于开源软件（OSS）的使用。然而，未能检测和缓解 OSS 中的漏洞可能会导致灾难性后果 [62]。OSS 组织通常遵循协调漏洞披露（CVD）[49] 模型来公开漏洞。在此模型中，一旦开发者认为他们有足够的时间修复安全风险，漏洞的详细信息就会被公开共享。这通常会导致在修复漏洞的提交（即漏洞修复提交）集成到代码库与漏洞及其修复被公开宣布之间存在延迟。修复与披露之间的时间差可能为恶意用户提供机会，让他们找到漏洞的详细信息并在依赖该 OSS 的软件中加以利用。尽管 CVD 建议静默应用修复以避免泄露有关漏洞的敏感信息，但被利用的风险依然存在。因此，OSS 用户有强烈的动机监控集成的 OSS 并发现漏洞修复，以便尽快启动修复过程（即漏洞修复检测）。

漏洞修复检测是一项复杂的任务，对没有自动化方法的一般 OSS 组织来说是一个重大挑战。此外，手动监控所有集成 OSS 的提交既非常耗时又成本高昂。为了解决这一问题，先前的研究提出了自动识别漏洞修复的方法，这些方法通常通过使用提交级别的信息训练深度学习模型。例如，VulFixMiner [72] 使用来自提交的代码变更信息训练预训练语言模型（PLM）。在其后续工作 [71] 中，他们提出了一种通过使用函数级代码变更信息，在更细粒度上检测漏洞修复的方法。然而，这些方法仅利用代码变更信息，忽略了与提交相关的其他软件开发工件，使得在缺乏足够上下文的情况下难以识别代码变更的意图，尤其是对于细微的代码变更（例如，添加条件检查）。漏洞修复是一项复杂的任务，通常与问题报告 [52] 相关，但现有方法 [71, 72] 并未充分利用此类信息。唯一利用开发工件（即问题报告）的工作是 Vulcurator [39]，但它使用了投票机制，而没有利用工件之间的语义关联。先前的方法还无法识别纠缠提交中的漏洞修复——那些包含多种目的代码修改（例如重构）的提交 [4]。上述现有方法的局限性导致它们遗漏了许多真实的漏洞修复提交（如第 6.1 节所示，召回率极低，介于 0.06 至 0.26 之间）。更重要的是，识别漏洞修复需要专门的安全专业知识和特定项目的领域知识 [36, 75]，而以往的方法仅提供预测，缺乏背后决策的解释，这阻碍了这些方法的实际应用。

最近，大型语言模型（LLMs）在代码相关任务中展示了令人鼓舞的结果，例如代码理解 [2, 32] 和漏洞理解 [18, 27]。直观地说，漏洞修复检测是一项需要自然语言理解和代码理解能力的任务，尤其是在漏洞理解方面。

因此，LLMs 强大的自然语言和代码理解能力非常适合这一任务的要求。因此，为了解决这一问题并克服现有方法的局限性（即忽视开发工件中的信息、纠缠提交以及缺乏足够的解释），我们提出了 LLM4VFD，一种新颖的框架，通过利用由 LLMs 提炼的多源信息增强漏洞修复检测，包含四个组件：

• 代码变更意图（CCI） 组件通过链式思维（CoT）推理分析提交，提取其摘要、目的和潜在影响。
• 开发工件（DA） 组件利用相关开发工件的信息，例如问题报告（IRs）和拉取请求（PRs），提供额外上下文并增强对提交的理解。
• 历史漏洞（HV） 组件从历史漏洞数据中检索相似的漏洞修复提交，进一步丰富提交的上下文。
• 综合分析与漏洞修复检测（CAVFD） 组件结合从前述组件中提炼的信息，实现上下文学习。合成的信息用于生成最终预测，同时提供详细的分析解释，帮助安全专家理解决策背后的逻辑。

我们在一个新创建的多语言漏洞修复数据集上评估了 LLM4VFD，我们称其为 BigVulFix 数据集。该数据集包含 2023 年之后从国家漏洞数据库（NVD）[43] 收集的 1,689 个漏洞修复提交。LLM4VFD 在涵盖 3 个 LLM 系列的 6 个 LLM 上进行了评估，参数规模从 7B 到 236B 不等。在 MCC、F1 分数和召回率方面，LLM4VFD 始终优于基于 PLM 的方法。例如，在使用不同 LLM 作为基础模型时，LLM4VFD 的 F1 分数比表现最佳的基于 PLM 的方法 VulCurator 高出 68.1%–145.4%。我们的框架相较于其普通变体性能提升范围为 12.7%–105.6%，较小的模型通常比较大的模型受益更多。此外，进行的消融分析表明，三个组件对 LLM4VFD 的最终性能都至关重要。
通过一项涉及安全专家的用户研究，我们发现在 80.0% 的案例中，LLM4VFD 的分析帮助安全专家理解代码变更，并提高了识别变更是否为漏洞修复提交的效率。我们还进行了失败案例分析，以了解 LLM4VFD 的局限性，并为未来的工作提供见解。

总之，本文做出了以下贡献：

• 据我们所知，我们是第一个研究使用 LLM 进行漏洞修复检测的研究。
• 我们提出了一种新颖的框架 LLM4VFD，通过基于 LLM 的多源信息增强漏洞修复检测。
• 我们对 LLM4VFD 进行了广泛的评估，包括消融研究以评估 LLM4VFD 中每个组件的贡献，以及用户研究以评估 LLM4VFD 的分析结果对安全专家的实用性。
• 我们收集并发布了一个新的数据集 BigVulFixes，包含 2023 年之后的 7 种主要编程语言的 1,689 个漏洞修复提交，以避免与 LLM 的预训练数据发生数据泄漏。
• 我们对方法的局限性进行了坏案例分析，以促进未来在漏洞修复检测方面的工作。

2 背景与相关工作

在本节中，我们将介绍漏洞修复检测和 LLMs 的背景。

2.1 漏洞修复检测

典型的漏洞修复检测任务以提交作为输入，并输出该提交是否修复了漏洞。现有方法大多通过某种嵌入技术利用预训练语言模型（PLM）技术来捕获代码变更信息。Zhou 和 Sharma [76] 首次提出了漏洞修复检测的工作。他们使用提交消息和错误报告自动识别漏洞修复提交。Chen 等人 [9] 后来通过漏洞相关性的概念探讨了这一主题，以捕捉每个提交如何与解决漏洞相关联。

在此期间，尝试将提交与漏洞关联的主要目的是整理漏洞相关信息，以辅助数据收集和清理。拥有高质量的漏洞修复代码数据对于其他漏洞任务（如自动化漏洞修复）至关重要。Zhou 等人 [72] 进一步探索了检测漏洞修复提交的想法，尤其是在静默修复的情况下，即漏洞修复信息可能未公开披露。Sabetta 和 Bezzi [58] 利用基于支持向量机（SVM）的方法，结合来自提交消息和补丁信息的特征，预测提交是否与安全相关。Nguyen-Truong 等人 [42] 将三个分类器分别用于补丁、提交和相关问题内容，创建了一个联合分类器来识别漏洞修复提交。Xu 等人 [66] 提出了 SPAIN，用于在二进制级别识别漏洞修复。当目标软件无法获得源代码且仅以二进制形式分发时，他们的工作尤其有用。

在更细粒度的漏洞检测方向上也有相关努力。例如，Zhou 等人 [71] 提出了一个框架，使用深度学习技术在函数级别分析漏洞代码。他们的框架可以识别漏洞修复、CWE 类别和可利用性。还探索了变更代码的替代表示形式，尤其是基于图的技术。Nguyen 等人 [39] 提出了一种基于图的方法，用于检测静默漏洞修复。他们使用提交前后的抽象语法树（AST）构建图。他们的工作在实际的 C/C++ 项目中显示出显著的性能提升。

2.2 大型语言模型

由生成式预训练 Transformer（GPT）模型 [50] 推广开来，LLMs 在软件工程任务中展现了巨大的潜力。近期的研究探索了 LLMs 在解决一些独特的软件工程问题中的能力 [10, 17, 26, 27, 30, 74]。在实践中，LLMs 通常通过提示工程和/或微调为特定领域的任务量身定制。

提示工程是与 LLM 交互以改变其响应的关键步骤。提示的特性（例如词汇、风格、语气）会极大地影响 LLM 生成的响应 [69]。精心设计的提示可以帮助提高 LLM 在特定任务中的能力。例如，链式思维（CoT）[64] 是一种常见的提示工程技术，它将提示分解为更小的、单独的步骤，从而提高 LLM 的推理能力。LLMs 的上下文长度也有所不同，这限制了提示的长度，最终截断超出此限制的信息。因此，提示工程通常还旨在通过压缩信息使提示变得简洁。此外，提示工程是一种有效的方法，可以绕过 LLM 的知识截止问题。LLMs 通常使用早于某个知识截止日期的信息进行训练。当查询超出截止日期或不在训练数据集中的信息时，LLMs 往往会产生幻觉并生成不合适的答案。这种问题经常出现在零样本（0-shot）提示策略 [29] 中，这种策略要求 LLM 执行其未明确训练的任务。此问题通常通过在提示中提供上下文信息来解决。一个典型解决方案是上下文学习（ICL）[13]，它在提示中包含任务示例和/或演示。

由于 LLMs 在代码相关任务（如代码理解 [59]、代码摘要 [63] 和代码生成 [3, 19, 28, 35]）中表现出卓越的能力，它们克服了先前技术的许多局限性 [26, 65]。LLMs 的优势促使研究人员将其应用于漏洞相关任务。大多数先前的工作都集中在漏洞检测 [73] 上。Chan 等人 [6] 提出了一个基于脆弱代码模式的系统，用于检测代码中的漏洞。Thapa 等人 [61] 研究了 LLM 在包含多种漏洞的 C/C++ 源代码上的表现。Cheng 等人 [10] 提出了 Vercation 方法，用于识别开源 C/C++ 软件的脆弱版本。Du 等人 [14] 提出了 Vul-RAG，这是一个首先构建包含 CVE 信息的漏洞知识库的框架。然后，该框架能够通过从知识库中检索的 RAG 系统预测给定代码片段是否易受攻击。

3 挑战与动机

在本节中，我们将概述当前漏洞修复检测技术面临的主要挑战，并讨论可以利用的上下文信息类型以应对这些挑战。

3.1 挑战 #1：纠缠提交

检测漏洞修复的一个关键挑战是识别包含多种目的修改（如功能改进、重构和漏洞修复）的提交中的安全相关变更 [4]。这种意图的混合使传统方法的任务变得复杂 [25]，尤其是那些仅依赖分析代码变更来检测漏洞的方法 [71, 72]。

例如，在图 1 中，提交中的 164 行代码中只有两行通过更改 LookupPathMatchableHandlerMapping 的初始化和使用来解决漏洞，其余部分则与重构和功能调整相关。在这种纠缠提交中，大量的非漏洞相关变更引入了噪声，使得现有方法难以准确检测出真正的漏洞相关修复。事实上，目前没有任何方法 [39, 71, 72] 能够识别这一特定案例。

为了解决这个问题，我们采访了安全专家，以了解他们如何辨别漏洞修复，尤其是在纠缠提交中。从他们的见解中，我们确定了判断漏洞修复所需的三个关键信息方面：代码变更的摘要、变更背后的目的以及其潜在影响。通过关注这些方面，而不是仅仅关注原始代码变更，我们可以有效过滤掉无关修改带来的噪声，从而提高漏洞修复检测模型的准确性。

3.2 挑战 #2：提交内信息不足

在许多情况下，提交消息和代码变更本身并不足以判断提交是否与漏洞修复相关。当变更较为细微或提交消息模糊时，这一挑战尤为突出，使得传统方法 [71, 72] 难以准确识别漏洞修复提交。

例如，图 2 所示的提交仅在 filter_session.c 文件中添加了三行代码并进行了条件检查。提交消息“fixed #2475”对变更的性质或其是否与安全相关几乎没有提供任何见解。因此，仅基于代码和提交消息，即使是人类专家也几乎无法判断这是一次漏洞修复还是常规更新。

然而，当我们研究相关的开发工件——问题报告 #2475 时，可以明显看出该提交解决了安全漏洞。问题报告详细描述了一个涉及某些过滤参数处理不当的漏洞，可能导致越界读取和段错误的安全缺陷。尽管提交直接解决了这一问题，但如果没有问题报告提供的上下文，仅依赖提交的方法很可能会遗漏这一关键联系，导致假阴性预测。因此，我们的目标是利用相关的开发工件来丰富提交内容，以增强漏洞修复检测能力。

3.3 挑战 #3：缺乏项目特定的上下文信息

通常情况下，仅基于代码变更进行预测而不深入了解相应的开源软件（即项目特定领域知识）是非常困难的。

例如，图 3 左侧显示的提交包含一个小型代码变更，在 setProperty 函数中添加了检查以防止对原型属性的更改——这是原型污染漏洞的常见来源。虽然提交消息使用了“fix”一词，但变更的简单性使得很难判断这是否是一次漏洞修复，尤其是对于传统方法而言，它们通常依赖于对提交消息和/或代码的表面分析 [39, 71, 72]，在没有相关信息的情况下可能难以区分。
方便的是，项目通常会有历史提交记录，其中可能包含类似修复的内容，为项目提供更多上下文信息。例如，在图 3 右侧，我们展示了一次历史漏洞修复提交，其中在先前提交中对同一函数进行了类似更改，添加了对 proto 属性的检查以缓解已知的原型污染漏洞。这个例子表明，可以利用历史漏洞修复来补充识别新漏洞修复提交所需的缺失上下文。

4 方法论

为了解决第 3 节中讨论的挑战，我们提出了 LLM4VFD，该框架通过利用 LLMs 提取多源信息来增强漏洞修复检测。图 4 展示了我们的框架概览。LLM4VFD 包含四个组件：代码变更意图（CCI）、开发工件（DA）、历史漏洞（HV） 和 综合分析与漏洞修复检测（CAVFD）。

更具体地说：

• 为应对挑战 #1，CCI 组件利用 LLMs 的链式思维（CoT）技术构建提交摘要，重点关注三个关键方面（即代码变更摘要、变更目的和变更影响）。
• 为应对挑战 #2，DA 组件利用从相关开发工件（在我们的案例中是问题报告（IR）或拉取请求（PR））中提取的信息，为提交提供额外上下文以丰富其背景。
• 为应对挑战 #3，HV 组件构建向量数据库并从历史漏洞数据中检索相似的漏洞修复提交。这些组件的信息随后被整合到 CAVFD 组件中，在该组件中使用全面的提示模板引导 LLM 分析提交的所有相关方面。这种结构化的提示不仅预测给定提交是否为漏洞修复提交，更重要的是，它生成深入的分析解释，帮助安全专家理解预测背后的逻辑。
  

如图 4 所示，我们提供了一个运行示例来说明 LLM4VFD 的流程。输出来自挑战 #1 中的提交，通过我们的方法，可以正确识别为漏洞修复（VF）提交。

4.1 代码变更意图（CCI）

代码变更意图 组件将原始提交数据（即代码差异和提交消息）作为输入，并输出一个结构化摘要，抽象出提交背后的意图。然而，获取这些信息并非易事，因为提交数据并未明确提供这种结构化推理。为了生成此类信息，我们利用并增强了 LLMs 的推理能力，采用 CoT 技术。具体而言，我们设计了一个结构化提示，将推理过程分解为步骤，模仿安全专家分析提交的方式。提示模板如图 5 所示，引导 LLM 分析提交代码变更并将相关信息提炼为三个关键方面（称为 3 方面摘要）：摘要、目的和影响，如下所述：

1. 代码变更摘要
   在提示的第一步中，我们指示 LLM 专注于识别代码变更的主要操作。目标是抽象核心修改并总结不同类型的代码变更。
2. 变更目的
   提示的第二步指示 LLM 推理变更的原因。此步骤将提交归类为更广泛的类别，例如重构、功能增强或修复漏洞。
3. 变更影响
   在最后一步中，提示要求 LLM 考虑变更的更广泛后果，包括其潜在影响。此步骤确保捕获任何与安全相关的修改，并充分理解提交引入的潜在风险或修复。
   此外，为了简化后续组件的提取过程，我们提供了具体说明和演示示例，以确保 LLM 输出符合我们预期格式的 3 方面摘要。请注意，某些提交（例如纠缠提交）可能具有多个摘要、目的和影响点。如果适用，我们指示 LLM 为每个方面生成多个点（即关键点/可选关键点）。
   

提示模板：代码变更意图

系统提示：你是一位专门研究软件开发生命周期的有帮助的软件开发助手，旨在帮助其他开发者理解软件补丁的特性。
用户提示：给你以下软件补丁：{提交}。请分步骤思考并提供描述以下特性的分析：

1. 代码变更摘要
2. 变更目的
3. 变更影响
   以项目符号格式提供每个特性的分析。每个项目符号应以关键点开头，然后简要描述文本中的主要思想或事实。确保每个点简洁并捕捉其所总结的主要思想的本质。以下是期望的格式示例：
4. 代码变更摘要
   • [关键点]：<描述>
   • [可选关键点]：<描述>
5. 变更目的
   • [关键点]：<描述>
   • [可选关键点]：<描述>
6. 变更影响
   • [关键点]：<描述>
   • [可选关键点]：<描述>

4.2 开发工件（DA）

在 DA 组件中，我们的目标是整合外部开发工件（如问题报告（IR）和拉取请求（PR））的信息，以丰富对给定提交的分析。然而，这些工件可能冗长且包含无关细节，例如问题报告模板和 CI/CD 通知。为了解决这一问题，并受到 4.1 节中 CCI 组件的启发，我们设计了一个结构化提示，引导 LLM 分析和总结相关 IR 和 PR，生成类似于提交的 3 方面摘要。

更具体地说，DA 组件生成一个简洁的摘要，通过关注三个核心方面（摘要、变更目的和潜在影响）来抽象这些工件背后的意图。提示模板如图 6 所示。

提示模板：IR/PR 摘要

系统提示：你是一位专门研究软件开发生命周期的有帮助的软件开发助手，旨在帮助其他开发者理解软件组件（如补丁、问题报告、拉取请求等）的特性。
用户提示：给你以下与提交相关的 GitHub 问题报告标题和正文信息（JSON 格式）：{提交}。请分步骤思考并提供描述以下特性的分析：

1. 报告摘要
2. 报告目的
3. 报告影响
   以项目符号格式提供每个特性的分析。每个项目符号应以关键点开头，然后简要描述文本中的主要思想或事实。确保每个点简洁并捕捉其所总结的主要思想的本质。包含 1-3 个关键点。以下是期望的格式示例：
4. 报告摘要：
   • [关键点]：<描述>
   • [可选关键点]：<描述>
5. 报告目的：
   • [关键点]：<描述>
   • [可选关键点]：<描述>
6. 报告影响：
   • [关键点]：<描述>
   • [可选关键点]：<描述>

4.3 历史漏洞（HV）

在该组件中，我们的目标是利用历史漏洞修复提交的信息。更具体地说，给定一个提交，HV 的目标是检索相似的漏洞修复提交以丰富当前提交的内容。正如第 3 节所讨论的，漏洞修复提交可能是多用途的，并包含解决其他问题的代码。因此，我们决定根据意图检索相似的漏洞修复提交。为此，我们需要构建一个历史漏洞修复数据库。
首先，我们从现有的漏洞数据库（如 NVD [43]）中收集历史漏洞修复提交。然后，使用 CCI 组件为所有收集到的漏洞修复提交生成 3 方面摘要。接着，我们使用句子嵌入模型 [34] 对每个漏洞修复提交生成的三方面摘要进行嵌入和向量化，并将它们存储在向量数据库中。除了生成的摘要外，我们还存储其对应的漏洞元数据，包括 CVE ID 和 CVE 描述。

在处理新提交时，我们首先使用 CCI 组件为提交生成 3 方面摘要。然后，基于其 3 方面摘要的相似性，从历史漏洞数据库中搜索最近的实例。通过最近的实例，我们从其元数据中收集 3 方面摘要和 CVE 描述，作为 HV 组件的输出。

4.4 综合分析与漏洞修复检测（CAVFD）

在最后一步中，我们将从三个组件（即 CCI、DA 和 HV）收集的多源输出，连同提交的代码变更和提交消息，整合到一个全面的 LLM 提示中。这一步确保模型能够访问提交的所有相关特性，不仅包括代码本身，还包括周围的上下文和历史漏洞修复提交。输出是一个带有结构化分析和推理的预测，解释决策是如何做出的。提示模板如图 7 所示。

提示设计遵循多维方法 [7]，以确保对给定提交进行彻底且结构化的分析。我们通过引导 LLM 使用 CoT 和 ICL 技术分析并整合来自各组件的信息来实现这一点。首先，我们将原始提交数据（代码差异和提交消息）作为补丁内容提供，随后提供来自三个组件的输出。接下来，我们设计提示以包括 LLM 的两步任务：比较 和 分析。

1. 比较阶段：我们提示 LLM 将当前补丁与检索到的历史修复进行评估，以避免潜在偏差并确保基于证据的分析。这是因为我们无法保证检索到的历史漏洞确实与当前提交相关。
2. 分析阶段：我们要求 LLM 合成来自三个组件的信息，以确定补丁是否为漏洞修复，并提供理由。最后，我们指示 LLM 以 JSON 格式生成响应，包括其详细分析和最终决策。
   分析过程旨在输出一种分析结果，以帮助 LLM4VFD 的用户在手动筛选过程中更好地理解 LLM 的决策过程。我们在第 6.3 节中进行了用户研究，以评估生成分析结果的实用性。
   

提示模板：综合分析与漏洞修复检测

系统提示：你是一位专门从事漏洞检测的有帮助的软件开发助手，旨在帮助其他开发者理解软件补丁的特性并发现潜在漏洞。
用户提示：给你以下用于分析的详细信息：

1. 补丁内容：{提交}
2. 相关问题报告/拉取请求摘要：{DA 组件输出}
3. 补丁的三方面分析：{CCI 组件输出}
4. 类似历史漏洞修复信息：{HV 组件输出 - CVE 描述}
5. 历史漏洞修复的三方面分析：{HV 组件输出 - 3 方面摘要}

任务：

1. 比较：
   • 仔细比较当前补丁与历史漏洞修复，以避免偏差。
   • 确保考虑三方面分析中突出显示的相似点和不同点。
2. 分析：
   • 使用来自相关问题报告/拉取请求摘要的信息，理解补丁背后的上下文和动机。
   • 确定当前补丁是否旨在修复漏洞。如果你认为它是漏洞修复，则必须提供证据。

你的输出应遵循以下语法：

{"analysis": "<关于补丁是否修复漏洞的详细分析>", "vulnerability_fix": "<yes 或 no>"}

5 实验设置

在本节中，我们提出了研究问题（RQs）、数据集、评估指标、针对 RQs 的分析方法以及实现细节。

5.1 研究问题

我们从不同方面评估 LLM4VFD，以回答以下研究问题：

• RQ1：LLM4VFD 与最先进的技术相比效果如何？
• RQ2：LLM4VFD 中每个组件的效果如何？
• RQ3：LLM4VFD 生成的分析能否帮助安全专家识别漏洞修复？
• RQ4：失败案例分析：LLM4VFD 在哪些场景下会失败？

5.2 数据收集

5.2.1 日期范围选择

LLMs 是基于大量数据训练的，这导致了一个知识截止日期，反映了它们所掌握的最新信息。对于我们的任务，向 LLMs 提供早于其知识截止日期的历史漏洞可能导致数据泄漏，因为模型可能已经知道这些漏洞。为缓解这一问题，我们将分析限制在 2023 年之后的漏洞，以确保使用的数据是在知识截止日期之后，并降低数据泄漏的风险。

5.2.2 漏洞与非漏洞修复提交的选择

我们从 NVD [43] 收集历史 CVE 数据开始数据收集过程。NVD 包含大量漏洞数据，涵盖众多开源软件（OSS），涉及广泛的开发活动和目的。我们仅包括在其参考中包含 GitHub 提交 URL 的 CVE，这些 URL 表明漏洞修复的存在。为了获取此信息，我们使用 GitHub 的 REST API 端点直接访问存储库，并从响应 JSON 中提取语言键 [12]。为了避免漏洞多样性的长尾效应，我们将范围限制在 7 种编程语言的漏洞，即 Java、C、C++、Rust、JavaScript、Python 和 Go。

在现实世界的开源软件（OSS）开发中，漏洞修复（VF）提交极为罕见，仅占总提交的一小部分。VF 与普通提交的比例可能低至 1:1000。例如，在 OSS 项目 FFmpeg 中，我们收集了 114,210 次总提交，其中只有 124 次是 VF 提交（0.1%）。这种极端的类别不平衡使我们的任务比典型的二分类任务更具挑战性，后者通常假设分布更加平衡（接近 1:1 的比例）。

为解决这一不平衡并减少评估的非漏洞修复（NVF）提交数量，我们遵循 Big-Vul 数据集 [16] 的采样策略，选择了 VF 与 NVF 提交之间的 1:16 比例。我们从收集漏洞修复提交的相同 OSS 中随机采样 NVF 提交。我们的最终评估数据集 BigVulFixes 包含 1,689 次 VF 提交和 26,468 次 NVF 提交，反映了这一采样比例。

此外，为了处理极端异常值并确保与我们使用的语言模型的最大标记长度兼容，我们排除了超过补丁标记长度第 99 百分位（约 30,000 个标记）的补丁。

5.3 IR/PR 数据收集

对于从前面步骤中收集的所有提交，我们使用两种方法收集相关的问题报告（IR）或拉取请求（PR）URL 及其信息。第一种方法是解析提交消息以查找对 IR/PR 的任何引用。GitHub 使用特定格式的自动链接功能，允许开发者直接在提交消息中引用 IR/PR 信息 [12]。我们设计了一个正则表达式，根据定义的自动链接格式语法查找这些 IR/PR 引用。第二种方法访问了“列出与提交关联的拉取请求”GitHub REST API 端点。该端点提供包含相应提交的拉取请求。这种方法特别适用于开发者未在提交消息中引用相关拉取请求的情况，从而避免第一种方法失效。最后，我们使用 GitHub REST API 从每个收集到的 IR/PR URL 中检索信息。我们为 BigVulFixes 数据集总共收集了 17,791 条 IR/PR 数据。

5.4 历史漏洞数据收集

在前一节中，我们描述了如何收集 2023 年之后的数据用于评估，因此，为了避免数据泄漏，我们选择的历史漏洞数据范围将是 2023 年之前的所有漏洞数据。与前一节类似，我们首先从 NVD [43] 收集 2023 年之前的所有历史 CVE 信息，并从漏洞咨询 NVD 收集了 22,745 个漏洞。对于每个历史漏洞，我们收集其相关的漏洞修复提交和 CVE 描述。

5.5 实现细节

5.5.1 LLMs 选择

LLM4VFD 是一个可以与任何 LLM 和嵌入模型结合使用的框架。在本研究中，我们基于代码相关基准（如 HumanEval [8]、MBPP EvalPlus [35]）和通用基准（如 MMLU [24]、IFEval [70]）的表现选择了最先进的 LLMs。我们重点关注三个 LLM 家族：Llama [15]、Qwen [67] 和 Deepseek [77]。对于 Llama 家族，我们选择了 Llama3.1-70B 和 Llama3.1-8B。从 Qwen 家族中，我们选择了 Qwen2-70B 和 Qwen2-7B。对于 Deepseek 家族，我们包括了 DeepseekCoder-V2（236B）及其较小版本 Deepseek-Coder-V2-Lite（16B）。我们使用所有 LLMs 的“指令微调”版本。

我们通过 vLLM [31] 在 Ascend 910 NPUs 上部署了 Llama、Qwen 和 Deepseek-Coder-V2-Lite。对于 Deepseek-Coder-V2，我们利用了 DeepSeek 提供的官方 API。实验的总计算成本约为 25 亿个标记。虽然更强大的 LLMs（如 Llama3.1-405B 或 GPT-4o）可用，但它们要么是闭源的，要么计算成本过高，无法在我们的研究中部署。因此，我们选择了上述模型。

5.5.2 嵌入模型和 RAG 实现

对于我们在检索增强生成（RAG）中用于嵌入 3 方面摘要的嵌入模型，我们选择了 gte-Qwen2-7B-instruct [34]。截至 2024 年 6 月 16 日，该模型在大规模文本嵌入基准（Massive Text Embedding Benchmark）[38] 上是最先进的句子嵌入模型。我们使用 ChromaDB [11] 实现向量数据库，作为 HV 和 RAG 的一部分。查询 HV 数据库时，我们使用条件过滤查询结果，仅检索与当前提交具有相同编程语言的历史漏洞。我们使用 ChromaDB 的默认欧几里得距离函数计算并检索最相似的历史漏洞。

5.6 评估指标

我们使用精确率（Precision）、召回率（Recall）、F1 分数和 Matthews 相关系数（MCC）[37] 作为评估指标，这些指标在先前的研究中被广泛使用 [5, 33, 56, 68, 75]。与先前的研究不同，我们避免使用准确率（Accuracy）作为评估指标，因为漏洞修复检测数据集高度不平衡，多数类别可能会主导结果，导致误导性结论 [23]。

5.7 RQ 方法

5.7.1 RQ1：LLM4VFD 与 SOTA 技术相比效果如何？

在 RQ1 中，我们将 LLM4VFD 与现有的 SOTA 方法进行比较，包括三种基于 PLM 的技术和三种不同规模的 LLMs（在 CoT 零样本设置下）。

首先，我们选择了三种 SOTA 的 PLM 方法，包括 VulFixMiner [72]、CoLeFunda [71] 和 VulCurator [40]。我们选择 VulFixMiner 和 CoLeFunda 是因为它们是最常用的漏洞修复检测基线 [41, 51]。VulCurator 扩展了 VulFixMiner 的方法，包括与提交相关的开发工件（即 IR/PR、提交消息）。由于其实现限制，CoLeFunda 仅适用于 Java 语言，因此我们仅在 Java 数据上比较 CoLeFunda 与 LLM4VFD。我们从原始作者处获取这些 SOTA 模型，并根据作者指导或复现包使用它们。注意，我们没有重用用于评估 VulFixMiner 和 CoLeFunda 的 VulFixMiner 数据集，因为该数据集存在数据泄漏风险（包含 2023 年之前的数据，早于我们研究中所有 LLM 的知识截止日期）。因此，我们使用新收集的 BigVulFixes 数据集评估所有模型。

其次，我们还在不使用 LLM4VFD 的情况下比较了 LLMs 的普通设置，定义为零样本 CoT 设置。为了公平比较，我们保留了漏洞修复检测提示模板的结构（如图 7 所示），但省略了代码变更意图（CCI）、开发工件（DA）和历史漏洞（HV）组件的所有信息。换句话说，LLM 仅获得补丁内容，并被要求确定提交是否为 VF，而没有任何来自 LLM4VFD 的额外上下文。此外，任务指令简化为：“确定当前补丁是否旨在修复漏洞。如果你认为它是漏洞修复，则必须提供证据。”

5.7.2 RQ2：LLM4VFD 中每个组件的效果如何？

在我们的框架中，我们集成了三个关键组件：代码变更意图（CCI）、开发工件（DA）和历史漏洞（HV）。为了了解每个组件的贡献，我们进行了消融研究，评估它们对 LLM4VFD 整体性能的单独影响。在本研究中，我们选择了 Qwen 家族中的两个模型：Qwen2-72B 和 Qwen-7B。这些模型被选中是因为它们在初始实验中表现出色（详见第 6.1 节）。在消融研究中，我们系统地每次移除一个组件，并比较移除组件前后模型的性能。

5.7.3 RQ3：LLM4VFD 生成的分析能否帮助安全专家识别漏洞修复？

让模型检测并将提交标记为 VF 通常并不是故事的终点。安全专家通常会对实例进行筛选以确认预测的正确性。这是开始修复（例如将补丁应用于下游软件依赖项）之前的必要步骤。因此，在 RQ3 中，我们进行了用户研究，调查 LLM4VFD 生成的分析是否可以帮助开发者更有效地识别漏洞修复。以下是用户研究方法的详细说明：

参与者：我们邀请了 10 名来自行业和学术界的安全专家，他们拥有 3-5 年的软件安全经验，并且有筛选漏洞修复的经验。
任务：我们随机选择了 40 个 VF 及其由 LLM4VFD（基于 Qwen2-72B）生成的分析。
流程：每位参与者需回答一系列是非问题，并可添加额外评论。我们展示 LLM4VFD 生成的分析结果，并要求评审员回答以下问题：

1. 分析是否有助于理解代码变更背后的意图？
2. 分析是否准确描述了漏洞？
3. 分析是否提供了对漏洞根本原因的更好理解？
4. 大型模型提供的分析是否有助于提高识别漏洞修复的效率？
5. 您是否对生成内容的质量感到满意（例如，是否包含冗余信息、不准确信息、不够深入、幻觉、提到的历史漏洞与当前漏洞无关等）？
   通过收集这些问题的答案，我们旨在确定 LLM4VFD 提供的分析信息是否可以帮助参与者有效理解提交并验证漏洞修复。

5.7.4 RQ4：失败案例分析：LLM4VFD 在哪些场景下会失败？

为了更好地理解 LLM4VFD 的局限性，我们对失败预测进行了手动分析，重点关注两类错误分类：

1. 假阳性（FP）：LLM4VFD 错误地将提交分类为漏洞修复（VF）的情况。这有助于我们检查 LLM4VFD 误解提交意图或上下文的场景。
2. 假阴性（FN）：LLM4VFD 未能识别提交为 VF 的情况。该分析突出了 LLM4VFD 忽略 VF 重要指标的情形。

前三位作者根据 RQ2 的结果，分别对 Qwen-72B 和 Qwen-7B 模型各审查了 20 个 FP 和 20 个 FN 案例，总计审查了 240 个案例。我们的目标是确定错误分类的具体原因。通过找出错误的根本原因，我们希望了解 LLM4VFD 的当前局限性，并为未来改进提供方向。

6 结果

6.1 RQ1 - 效果

6.1.1 基于 PLM 的方法 vs. LLM4VFD

在 MCC、F1 分数和召回率方面，LLM4VFD 始终优于基于 PLM 的方法。例如，在 F1 分数方面，LLM4VFD 的表现比最佳的基于 PLM 的方法 VulCurator 高出 68.1%-145.4%。如表 1 所示，LLM4VFD 在 F1 分数、MCC 和召回率方面显著优于所有三种基于 PLM 的方法（VulFixMiner、CoLeFunda 和 VulCurator）。使用不同 LLMs 的 LLM4VFD 实现了 0.37 至 0.54 的 F1 分数，显著高于基于 PLM 的方法（其 F1 分数为 0.14 至 0.22）。例如，表现最佳的 LLM4VFD（使用 Llama3.1-70B）实现了 0.54 的 F1 分数，相较于最佳的基于 PLM 的方法 VulCurator 提高了 145.5% 的 F1 分数。尽管 VulCurator 和 CoLeFunDa 分别实现了较高的精确率（0.50 和 0.77），但它们的召回率非常低（分别为 0.06 和 0.13），遗漏了许多真实的漏洞修复，从而限制了其实际应用。

6.1.2 普通 LLMs（零样本 CoT）vs. LLM4VFD

在 F1 分数和 MCC 方面，LLM4VFD 优于所有普通 LLMs。与普通 LLM 相比，我们观察到 LLM4VFD 在所有评估指标上均有所提升，除了两个 LLMs（即 Deepseek-Coder-V2 和 Llama3.1-8B-Instruct）的召回率略有下降。在 F1 分数方面，对于每个 LLM，LLM4VFD 在其普通设置基础上实现了 12.7% 至 105.6% 的改进。类似地，MCC 也表现出类似的改进模式。特别是，使用 DeepseekCoder-V2 的 LLM4VFD 实现了 0.40 的精确率和 0.78 的召回率，最终得到 0.53 的 F1 分数，相较于其普通设置，精确率提高了 13%，F1 分数增加了 12.8%。同样，Llama3.1-70B 的精确率从 0.41 提高到 0.49（提高了 19.5%），召回率从 0.53 提高到 0.61（提高了 15.1%），最终得到 0.54 的 F1 分数（提高了 14.9%）。

较大的模型通常优于较小的模型，而较小的模型从我们的框架中获益更多。例如，较小模型在应用 LLM4VFD 后，F1 分数平均提高了 64.0%，而较大模型的平均提高仅为 14.4%。在同一模型家族中比较较小模型和较大模型时，我们观察到无论是否使用 LLM4VFD 框架，较大模型始终优于较小模型。这可能是因为漏洞修复检测是一项复杂的任务，受益于额外参数提供的更强代码理解能力。

此外，普通设置下 LLMs 的解释结果存在显著差异，F1 分数范围广泛（从 0.18 到 0.50），尤其是对于较小模型。例如，在 Llama 家族中，普通版 Llama3.1-70B-Instruct 模型的 F1 分数为 0.47，而较小的 Llama3.1-8B-Instruct 模型的 F1 分数仅为 0.18。然而，在应用 LLM4VFD 框架后，我们发现较小模型的性能提升比大模型更显著。平均而言，F1 分数相对提高了 64.0%，而大模型的提升较为温和，平均仅为 14.4%。这些结果表明，LLM4VFD 显著提升了较小模型的性能，使其更具竞争力，并缩小了与大模型的性能差距。

LLM4VFD 在 MCC、F1 分数和召回率方面始终优于基于 PLM 的方法。例如，在 F1 分数方面，LLM4VFD 的表现比最佳的基于 PLM 的方法 VulCurator 高出 68.1%-145.4%。我们的框架相较于其普通变体，性能提升范围为 12.7%-105.6%，较小模型通常比大模型受益更多。

6.2 RQ2 - 消融分析

总体而言，LLM4VFD 中的三个组件均对整体性能做出了积极贡献。其中，代码变更意图（CCI） 的影响比 开发工件（DA） 和 历史漏洞（HV） 更为显著。表 2 展示了我们的消融分析结果。移除 CCI 组件会导致性能显著下降，尤其是在精确率和 F1 分数方面。对于 Qwen2-72B，精确率从 0.38 下降到 0.33，降幅达 13.1%；而在 Qwen2-7B 中，精确率从 0.52 下降到 0.40，降幅为 15.4%。这些结果突显了 CCI 在通过减少假阳性来提高模型准确捕获漏洞修复提交能力方面的重要作用，尤其是对于较小模型，CCI 能有效平衡精确率和召回率。开发工件（DA） 组件对 Qwen2-7B 和 Qwen2-72B 的影响较为相似。在 Qwen2-72B 中，F1 分数从 0.48 显著提升至 0.51，增幅达 6.3%，这表明 DA 提供的额外上下文信息显著提升了精确率和召回率。移除 HV 或 DA 组件会导致两种模型的 F1 分数和 MCC 略有下降。然而，我们发现 Qwen2-7B 在没有 HV 组件时精确率下降更为显著，从 0.52 降至 0.39，降幅达 25%。

消融研究强调了 LLM4VFD 中每个组件的重要性，尤其是 CCI，它在精确率和 F1 分数方面表现出显著改进，特别是对于像 Qwen2-7B 这样的较小模型。HV 则通过减少假阳性进一步提升精确率，尽管其效果相对温和。总体而言，这些组件共同构成了一个综合框架，显著提高了漏洞修复检测的准确性和可靠性，特别是通过为较小模型提供关键的上下文和历史信息。

LLM4VFD 中的所有组件均对性能做出了积极贡献，其中 代码变更意图（CCI） 的影响大于 开发工件（DA） 和 历史漏洞（HV）。

6.3 RQ3 - 用户研究

LLM4VFD 生成的分析帮助安全专家理解代码变更的意图和漏洞，从而提高了识别漏洞修复的效率。我们的结果显示，在 95.0% 的案例（40 个案例中有 38 个）中，LLM4VFD 的分析有助于理解提交的意图（问题 1）。例如，CVE-202429199 [48] 涉及 47 个更改文件、517 行新增代码和 226 行删除代码，内容过于冗长，参与者难以直接理解。然而，LLM4VFD 的分析帮助参与者快速理解了变更内容。此外，参与者认为 LLM4VFD 在 90% 的提交中准确描述了漏洞的特性（问题 2），并在 75.0% 的案例（40 个案例中有 30 个）中清晰解释了漏洞的根本原因（问题 3）。借助 LLM4VFD，参与者能够更高效地识别 VF 提交。这体现在 80.0% 的提交（40 个案例中有 32 个）中，LLM4VFD 提高了他们识别漏洞修复的效率（问题 4）。我们调查了 8 个参与者认为 LLM4VFD 分析未提升效率的案例，其中 7 个案例是因为漏洞修复本身易于识别，即使没有 LLM4VFD 的帮助也能完成。在 CVE-2024-28103 [47] 的一个案例中，即使有 LLM4VFD 的帮助，参与者仍未能理解漏洞。

在分析参与者对 LLM4VFD 生成分析质量的反馈时（问题 5），我们发现 75% 的参与者对整体分析质量表示满意。但也有一些案例（如 CVE-2023-48014 [45] 和 CVE-202337061 [44]），参与者指出分析包含冗余信息，或对更复杂漏洞缺乏深入分析（如 CVE-2023-48657 [46]）。这表明需要进一步改进以处理边缘案例，并确保提供的历史上下文相关且简洁。尽管如此，我们的工作是这一方向上的首次尝试，未来研究仍有广阔空间。

总体而言，用户研究表明，LLM4VFD 生成的分析帮助安全专家理解代码变更的意图和漏洞，从而提高了识别漏洞修复的效率。

6.4 RQ4 - 失败分析

表 3 总结了我们的失败分析结果。为了更好地理解 LLM4VFD 遇到的错误分类问题，明确安全修复与漏洞修复之间的关系至关重要。漏洞修复是安全修复的一个子集。安全修复涵盖任何增强软件整体安全性的代码变更，例如改进身份验证机制、加密实现或遵循安全最佳实践，而漏洞修复旨在解决软件代码中存在的可被攻击者利用的安全缺陷、漏洞或弱点 [43]。因此，在我们的数据集中，不针对漏洞修复的安全修复提交被视为非漏洞修复（即非漏洞相关的安全修复），尽管它们与安全修复相关。

LLM4VFD 最常见的错误分类是难以区分漏洞修复与非漏洞安全修复。例如，在假阳性（FP）案例中，Qwen2-72B 的 75.0% 和 Qwen2-7B 的 60.0% 的 FP 是由于将非漏洞安全修复误分类为漏洞修复。反之，在假阴性（FN）案例中，Qwen2-72B 的 46.7% 和 Qwen2-7B 的 55.0% 的 FN 是由于将漏洞修复误分类为非漏洞修复。结果表明，即使 LLM4VFD 能够识别与安全相关的提交，有时也难以解读其严重性。例如，在分析一个 FN 案例时，LLM 解释道：“虽然变更与安全相关，但我不确定这些变更是否修复了一个漏洞。”一种可能的解释是，LLM 在生成提交意图时无法区分安全相关变更与漏洞修复。尽管 LLM4VFD 难以区分漏洞修复与非漏洞安全修复，但二者均为安全修复，识别它们仍然具有价值。

另一个导致 FN 的常见原因是无法识别与安全相关的代码变更（占 32.5%）。另一个值得注意的失败案例与其通过 HV 组件使用历史漏洞数据有关。检索到的无关历史漏洞导致了 FP 和 FN 案例中的错误分类。具体而言，在 4.2% 的 FP 案例和 9.2% 的 FN 案例中，HV 组件检索到看似相关但与当前提交的功能或上下文细节不符的漏洞，这种信息混淆了 LLM，导致 LLM4VFD 对提交做出错误假设。尽管我们的 HV 组件在整体性能上有显著提升（如第 6.2 节的消融研究所示），但它并不完美，有时会检索到无关的历史漏洞。未来的研究可以专注于开发更好的检索技术并改进底层漏洞数据库。

我们还发现了一些 FP 案例，其中提交可能修复了未报告的漏洞。例如，在一个检查过的案例中，提交是从 GHSA [20] 的拉取请求合并的变更。GHSA 是一个独立的安全顾问机构，维护自己的漏洞数据集，可能与 NVD 的评估有所不同。

7 讨论

7.1 潜在的未来方向

我们的研究是首次探索使用大型语言模型（LLMs）进行漏洞修复检测的研究。然而，从用户研究和失败案例分析中获得的见解表明了未来可以探索的几个方向。首先，整合更多与项目相关的特定信息，例如安全策略和历史提交模式，可以帮助 LLMs 更好地区分与安全相关的提交中的漏洞修复。其次，引导 LLM 的提示模板可以进一步优化，从而更有效地利用上下文，并为安全专家生成更具洞察力的分析结果。最后，当前的 RAG 设计较为基础，引入先进技术——例如动态检索策略或重排序机制——可以提高检索到的历史漏洞的精确性和相关性。

7.2 对有效性的威胁

7.2.1 内部有效性

由于漏洞修复和非漏洞修复之间存在极端不平衡的特性，当我们的方法应用于监控实际项目时，可能会产生大量的假阴性。根据我们行业合作伙伴的反馈，假阳性率被认为是可以接受的，因为只需少量额外的人工审查即可处理这些结果。先前的研究表明，LLM 的设置（如温度参数）会影响输出 [53, 57]。在本研究中，我们在所有研究问题（RQs）中均使用了所研究 LLMs 的默认设置。

7.2.2 外部有效性

外部有效性威胁涉及我们方法的普适性。由于 LLM4VFD 是一个框架，其实施依赖于 LLMs，因此 LLM4VFD 的有效性也取决于 LLMs 的性能和能力。为了缓解这一威胁，我们使用多个知名且最先进的 LLMs 对 LLM4VFD 进行了评估，包括大模型（70B–236B 参数）和小模型（7B–16B 参数）。结果显示，在所有模型上，LLM4VFD 均优于现有的 SOTA 基线方法。我们鼓励未来的研究使用我们的框架探索更多 LLMs 的性能表现。

8 结论

本文提出了一种新颖的框架 LLM4VFD，该框架利用通过链式思维推理和上下文学习增强的大型语言模型（LLMs），通过整合多源信息（例如相关开发工件和历史漏洞）提高漏洞修复检测的准确性。更重要的是，在预测的基础上，LLM4VFD 还提供了详细的分析解释，以帮助安全专家理解决策背后的逻辑。实验结果表明，LLM4VFD 在 MCC、F1 分数和召回率方面始终优于基于 PLM 的方法。例如，在使用不同的 LLMs 作为基础模型时，LLM4VFD 的 F1 分数比表现最佳的基于 PLM 的方法 VulCurator 高出 68.1%–145.4%。此外，我们进行了涉及安全专家的用户研究，以评估 LLM4VFD 生成的分析在辅助漏洞修复识别方面的有效性。参与者的反馈表明，LLM4VFD 提供的分析提高了识别漏洞修复的效率。