翻译：Vul-RAG: Enhancing LLM-based Vulnerability Detection via Knowledge-level RAG

Vul-RAG：通过知识级 RAG 提升基于 LLM 的漏洞检测能力

Vul-RAG: Enhancing LLM-based Vulnerability Detection via Knowledge-level RAG

摘要

在软件质量保证的过程中, 漏洞检测扮演着至关重要的角色。近年来的研究表明, 在漏洞检测领域中, 基于深度学习的模型展现出显著的潜力。本研究提出了一种基于LLM的新颖漏洞检测技术, 称之为Vul-RAG系统。该系统通过结合功能级检索增强生成(RAG)框架, 从给定代码中系统性地执行漏洞检测任务, 并划分为三个关键阶段进行操作:首先是利用LLM从已有的CVE实例中提取多维度的知识信息并构建起专业的漏洞知识库;其次是针对给定代码片段, 通过功能语义检索相关漏洞知识;最后是利用LLM对检索到的知识进行推理分析, 得出相应的漏洞成因及修复方案, 最终完成对代码片段的全面检验与评估。为了全面评估Vul-RAG系统的性能表现, 我们设计并构建了自建基准数据集PairVul进行实验测试。实验结果表明,Vul-RAG系统在准确率/配对准确率方面较现有方法分别提升了12.96%和110%, 显著超越了所有基线方法。此外, 通过用户的实际反馈调查发现,Vul-RAG生成的知识解释能够显著提高人工检验效率:准确率从原先的基础水平0.60提升至高可达0.77。

1 引言

软件中的安全漏洞向破坏性攻击打开了大门，并可能造成运行期间严重的后果。目前已有大量研究专注于自动化漏洞检测技术的发展与应用。除了采用传统的程序分析方法之外，在基于人工智能领域的最新进展下，深度学习已成功应用于漏洞检测技术中。

基于学习的漏洞检测技术[1-6]主要将漏洞检测转化为针对给定代码的二分类任务，并通过训练多种模型（如图神经网络或预训练语言模型）来实现这一目标。随后会对特定代码实施深入分析以识别潜在风险点，并结合提示工程（例如链式思维[12,13]及少量样本学习[14]）提升检测效率与准确性。当前研究中大型语言模型(LLMs)的应用进一步推动了该领域的发展，在准确识别代码中的恶意行为方面展现了显著优势[7-11]。例如现有的LLM驱动型漏洞检测系统通过整合多种辅助方法实现了更高的检测精度和可靠性

初步研究

然而

技术

基于初步研究观察到的结果启发下, 我们提出的见解是利用高级漏洞知识来区分具有潜在风险特征的实际缺陷码与看似相似但功能正确的正常码. 具体来说, 我们从开发人员识别潜在缺陷行为模式出发, 分析认为, 漏项通常会涵盖以下三类代码语义:(包括)功能、原因及修复方案. 这种高级代码语义可被用作构建漏洞检测体系所需的关键信息源.

为此

第一阶段

Vul

第二阶段

评估

我们对基准数据集PairVul上的Vul-RAG模型进行了系统评估。首先，在精确识别漏洞代码与看似相似但正确的代码对方面积分显著优于所有基线方法的前提下（例如，在准确率上提升了12.96%），我们进一步将其与其基础版本的GPT-4模型以及整合了代码级RAG增强的GPT-4版本进行了对比分析。结果显示，在所有评价指标上均持续超越这两种基于GPT-4的技术方案。随后，在考虑Vul-RAG生成的知识辅助下进行的人工漏洞检测研究中发现：该方法能够使人工检测准确率从0.6提升至0.77，并且用户反馈显示生成的知识在帮助性、精确性和通用性等方面的品质具有较高水平。综上所述,Vul-RAG所展现的知识级RAG框架具有双重优势包括：(i) 能够通过更高效的检索和利用现有漏洞知识来提升自动化漏洞检测效果；(ii) 提供了对开发者友好的解释机制来辅助人工漏洞检测,从而帮助理解具体的漏洞或非漏洞代码特征。

总结

本文的主要贡献如下：

• 基准 ：我们开发了一个新基准数据集 PairVul，并特意选择了包含漏洞代码与其看似相似但正确的代码对的样本集合。
• 初步研究 ：我们最初发现现有的基于学习的方法在理解和捕获与漏洞相关的代码语义方面存在明显局限性。
• 技术 ：基于所提出的多层次特征表达方法，我们系统性地构建了一个全面的漏洞知识库，并引入了一种创新的知识级检索增强模型 Vul-RAG 来实现高效的漏洞检测。
• 评估 ：通过系统化的实验分析，在多个真实场景下进行评估后发现由 Vul-RAG 生成的漏洞知识不仅表现出良好的自动化检测性能，在人工评估中也展现出显著的有效性。

2 背景

2.1 CVE 和 CWE

现有的漏洞分类体系中包含通用漏洞列表（CVE）[17] 和通用缺陷枚举标准（CWE）[18]等重要组成部分。其中CVE是一个广泛认可的标准,它为安全领域的风险识别提供了一套标准化的方法,每个参与方可以根据该标准发布自己的安全发现.此外,每一个CVE编号都对应一个独特的安全事件报告,这种编号机制确保了信息记录的一致性和可追溯性.值得注意的是,CVE不仅是一个编号系统,它还能够帮助组织将发现与已知的安全事件进行关联

CWE 是一种广泛使用的公共安全漏洞分类工具。
每个缺陷类别都分配了一个唯一的标识符。
虽然 CWE 提供了广泛的漏洞分类，
然而，在某些特定的CWE类别中，
具体导致漏洞的代码行为可能存在显著差异。
例如，在内存被释放后引用该内存的问题。
这一问题的根本原因可能来自于竞态条件下的不协调操作，
例如CVE-202330772事件，
或者由于引用计数错误而导致对象过早销毁，
如CVE-2023-3609事件。

2.2 基于学习的漏洞检测

深度学习的最新进展推动了许多基于学习的漏洞检测技术的发展。

• 基于图神经网络 (GNN) 的漏洞检测 [1–4] 通常将待检测的代码片段表示为基于图的中间表示形式，例如抽象语法树 (AST) 或控制流图 (CFG)。然后将图神经网络 (GNN) 应用于这些抽象的代码表示以提取特征。模型学习到的特征随后被输入二分类器进行漏洞检测。
• 基于预训练语言模型 (PLM) 的漏洞检测 [5, 6] 通常涉及在漏洞检测数据集上微调现有的 PLM。通过这种方式，代码片段被标记化并由预训练语言模型（PLM，例如 RoBERTa [22]）处理，作为编码器。提取的特征随后用于二分类任务。
• 基于大型语言模型 (LLM) 的漏洞检测 。此类方法利用大型语言模型（LLMs）通过提示工程或微调实现漏洞检测 [7–9]。前者利用不同的提示策略，例如链式思维（CoT）[12, 13] 和少量样本学习 [14, 23] 实现更准确的基于 LLM 的漏洞检测，而无需修改原始 LLM 参数；后者则通过对漏洞检测数据集进行训练来更新 LLM 参数，以学习漏洞代码的特征。

2.3 检索增强生成

基于检索增强生成模型（RAG）是一种通用范式

3 初步研究

尽管现有的基于学习的漏洞检测技术显示出令人期待的效果，但由于深度学习模型的可解释性较弱，这些技术是否真正理解和捕捉到了与漏洞行为相关的代码语义仍然不清楚。为了填补这一知识空白，在本初步研究中，我们假设“如果某技术能够精准区分一对具有高词汇相似性的漏洞代码和非漏洞代码（即仅在少数标记上存在差异），我们认为该技术具备更好的捕捉与漏洞相关语义的能力”。

如图1所示，在修复该问题的过程中（即针对该问题），我们发现尽管漏洞程序与非漏洞程序在词汇高度相似的同时，在语义上有明显区别。因此我们建议建立一个包含漏洞程序及其修复方案的标准数据集集合，并在此基础上评估现有基于学习攻击检测技术的效果。

3.1 基准数据集 PairVul

为了进行初步研究，我们首先构建了一个新的基准数据集 PairVul，因为从现有的漏洞检测基准中准备漏洞代码和修补代码对既具有挑战性又耗时费力。

例如，在表格1中列出了从2019年1月到2024年4月期间发布并被广泛使用的三个通用基准的具体统计资料[16]、[1]和[2]。其中BigVul、Devign和Reveal是主要的研究对象。为此，我们开发了一个专门的数据集PairVul作为比较依据。值得注意的是现有研究集中于漏洞代码与补丁代码配对的情况较少关注其他类型的配对关系。具体而言有些研究并未包含补丁代码而另一些研究则包含了与漏洞代码长度存在明显差异的非相似正确配对程序因此为了更全面地反映实际应用场景我们创建了这一新基准数据集PairVul它专为函数级漏洞检测而设计因为这一主题已在基于学习的研究中得到了广泛探讨[3-5,29]

数据格式

具体而言，我们的基准数据集为每个漏洞包含以下信息：

• CVE ID : 在通用漏洞与暴露（CVE）系统中用于标识报告特定漏洞的独特标识符。
  • CVE 描述 : 包含有针对系统的CVE系统提供的漏洞描述信息, 包括了该漏洞的表现形式, 可能带来的潜在影响以及该漏洞可能发生的具体环境条件.
  • CWE ID : 根据通用缺陷枚举（CWE）对不同类型的漏洞利用方法进行分类使用的标识符.
  • 漏洞代码 : 包含有该系统中存在的特定漏洞源代码片段, 这些代码片段将被后续修改.
  • 修补代码 : 已经被提交到相关平台用于修复上述存在的问题的具体源代码片段.
  • 补丁差异 : 在上述两种相关文件之间存在的详细记录, 包括具体的增删改动内容.

构建过程

考虑到Linux内核在现代复杂软件系统中具有显著代表性，在本研究中我们采用Linux内核CVE作为基准数据来源。具体而言，基于上述分析的基准构建过程主要包括两个主要步骤：

漏洞修复相关的代码收集：我们基于开源项目 Linux Kernel CVEs [30] 的资源进行收集，并专注于自动追踪Linux内核中的安全问题。通过系统自动追踪Linux内核中的安全问题并获取相应的CWE编号及CVE描述信息后，在数据库中建立完整的CVE记录体系。随后我们解析每个CVE的发布信息并获取与函数相关的漏洞修复代码及其补丁信息。我们将这些未修复前的漏洞修复前的代码片段归类为正样本数据集，并将这些已修复后的补丁文件视为负样本数据集的一部分。最终我们获得了包含2,174个CVE在内的4,667对函数级漏洞修复相关的信息库

修复代码验证 ：修复后的代码并非总是没有缺陷需要经过严格测试。因此为了保证修复版本的质量与稳定性进而对修复后的代码进行严格测试变得至关重要

基准统计

最终，我们得到了一个新的基准数据集 PairVul，其中包含来自 2,073 个 CVE 的 4,314 对函数级漏洞代码和修补代码。在本工作中，由于模型执行和人工分析的成本较高，我们重点关注基准中排名前五的 CWE 类别。特别地，由于本工作关注通常需要训练数据集的基于学习的技术，我们进一步将基准划分为训练集和测试集，具体步骤如下：对于每个 CVE，我们随机选择一个实例进入测试集，其余实例（如果有）进入训练集。我们排除了代码长度超过 GPT-3.5-turbo 当前令牌限制（即 16,384 个令牌）的情况。最终，训练集包含 896 个 CVE 和 1,462 对漏洞代码和修补代码函数，而测试集包含 373 个 CVE 和 592 对。我们基准中每个 CWE 类别的统计数据如表 2 所示。

3.2 研究基线

我们在基准数据集 PairVul 上评估了以下最先进的（SOTA）漏洞检测技术：

• LLMAO[8]：经过LLMAO模型的微调优化，并在Devign数据集上进行了进一步的优化训练以实现漏洞检测功能。
• LineVul[6]：该方法作为一种基于预训练语言模型的方法，在支持函数级别的漏洞定位的同时也能实现更细致的行级检查。
• DeepDFA[3]：该算法通过数据流分析作为指引构建了一种基于图的学习架构，并专注于解决函数级别潜在漏洞的问题。
• Cppcheck[15]：这是一个功能强大且广受欢迎的静态代码分析工具。

我们基于所有公开可用的基础模型实现了统一测试框架。通过系统性优化后完成微调,这些学习驱动的基础模型得以更好地适应我们的基准指标。此外,作为一种漏洞检测方案,LLMAO经过适配扩展后应用于函数层面,并标记出所有在单个函数运行期间表现出异常行为的行为单元

3.3 指标

为了进一步评估区分具有高词汇相似性的漏洞代码与非漏洞代码的能力, 我们开发了一个新指标——配对准确率（Pairwise Accuracy） , 该指标用于衡量漏洞代码与修复后代码都被正确识别的比例. 此外, 在漏洞检测任务中常用的六个关键指标, 包括假阴性比例（FN）、假阳性比例（FP）、准确率（accuracy）、精确率（precision）、召回率（recall）以及F1分数, 也被纳入评估体系. 其中, FN 是指真实阴性样本中的误判数量; FP 是指真实阳性和误判的数量; 准确率为正确分类样本所占的比例; 精确率为所有被判定为阳性的样本中实际阳性的比例; 召回率为所有真实阳性的样本中有多少被正确识别出来; 而F1分数则是精确度与召回率的调和平均值, 旨在平衡这两者之间的关系.

3.4 结果

如表3所示，在我们的基准数据集PairVul上，现有技术所呈现的局限性较为显著。尤其是相较于早前的基准报告（例如，在BigVul [6]上LineVul的准确率为99%），在此情况下（PairVul上的表现），现有技术的表现明显低于预期（准确率范围介于50%至54%之间）。这种结果令人担忧。具体而言，在配对方面表现得更加糟糕——配对准确率则进一步缩小至仅限于微小区间（如1%至10%）。这表明现有的基于学习的技术未能有效捕捉到细微的语义差异。这些观察结果进一步表明，在理解与漏洞相关的语义方面能力仍有待提升。

我们的见解

实际上，在某些情况下，仅存在微小语言差异的两个代码片段可能会产生完全不同的意义（即执行不同功能）。因此，在基于高级代码语义识别潜在漏洞时，在将潜在漏洞与看似相似但无误的代码区分开来方面具有重要意义。特别地，在借鉴开发者如何手动识别漏洞的经验后发现：理解一个潜在漏洞通常涉及以下几个关键方面：(1) 该潜在缺陷所实现的功能是什么；(2) 这个缺陷为什么会存在；以及 (3) 如何对这个缺陷进行修复。这种高级代码语义可作为提升漏洞检测能力的关键依据之一。因此，在本研究中，我们建议通过提升LLM在识别高级漏洞方面的知识来区分看似相似但功能正确的代码片段。具体而言，则首先利用LLM系统从现有的高级漏洞实例中构建完整的漏洞知识库；然后进一步利用这些知识库来优化LLM在进行缺陷检测任务时的表现。

4 方法

4.1 概述

在本工作中，我们提出了一种基于 LLM 的新型漏洞检测技术 Vul-RAG，该技术利用知识级 RAG（检索增强生成）框架来检测给定代码中的漏洞。Vul-RAG 的核心思想是利用 LLM 基于现有漏洞的相似漏洞知识进行推理以实现漏洞检测。图 2 展示了我们方法的总体流程，包括以下三个阶段：

• 阶段一：基于离线的CVE实例构建 （第4.2节）：Vul-RAG系统首先利用LLM技术从已知的CVE实例中提取多维数据信息并建立完整的漏洞知识库。
• 阶段二：针对一段特定代码样本 （第4.3节）：系统将对一段特定代码样本进行功能语义分析并结合预先建立的知识库进行相关性匹配。
• 阶段三：基于功能语义分析 （第4.4节）：系统将通过LLM技术对已识别的相关性较高的潜在缺陷原因及其修复方案进行逻辑推理分析，并对所分析的具体代码样本进行潜在缺陷定位与修复评估。

4.2 漏洞知识库构建

我们为全面总结漏洞而开发了一种三维表示的漏洞知识表示方法（见第4.2.1节）。基于此方案，Vul-RAG借助LLM从现有CVE实例中获取相关漏洞知识以构建知识库（见第4.2.2节）。

4.2.1 漏洞知识表示

Vul-RAG通过三个维度对CVE实例中的漏洞知识进行表征：包括功能语义、潜在原因以及修复策略。图3展示了CVE-2022-38457的三维表示实例。在此案例中，在RCU读锁情境下访问共享数据结构时，默认未采用适当同步机制而导致竞争条件及释放后的潜在利用。为修复此漏洞，默认修补代码引入了自旋锁来保护共享数据结构。

功能语义 ：总结漏洞代码的高层次功能（即代码的作用），包括：

* **抽象目的** ：对代码意图的简要总结。
* **详细行为** ：对代码行为的详细描述。

漏洞起因：对比分析漏洞代码及其对应的补丁以阐述其触发机制。我们涉及从多个角度探讨导致漏洞的原因

• 抽象漏洞描述 ：对原因进行简明扼要的概述。
  • 详细漏洞描述 ：对原因进行深入而详细的阐述。
  • 触发动作 ：直接引发该问题的具体操作步骤。

修复方案 ：通过比较漏洞代码及其对应的补丁，总结漏洞的修复方法。

4.2.2 知识提取

针对每一个现有的漏洞实例（即漏洞代码及其对应的补丁信息），Vul-RAG 通过指示 LLM 提取三维知识表示，并对其进行抽象处理从而使得提取的知识能够更加通用化地表达出来）。随后我们将详细阐述以下各阶段的过程：

功能语义提取

对于给定的漏洞代码片段而言,Vul-RAG 会通过特定指令提示LLM 分别归纳其抽象目的和详细行为模式,并将 [Vulnerable Code] 作为标记用于表示该漏洞代码片段

• 抽象目的提取提示 ：

    [Vulnerable Code]  
    上述代码片段中函数的目的是什么？请用一句话总结答案，格式为：“函数目的：”。  

用于抽象目的提取的问题：[Vulnerable Code] 请总结该函数在上述代码片段中的目的，并用以下格式回答："Function purpose:"

• 详细行为提取提示 ：

    [Vulnerable Code]  
    请用列表形式总结上述代码片段的功能，无需其他解释：“代码片段的功能是：1. 2. 3...”  

用于详细行为提取的提示：[Vulnerable Code]，请列出以下代码的功能点：1. ...功能点1；2. ...功能点2；3. ...功能点3

图 3 展示了功能语义的示例输出。

漏洞成因与修复方案提取

由于漏洞成因与修复方案之间通常存在内在联系，本研究提出的Vul-RAG方法通过整合这两者的优势来提升LLM在漏洞分析中的性能。具体而言，在这一框架下有两种提取机制：第一阶段要求模型阐述为何有必要对漏洞代码进行修改；第二阶段则需模型基于前一阶段所得出的结论来归纳总结该漏洞的根本原因及其相应的补丁方案。这种分层推理模式基于链式推理模式（Chain-of-Thought），旨在逐步引导LLM深入思考问题本质并实现精准分析效果[12, 13, 31, 32]。此外，在输入长度有限的情况下，为了便于模型输出规范化的结果格式化信息,Vul-RAG采用了简明扼要的方式呈现两个示例：一个展示了具体的缺陷表现形式,另一个则给出了完整的修复方案.根据第4.4节所述的具体知识表示方法,我们特意为该框架构建了两个典型示例.具体提示如下:占位符[Vulnerable Code]、[Patched Code] 和 [Patch Diff] 分别标识待补丁的缺陷代码、修正后的完整代码以及该缺陷与补丁之间的差异;而占位符[CVE ID] 和 [CVE Description] 则分别对应于该缺陷的具体CVE编号及其技术细节描述.

• 第一轮提取提示 ：

    这是一个包含漏洞 [CVE ID] 的代码片段：[Vulnerable Code]  
    漏洞描述如下：[CVE Description]  
    正确的修复方法是通过 [Patch Diff]  
    修改后的代码如下：[Patched Code]  
    为什么上述修改是必要的？  

Extraction prompt in Round 1 refers to a piece of code containing a known vulnerability identified by its CVE ID: Vulnerable Code. The corresponding CVE description provides detailed information about the issue. The recommended fix involves applying the patch difference specified in the following section. The modified code, as shown below, incorporates this fix: Patched Code. The modification is essential to ensure system integrity and prevent potential security risks.

• 第二轮提取提示 ：

    我希望你作为一名漏洞检测专家，根据上述漏洞修复信息组织漏洞知识。请总结导致漏洞的代码行为以及修复漏洞的具体方法。以 JSON 格式整理你的发现。以下是引导你提取细节的示例：  
    [漏洞成因与修复方案示例 1]  
    [漏洞成因与修复方案示例 2]  

Extraction Prompt in Round 2: 希望您能够扮演漏洞检测专家的角色，并根据上述修复漏洞的信息整理漏洞知识。请总结代码导致漏洞的一般可推广的具体行为以及修复的具体解决方案。Format your findings in JSON, 使用以下两个示例来指导所需提取信息的具体程度：

知识抽象

不同的漏洞实例可能存在相同的高层知识（如相似的原因与补救措施），因此基于此，在提取这些漏洞共性时能够提炼出更具通用性的知识表示。
为此,Vul-RAG采用LLM对提取的具体代码元素,如方法调用、变量名及类型,进行高层次抽象。
我们的研究重点在于功能语义不参与这一过程。
随后我们将阐述相关知识抽象的原则与示例。

• 在进行抽象化的方法执行时 ，系统能够识别出具体的函数调用实例 （ 如 io\_worker\_handle\_work 和 mutex\_lock\left(&dmxdev\textgreater{}mutex\right) ） ，这些实例都可以被概括为更通用的行为模式 （ 如 “在处理 IO 工作流程期间 ” 以及使用与 mutex\_lock\left(\right) 类似机制进行同步控制 ）。

Method Invocation Abstraction. The extracted knowledge may include specific method references with detailed function pointers (e.g., io_worker_handle_work) and arguments (e.g., mutex operations), which may be encapsulated as generalized descriptions, such as describing IO work process handling and employing a locking mechanism similar to that of mutex_lock().

• 抽象变量名和类型 ：所提取的知识可能包括特定变量名或数据类型（例如，“未初始化 &dev->ref ”），这些信息可以被更一般性地描述（例如，“未正确初始化引用计数器”）。
  Abstraction of Variable Names and Types. The extracted knowledge may include specific variable names or data types (for example, "without &dev->ref initialization"), which can be more generally described (for example, "without proper reference counter initialization").

Vul-RAG 采用特定提示以指导 LLM 实现知识抽象过程，并遵循这些提示以调用其内部抽象机制及相关的变量名操作。

知识抽象提示 ：

    基于前一阶段提取的详细漏洞知识，您的任务是对这些知识进行抽象和概括，以增强其在不同场景中的适用性。请遵循以下提供的指导原则和示例： 
    [知识抽象指导原则和示例] ...

Prompt for Knowledge Abstraction: With the detailed vulnerability knowledge extracted from the previous stage, your task is to abstract this information and then further develop it to make it applicable in various scenarios. Please adhere to the following guidelines and examples provided: [Knowledge Abstraction Guidelines and Examples] …

最终结果是每个漏洞实例对应的三维知识表示（即以一种形式进行表达）。具体来说，在第3.1节所述PairVul框架构建的基础上，我们针对每一组现有的漏洞实例进行了单独处理，并将所有这些实例所提取的知识项进行整合至最终的知识库中。

4.3 漏洞知识检索

基于给定的漏洞检测代码片段,Vul-RAG 经过三个阶段的检索流程,从所构建的知识库中获取相关的漏洞信息项:包括生成查询,执行候选知识检索以及对候选知识进行排序

查询生成

Vul-RAG 不仅以代码为基础进行检索查询，并且综合考虑了代码的功能意义作为多维查询。首先通过提示LLM提取给定代码的功能意义（第4.2.2节所述），并结合抽象目的、详细行为以及代码本身共同构成后续检索的查询。

候选知识检索

该系统采用基于相似度的检索机制，并通过三个关键查询元素——代码、抽象目的以及详细行为——来进行检索。每个查询元素均独立地从知识库中检索出排名前n（实验中取n=10）的知识项。因此，在综合所有查询结果后，该系统总共获得了10至30个候选知识项（需要注意不同查询来源可能产生重复结果）。为了计算 query 和 document 之间的相似性评分，则采用了 BM25 算法 [33] 。对于给定的 query 字符串q及其相关 document 集合D，在BM25算法应用之前需要对 query 和 document 进行预处理工作。其中k=1.2和b=0.75这两个参数被用来规范化 word 频率并调节对 document 长度的影响。预处理阶段通常包括分词、词干提取以及去除停用词这三个步骤[34]。

该系统采用BM25模型评估文档相似度值为：

Sim_{BM25}(q,d)=\sum_{i=1}^{n}\left(\frac{IDF(w_i)\cdot f(w_i,q)\cdot(k+1)}{f(w_i,q)+k\,\cdot\,\left(\text{1}-b+b\,\cdot\,\frac{|q|}{avgdl}\right)}\right)

候选知识重排序

我们采用倒数排名融合（RRF）策略对待排序知识项进行调整排列。对于每个被检索到的知识项k，在所有三个查询元素中对其相应排名进行汇总以计算其总分值。如果某个知识项目k未被特定查询元素所检出，则对该项目的秩次赋值为无穷大。根据公式2所述内容确定各项目最终分数值；其中E代表所有查询因素集合（即代码、抽象目的及详细行为），rank_t(k)表示基于查询因素t之下的项目k之秩次评估结果

ReRankScore_k = \sum_{t \in E} \frac{1}{rank_t(k)}

最后阶段中筛选出排名靠前的 10 个候选知识项，并将其作为用于向 LLM 提供漏洞检测所需的知识项。

4.4 知识增强漏洞检测

基于检索得到的知识项,Vul-RAG借助LLM对给定代码是否存在漏洞进行判定。然而,简单地将所有检索出的知识项整合至提示中可能会影响模型效果,因为LLM在处理冗长背景信息时通常表现出较差的效果[35]。因此,Vul-RAG采取迭代方式,逐一应用每个检索出的知识项,依次检验给定代码是否存在相同漏洞成因或对应修复方案。若发现代码存在与知识项相同漏洞成因但缺乏相关修复方案,则将其归类为存在漏洞的代码;若无法通过当前知识项判定代码为非漏洞,则进入下一轮迭代（即采用下一个检索出的知识项）。当代码未能通过任何知识项被判定为存在漏洞时，则最终归类为无漏洞状态。迭代过程将在以下两种情形下终止:(i)判定代码存在漏洞并停止;(ii)遍历完所有检索出的知识项后仍未找到匹配结果。特别地,用于判定漏洞成因及修复方案的相关提示如下：

寻找漏洞成因的提示 ：

    给定以下代码及相关漏洞成因，请检测代码中是否存在漏洞成因。[代码片段]。在类似代码场景中，发现了以下漏洞：[漏洞成因][修复方案]。请结合您对漏洞的知识以及上述漏洞知识，检测代码中是否存在漏洞。

Vulnerability Cause Detection Prompt: Given the provided code along with its associated potential vulnerabilities, please evaluate whether any vulnerabilities exist within this codebase. [Code Snippet] has been analyzed, revealing several known vulnerabilities in comparable scenarios. The detection process should leverage both existing knowledge of vulnerabilities and any additional information provided to thoroughly assess potential issues within this system.

寻找修复方案的提示 ：

    给定以下代码及相关漏洞修复方案，请检测代码中是否存在漏洞。[代码片段]。在类似代码场景中，发现了以下漏洞：[漏洞成因][修复方案]。请结合您对漏洞的知识以及上述漏洞知识，检测代码中是否存在相应的修复方案。

此段内容为关于代码漏洞修复的指导说明：给定以下代码及其相关漏洞修复方案，请核查代码是否存在漏洞（Code Snippet）。在类似代码场景中发现以下漏洞：（Vulnerability causes）（fixing solutions）。请运用相关漏洞知识及上述修复方案知识来确定是否存在对应的修复解决方案。

5 评估设置

我们通过回答以下四个研究问题来评估 Vul-RAG 的有效性和实用性：

• RQ1：相较于当前最先进的SOTA技术 ：Vul-RAG在面对最新的SOTA（State-of-the-Art）漏洞检测技术时展现出怎样的性能？
• RQ2：基于GPT-4的相关技术 ：Vul-RAG在针对基于GPT-4的技术时表现出怎样的优势？
• RQ3：对开发者而言 ：Vul-RAG生成的知识是否能够帮助开发者进行人工漏洞检测？
• RQ4：对其失败原因分析 ：为何Vul-RAG在某些情况下无法有效检测漏洞？

5.1 实现

基于 GPT 系列模型开发了 Vul-RAG 这一工具。具体而言，在离线知识库构建阶段，则是为了生成大量漏洞知识项而采用了 gpt-3.5-turbo-0125 模型版本 [36]；该版本以其快速响应和经济高效的性能著称[11]. 在线知识增强检测阶段，则采用了 GPT-4 模型版本[37]. 该版本以其卓越的理解能力和强大的逻辑推理能力而闻名[38]. 对于 knowledge retrieval 过程，则采用 Elasticsearch[39], 其默认采用 Lucene 库中的 BM25 评分函数.]

6 结果

6.1 RQ1：与 SOTA 技术相比

在 RQ1 中，我们在初步研究（第 3 节）的相同设置下评估 Vul-RAG，包括相同的基准数据集（即 PairVul）、相同的指标和相同的基线（即 LLMAO、LineVul、DeepDFA 和 Cppcheck）。由于篇幅限制，我们不再重复基线结果（先前已在表 3 中展示），而是将 Vul-RAG 的结果展示在表 4 中。

根据两个表格的数据，我们呈现以下发现：

6.2 RQ2：与基于 GPT-4 的技术相比

RQ2 通过比较 Vul-RAG 与两个基于 GPT-4 的基准模型来考察知识级 RAG 框架的实际应用价值。

6.2.1 基线

• 基础 GPT-4 ：直接查询 GPT-4 进行漏洞检测，提示设计如图 4(a) 所示。这表明了 GPT-4 在漏洞检测中的基本能力。
• 基于代码的 RAG ：通过从训练数据集中检索相似代码片段增强基础 GPT-4，提示设计详见图 4(b)。将 Vul-RAG 与此基线进行比较可以研究知识级 RAG 相较于代码级 RAG 的贡献。
  

6.2.2 结果

表 4 比较展示了 Vul-RAG 与基于 GPT-4 的两个基准模型之间的对比。从整体情况来看，在各项评估指标上,Vul-RAG 均持续优于另外两种基于 GPT-4 的基准模型,这有力地证明了我们所提出的知识级 RAG 框架的有效性。具体来说,我们通过提供一组能够被 VUL-RAG 成功检测但在另外两种基于 GPT-4 的基准模型中无法检测到的示例,从而清晰地阐述了 VUL-RAG 相对于其他方法的独特优势。

知识表示 ：图 4 展示了一个示例，说明了我们知识表示的优势。在检测来自 CVE-2023-30772 的给定代码时，基础 GPT-4 未能识别漏洞的真实原因（如图 4(A) 所示）。GPT-4 错误地建议“platform_get_irq_byname()”缺少返回值检查可能导致漏洞，而此处并不需要这种检查。然而，它忽略了真正的问题，即异步事件处理不当导致竞争条件，进而引发释放后使用漏洞。这种误解延续到 GPT-4 检测对应的修补代码时，导致假阳性并影响配对准确率。增强 GPT-4 的基于代码的 RAG 同样未能检测漏洞。如图 4(B) 所示，尽管检索到的代码对具有相似的功能语义和漏洞成因，GPT-4 仍然难以将检索到的源代码中隐含的漏洞知识与目标代码关联起来。相比之下，提供我们方法 Vul-RAG 提炼的高级漏洞知识后，GPT-4 不仅成功检测到漏洞代码的根本原因，还准确识别了修补代码（图 4©）。这一对比表明，高级漏洞知识可以有效帮助 LLM 理解漏洞代码的行为，从而提高漏洞检测的准确性。

检索策略 ：图 5 比较了基于代码检索（即仅通过代码片段检索）和我们的检索策略（即通过代码片段和提取的功能语义检索）对给定代码片段的检索结果。如图 5 所示，在检测来自 CVE-2023-1989 的给定代码片段时，基于代码的检索找到一个代码片段（来自 CVE-2021-33034），它与目标代码共享更多操作资源（黄色高亮），但在功能语义上存在显著差异，导致漏洞的根本原因不同。相比之下，我们的检索策略找到一个代码片段（来自 CVE-2023-1855），它与目标代码具有更高的语义相似性（绿色高亮）。此外，它们具有相同的漏洞根本原因，即在设备移除过程中未能充分处理异步事件。这表明我们的检索策略可以帮助 LLM 找到具有更相似漏洞成因的代码对。

6.3 RQ3：对开发者的实用性

针对 RQ3 的研究阶段中，在这项研究中我们开展了一项用户的调研活动

6.3.1 用户研究方法

任务

参与者
我们招募了6名具备3至5年C/C++编程实践经验的研究者参与用户体验研究。通过前期评估了解了他们对C/C++编程知识的掌握情况，并据此将其分成两组（GA与GB），两组的专业知识水平具有相似性。

流程

帮助性：该漏洞知识有助于支持理解特定安全问题并验证相关检测机制。
精确性：这些漏洞知识能够提供细致且全面的安全事件描述。
通用性：这些安全事件知识具备一定的通用适用性，并避免过于具体化可能会导致局限性的描述（例如，在描述时过度依赖具体标识符可能会限制其广泛实用性）。

6.3.2 结果

与传统设置相比，在识别漏洞代码以及区分非漏洞代码的能力上（即在知识辅助模式下的检测准确率高达77%，而传统模式下的检测准确率为60%），基于Vul-RAG生成的知识体系表现更为突出。

6.4 RQ4：失败案例分析

为了了解 Vul-RAG 的局限性，我们进一步手动分析了错误案例（即 Vul-RAG 报告的假阴性和假阳性）。特别地，我们对手动分析了来自 CWE-119 的所有 19 个假阴性和 21 个假阳性案例。表 5 总结了这些案例的原因及其分布。

假阴性的原因

假阴性的原因主要分为以下三类：

• 不准确的知识描述问题 ：我们发现，在 5 个案例（26.3%）中（占总测试案例的 15.8%），Vul-RAG 成功地从知识库中检索到了相关的漏洞信息。然而，在这些结果中存在描述上的不准确性问题导致漏检现象的发生。例如，在分析 CVE-2021-4204 的代码片段时（即该漏洞的具体实现细节），尽管 Vul-RAG 能够正确识别出与之相关的技术信息（如缺乏适当的边界检查），但其对边界检查的具体要求仍需进一步明确才能实现有效识别。
• 数据匹配不足的问题 ：我们观察到，在 2 个案例（约 15.8%）中（占总测试案例的 9.7%），Vul-RAG 完全无法从现有知识库中找到匹配的相关漏洞信息而导致假阴性结果的发生。具体而言，在这些情况下（即当代码特征与已知实例存在功能性技术差异时），尽管数据库中可能存在类似的修复方案和技术路径信息（如某些其他 CVE 的修复步骤），但由于这些信息在功能意义上与当前问题存在显著差异性（即技术特性并不完全相同），因此无法实现有效的假阴性检测。
• 数据缺失的问题 ：根据我们的系统分析，在 12 个案例（63.2%）中（占总测试案例的 37.7%）的情况下（即当代码特征与数据库中的现有记录完全不匹配时），数据库中并未提供任何相关信息以支持这些问题的解决方法。这一情况的根本原因在于 RAG 框架本身的局限性（即其对某些特定技术的理解能力仍有待提升）。在未来的工作计划中，则计划通过引入更多元化的 CVE 数据来扩展数据库的内容范围，并提高其对复杂漏洞特征的支持能力。

假阳性的原因

假阳性的原因可分为以下两类：

不匹配的修复方案 ：在这些案例（约52.4%）中，尽管Vul-RAG成功检索了相关漏洞知识，但代码片段仍然被视作存在漏洞，并未采用所检索知识中的修复方案。主要由于一个漏洞通常具有多种替代修复策略。

无关漏洞知识检索：在10个案例（占47.6%）中,假阳性结果多源于Vul-RAG检索到的相关但无用的知识.通过人工核查发现,这些错误检索的知识描述往往较为简略,如'缺乏针对特定数值的充分验证',这给GPT-4模型精确识别漏洞带来了挑战.

7 对有效性的威胁

潜在威胁：漏洞基准数据集与 GPT-4 的训练数据之间可能存在潜在的数据泄露问题。然而, Vul-RAG 相较于基础 GPT-4 的明显优势表明,其有效性不仅不局限于对数据的记忆能力。

泛化性中的潜在问题：鉴于Linux内核CVE的普遍性和其丰富的漏洞信息库[41]的存在性,我们特意选择了基于Linux内核CVE的基准数据集。然而,这种选择可能会限制该研究方法在不同系统上的适用性,因为这种方法实际上并不局限于针对Linux内核CVE的设计,而是具有更强的通用能力以适应其他系统环境下的CVE分析需求。此外,另一个值得探讨的问题在于:当构建的知识库未能涵盖与待检测代码相关联的关键漏洞信息时,如何确保能够从其他CVE中提取的有效漏洞特征来进行检测?为了验证这一问题的有效性,我们人工编制了一个小规模的数据集,其中包含了30个独特CVE对应的60个代码函数(30个正样本和30个负样本)。对于该数据集中每一个案例,我们都进行了人工验证工作以确认其是否存在来自其他CVE的相关漏洞特征信息存在于知识库之中。经过实验测试,Vul-RAG模型在该测试集上的性能表现(即召回率高达0.83、精确率达到0.76)充分证明了这种特征提取机制能够在不同CVE场景下展现出良好的泛化能力。

8 相关工作

以深度学习为基础的漏洞探测研究

基于LLM的安全漏洞检测

9 结论

在本工作中, 我们开发了一种创新的漏洞检测技术Vul-RAG, 该技术通过结合知识级检索与增强生成框架, 有效识别并定位代码中的潜在安全问题. 实验研究表明, 相较于四个具有代表性的基准模型,Vul-RAG在实际应用中展现出显著优势（具体表现为准确率提升了约13%, 配对准确率增长了110%）. 用户调研数据显示, 利用漏洞知识能够将人工检测效率从60%提升至77%, 同时用户的反馈也证实了生成的知识在帮助性、精确性和通用性等方面的卓越性能.