Chain-of-Thought Prompting of Large Language Models for Discovering and Fixing Software Vulnerabilit

今天分享的论文是：Chain-of-Thought Prompting of Large Language Models for Discovering and Fixing Software Vulnerabilities

原文链接： https://arxiv.org/pdf/2402.17230

数据集和源代码：Assessing and Improving Prompting Large Language Models for Software Vulnerability Analysis

这篇论文是关于如何考虑思维链应用于漏洞识别、漏洞检测和漏洞修复三个任务场景，论文的创新性不是胜在方法和框架上，而是实验的完备性上。

安全漏洞在现代软件中越来越普遍，对社会产生 了广泛的影响。人们提出了各种防御这些漏洞的方法， 其中深度学习(DL)避免了其他技术的主要障碍， 因此近年来受到了更多的关注。然而，基于 DL 的方法 面临着严峻的挑战，包括缺乏大规模和质量标记的特定 于任务的数据集，以及它们不能很好地推广到看不见的 真实世界场景。最近，大型语言模型(LLM)通过克服这 些挑战，特别是通过思维链(CoT)提示，在各个领域显 示出令人印象深刻的潜力。在本文中，探讨了如何 利用 LLMs 和 CoT 来解决三个关键的软件漏洞分析任务: 识别给定类型的漏洞，发现任何类型的漏洞，以及修补 检测到的漏洞。通过统一漏洞语义引导提示 方法 VSP，在这些任务的上下文中实例化一般 CoT 方 法，并针对三个 LLM 和两个数据集进行广泛的实验，评 估 VSP 与三个任务的五个基线。结果显示了 CoT 启发的提示相对于基线的实质性优势(在 CVE 数据集 上，漏洞识别、发现和修补的 F1 准确率分别提高了 553.3%、36.5%和 30.8%)。通过分析 VSP 故障的深入案 例研究，本文还揭示了 LLM/CoT 在挑战性漏洞案例中的 当前差距，同时提出并验证了相应的改进。

已经提出了多种防御性软件漏洞分析方法，包括基于静态/动态程序分析的方法[5, 42]、两者结合的方法[60]，以及数据驱动的方法（尤其是机器/深度学习方法）[11, 64]。这些技术在针对漏洞的各类主要防御任务中展现了各自的优点，包括识别特定类型的漏洞[3]（例如内存泄漏[13, 43]、使用后释放（use-after-free）[10, 57, 71, 79]、双重释放（double-free）[10]、跨站脚本攻击（XSS）[73]和缓冲区溢出[26, 40, 67]）、发现各种类型的漏洞[9, 20, 22, 27, 30, 38, 44, 47, 53, 56, 68, 81, 86]，以及修复已检测到的漏洞[12, 21, 24, 51, 65, 85]。

然而，这些技术类别各自都面临着主要挑战。特别是，纯静态技术（例如[13, 38, 43]）受到底层静态分析过度不精确性的困扰[60]，导致误报率较高，这是实际应用中的一个关键障碍[34]。此外，由于现代程序中动态语言构造的普遍使用[44]以及对大规模代码库的可扩展性有限[42, 60]，纯静态技术还可能存在不健全性。纯动态技术（例如[9, 27, 56]）和混合技术（例如[68]）的能力则受到现有程序输入覆盖范围的限制，这通常是不充分的，因此可能会遗漏潜在的严重漏洞（即召回率较低[60]）。

在本文中，我们通过提示 LLM，在漏洞识别、发现和 修补任务的上下文中实例化一般 CoT 方法，来系统地探 索防御性软件漏洞分析。在这三个任务的基础上，我们 提出了漏洞语义引导的提示(VSP)，这是一个统一的 CoT 启发的提示策略，它将漏洞语义(即，使其易受攻击的 易受攻击程序的行为)映射到思想链。全部代码语义由 所有常规数据和控制流依赖关系表示[2 在程序中，漏洞 语义由那些捕捉(即，说明)易受攻击行为的依赖关系的 子集来表示。因此，VSP 将漏洞语义下的数据/控制流事 实公式化为“思想”,并将相应的流路径公式化为 CoT 中的“链”。在作为统一方法的 VSP 之上，我们进一步 为每个单独的任务提出了具体的提示方案；但是所有这 些方案都是由漏洞语义指导的。 然后，我们进行了广泛的实验，检查 VSP 相对于五个 基线的有效性，包括 VSP 的两个变量，基于全代码语义 的提示策略(即，CoT 的简单实例化)，少数镜头学习和标准提示。通过针对三个 LLM 和两个数据集的这六个策 略，我们比较了针对三个漏洞分析任务直接利用或获取 各种 LLM 的(现有)知识的不同方式。我们的结果表明， 在只有几(20)个样本的情况下，VSP 在三个任务中的任 何一个任务上都远远超过了基线方法，尤其是在更具挑 战性的数据集上。例如，对于漏洞识别，我们的方法在 合成数据集上实现了 65.29%的 F1，在真实世界(CVE)数 据集上实现了 58.48%的 F1，而最佳(非 VSP)基线在 GPT-3.5 上分别只实现了 56.28%和 8.96%18].对于漏洞 发现，VSP 在合成数据集上实现了 54.07%的 F1，在 CVE 数 据集上实现了 45.25%的 F1，而最佳基线在 Llama2 上分别 实现了 52.04%和 33.16%69].对于漏洞修补，VSP 的这些 数字分别为 97.65%和 20.00%，而同样在 GPT 3.5 上， 最佳基线的这些数字分别为 96.47%和 15.29%。VSP 还帮 助 发 现 了 22 个 真 正 的 零 日 CVE 漏 洞 ( 准 确 率 为 40.00%)，而标准提示基线仅发现了 9 个漏洞(准确率为 16.36%)。

此外，我们进行了深入的案例研究来分析 VSP 遇到的 失败，并确定了这三项任务中的四个常见根本原因。例 如，对于漏洞识别和修补任务，以及潜在的误报和漏 报，主要的失败原因是在馈送给 LLMs 的代码片段中代 码上下文不足(例如，缺少关于代码中调用的自定义/外 部函数的信息)。另一个主要的根本原因，也是漏洞发 现失败的主要原因，是 LLM 在推理过程中遗漏了作为漏 洞语义一部分的重要控制流事实。相比之下，缺少关键 数据流事实是另一个主要的失败原因，但对于漏洞发现 而言，这比识别或修补漏洞更成问题。我们进一步提出 改进来克服这些失败的原因，并展示我们的建议的有效 性(例如，通过代码注释弥补不充分的上下文)。 据我们所知，我们的工作是第一个系统地研究如何在 防御软件漏洞分析中利用提示 LLM 完成所有三个代表性 任务的工作。通过 VSP，我们还展示了一个有希望的方 向，通过漏洞语义来指导 LLM，从而引出 LLM 知识来推 理程序中使其易受攻击的最基本的行为。我们广泛的实 验和讨论表明，这一方向可以将软件漏洞分析的有效性 推向一个新的高度(超过迄今为止最好的基于 DL 的方 法)。通过我们的失败案例研究和推荐的解决方案，我 们也为将来使用 LLMs 改进脆弱性分析的方法做出了贡 献 。

三个任务的VSP基本图示：

即时工程。最近的 LLM 如 GPT-3.5 [18]在各种任务中表 现出色 15,36,49,72,76].用户可以通过类似“下面的代码 是否有 bug”这样的自然语言提示，直接要求 LLMs 解决某 个问题。最近的研究[58,65 提示策略显著影响学习者的 学习成绩。为了更好地利用 LLM，促进工程[77]寻求优 化提示成为一个至关重要的话题。在快速工程中，少量 的学习 8]也可以通过一些期望输入和输出的例子来提高 性能。 思维链提示。在激励工程与少量学习中，思维链(CoT) [75]通过在样本中提供中间推理步骤，在复杂的推理任 务中显示出巨大的潜力。它在算术推理和符号推理等不 同的任务上是有效的 75].此外，零距离思维链通过直 接显示问题中的推理步骤而不提供样例，在某些任务中 也是有效的 37]. 使用 LLMs 进行脆弱性分析。LLM 已经被开发用于漏洞分 析任务，例如漏洞发现[58]，修复[65]，以及安全代码 生成[28].然而，这些工作使用简单的提示，并将所有 的脆弱性分析推理过程留给 LLMs。由于这些任务需要复 杂的推理步骤，如漏洞定位和全面的控制/数据流分 析，简单的提示可能不够有效。就其本质而言，CoT 似 乎很适合这里，但是如何适应仍然是未知的，最大限度地发挥其在软件脆弱性分析中的潜力，这也是 本文的目的。

在这一节中，我们将介绍漏洞分析的统一提示策略。然 后，我们描述了所考虑的三个分析任务和基于统一策略 的特定于任务的提示方案。请注意，我们的主要目标是 探索如何有效地提示 LLM 进行漏洞分析，从而提供有关 潜在/差距的证据和可操作的见解，为未来的技术开发 提供信息，而不是在此开发可部署的工具。最后，我们 描述了我们在这项研究中使用的数据集和 LLM，以及我 们实验的设计和实现。well 3.1 受 CoT 启发的漏洞语义引导的提示 75]，我们提出了 漏洞语义引导的提示(VSP ),它也实例化了一般的 CoT 方法。该策略专注于漏洞语义，这是有效漏洞分析的关 键组成部分。这种设计基于两个关键的观点:(1)虽然一 个程序可能包含许多行代码，但只有一小部分容易受到 漏洞的影响。因此，以这些关键片段为中心，构成漏洞 语义，使 LLMs 能够最大程度地进行漏洞分析；(2)主流 LLM 基于 Transformer [70]，众所周知，当处理/生成 大量文本[62].因此，专注于漏洞语义有助于缩减样本、提 示和答案的长度，减少对 LLM 的潜在干扰。 漏洞语义。鉴于只有一小部分代码可能导致漏洞，定位 (可能)易受攻击的语句至关重要，因为这些语句是漏洞 语义的核心。然而，如果没有适当的背景，这种陈述本 身不会导致漏洞。对于全面的漏洞分析，可能涉及漏洞 行为的具有控制和数据流关系的上下文语句也很重要 [59,60].因此，我们将漏洞语义定义为易受攻击语句及 其相关上下文语句的行为。这避免了包含所有的代码语 义，并帮助 LLM 关注关键部分。 数字 1(a)显示了一个涉及释放后使用和空指针取消 引用漏洞的示例，其中标记了漏洞语义。为了理解语 义，我们首先找到可能有这两个漏洞的语句，它在第 8 行使用了一个用青色标记的指针。然后，我们找到与第 8 行具有数据和控制流依赖关系的语句:第 2 行和第 6 行 具有可能导致空指针解引用和释放后使用漏洞的数据流 关系，如红色虚线箭头所示。第 6 行和第 7 行具有可能 导致释放后使用漏洞的控制流关系，如红色箭头所示。 因此，第 2、6 和 7 行构成了上下文，用黄色标记。因 此，第 8 行和上下文一起构成了漏洞语义。 激励策略。在漏洞语义的指导下，我们利用基于 CoT 的 少镜头学习来实现 VSP。每个 VSP 提示符由两部分组 成。第一部分是几个样例的集合，为模型执行少量学习 提供推理步骤的示例。具体来说，每个样本由任务的一 个问题、一个代码样本和问题的答案(包括推理步骤)组 成。答案中的推理步骤集中在上面讨论的漏洞语义上。 第二部分是我们希望模型分析的测试样本。在测试样本 中，我们提出的问题与范例中的问题具有相同的格式。 然后，我们期望 LLMs 按照样本中基于漏洞语义的推理 步骤输出答案。 在我们的研究中，VSP 策略为不同的漏洞分析任务奠定 了基础。数字 2 说明了总体设计:我们使用 VSP 作为每个 任务的详细提示方案下的统一/通用策略。请注意，我 们打算检查每个任务的 VSP 潜力—这些任务是正交的， 每个任务都假设它需要假设的内容，而不是基于前一个 任务的输出。我们的目标不是开发一个全面的漏洞分析 系统(例如，从识别开始，然后打补丁)。

3.2 任务 在这项工作中，我们解决了三个软件漏洞分析任务:(1) 漏洞识别(确定一个给定的代码样本是否具有特定类型 的漏洞)，(2)漏洞发现(在不指定其类型的情况下发现 代码样本中的潜在漏洞)，以及(3)漏洞修补(根据漏洞 样本和漏洞类型及位置创建修补程序)。这些任务跨越 不同级别的漏洞分析，代表了防御软件漏洞的关键步 骤。 接下来，我们分别描述这三项任务的目标、制定和具 体的激励方案。 3.2.1 任务 1:漏洞识别 目标。漏洞识别的目标是确定给定代码样本是否具有特 定类型的漏洞(例如 CWE)，因为漏洞检测器是否能够找 到特定类型的漏洞决定了它的有效性。配方。我们将脆 弱性识别公式化为一个二元分类任务。在 LLM 输入提示 中，我们以文本形式提供了一个代码示例，并询问模型 给定的文本是否存在 CWE-xxx 漏洞，其中 CWE-xxx 是漏 洞类型的 CWE ID。 提示。如第节所述 3.1，我们在每个提示中提供了漏洞 识别的示例和测试样本。如图所示 1(b)示出了，对于每 个样本，我们提出弱点识别的问题:“问:下面的代码有 CWE-xxx 弱点吗？”。除了问题本身，我们还要求模 型:“请关注最有可能存在漏洞的部分。”这是为了引导模 型关注漏洞语义。然后，我们提供代码进行分析。为了清 楚起见，每个样本的答案部分都包括对 CWE ID 含义的解 释。然后，我们根据漏洞类型找到可能的漏洞语句，并根 据漏洞控制和数据流关系找到它们的上下文。我们分析上 下文的条件，并决定代码是否有特定类型的漏洞。最后， 我们通过询问与样本中相同的问题来提供测试样本，让模 型输出它的响应。 3.2.2 任务 2:漏洞发现 目标。在这个任务中，要求 LLM 在没有 CWE id 的情况下发 现可能的漏洞。这有助于评估它们的实际适用性。在现实 世界的软件漏洞分析中，开发人员通常缺乏给定代码中特 定漏洞及其对应的 CWE id 的先验知识。因此，漏洞分析技 术需要查明潜在的漏洞并对其类型进行分类。配方。我们 将漏洞发现公式化为一个多类分类任务。给定文本形式的 代码样本，我们询问模型代码是否有漏洞，如果有，代码 有哪些 CWE。提示。如图所示 1(c)显示，在每个样本中，我们提出了 漏洞发现的问题:“问:下面的代码易受攻击吗？如果 有，它有哪些 CWE？请重点关注最容易受到攻击的部 分。”然后，我们提供代码示例。在回答中，我们列举 了可能易受攻击的语句类型，并在代码中找到它们。对 于每个潜在的易受攻击的语句，我们根据相关的漏洞控 制和数据流关系来识别相关的上下文。最后，我们对漏 洞语义进行分析，以确定漏洞的存在，以及它们相应的 CWE(如果有的话)。随后，我们用样本中提出的相同问 题来呈现测试样本，让模型提供它的响应。 3.2.3 任务 3:漏洞修补 目标。此任务的目标是在保留代码功能的同时消除代码 中的漏洞。这是至关重要的，因为它解决了代码的安全 问题，避免了对系统可能的攻击和破坏。 配方。我们将漏洞修补表述为文本到文本的转换任务。 给定文本形式的易受攻击的样本，我们要求模型生成补 丁。我们直接告诉模型易受攻击的线和各自的 CWE，这 对于 bug/漏洞修补是常见的[12,21,24].有了易受攻击 的代码示例、易受攻击的行和 CWE ID，模型只根据更改 的行(而不是整个修补的示例)来输出修补程序。 提示。如图所示 1(d)示出，在每个样本中，我们要求模 型为给定代码生成补丁 :“ 给定以下易受攻击的代 码:“’”，其具有 CWE-XXX(< CWE 的描 述>)易受攻击性。特别是，该漏洞出现在以下行 :< vulnerable line >。请提供有效的补丁，仅显示所需的代码更 改，而不是整个补丁代码。“在回答中，我们基于其语义 分析了漏洞的根本原因。然后，我们评估修补策略，并确 定通过代码编辑修复漏洞的纠正措施。最后，我们提供了 一个测试样本，带有与范例中相同的问题，让模型给出它 的响应。

如上图所示为面向漏洞分析任务的漏洞语义引导提示（Vulnerability-semantics-guided Prompting）概述。

3.3 数据集 在这项研究中，我们针对 C/C++代码中五个最危险的 cwe， 手动构建了基于 CoT 的少镜头学习的样本[1]: (1) CWE787(越界写入)，(2) CWE-125(越界读取)，(3) CWE476(空指针取消引用)，(4) CWE-416(释放后使用)，以 及 (5) CWE-190( 整 数 溢 出 ) 。 我 们 关 注 C/C++ 是 因 为 C/C++漏洞涵盖了主要的漏洞类别，它们是最易受攻 击的语言[60].对于每个 CWE，我们提供四对样本，每对 包含一个易受攻击的样本和一个相应的修补样本。这导 致总共 20 对。样本的灵感来自 CWE 报告网站上的示例 [1].我们使用上面描述的策略来编写各自的样本。 我们使用两个测试数据集来评估这三个任务。第一个 是被称为 SARD 的合成数据集[7]，包含大量易受攻击的 和相应的非易受攻击的样本。第二个是 Fan 等人收集的 真实世界漏洞数据集[16]，来源于 CVE 报告[55]，提供 易受攻击的和各自修补的代码示例。我们只关注与上述五 种 cwe 相关的样品。考虑到商业 LLM(例如 GPT-3.5)的成本 和时间消耗，我们只为每个测试数据集选择 500 对样本。 我们使用两个数据集，因为我们想评估的困难使用 LLMs 分析简单/合成样品和复杂/真实样品，帮助 我们获得更深入的见解

3.4 模型

表1总结了我们在研究中使用的三种最新大型语言模型（LLM），包括模型版本、规模和令牌限制。特别是，GPT-3.5 [18] 是OpenAI推出的一款主要大型语言模型，能够理解和生成自然语言和代码。由于GPT-4价格高昂，我们选择了GPT-3.5-Turbo。Llama2 [69] 是Meta AI推出的最新大型语言模型。由于我们机器的资源限制，我们选择了llama-2-7b-chat-hf版本。出于同样的原因，我们选择了来自技术创新研究所的Falcon [88]的falcon-7b-instruct版本。虽然这些模型在其家族中并非最先进或能力最强的，但我们的选择应该不会影响本研究旨在实现的目标。

3.5 基准方法

除了漏洞语义引导提示（VSP）外，我们还考察了以下五种基准方法：

• 标准提示（Standard Prompting）：我们要求大型语言模型在不提供任何示例或指导的情况下完成任务，旨在评估它们的原始/固有潜力。
• 标准少样本学习（Standard Few-Shot Learning）：对于每个示例，我们只提供最终答案，而不提供任何推理步骤。这是为了测试改进（如果有的话）是否来自示例中的推理步骤，而非最终答案。
• 朴素思维链（CoT）少样本学习：我们不关注漏洞语义，而是逐行分析代码以完成任务。这是为了测试VSP策略是否优于全语义分析。
• 零样本VSP提示（Zero-Shot VSP Prompting）：我们不提供示例，但在提示中提供了基于VSP的漏洞分析步骤。这是为了测试提供示例是否能提高模型的推理能力。
• 其他类型VSP提示（Other-type VSP Prompting）：我们确保所使用的示例在涵盖的通用弱点枚举（CWE）方面与任何测试样本都不重叠，以评估从示例中激发的大型语言模型的推理能力是否可以跨不同漏洞类型进行迁移。

讨论与分析：

7.1 零日漏洞发现

为了评估漏洞语义引导提示（VSP）检测近期零日漏洞的能力，我们选择了一个较旧的大型语言模型“GPT-3.5-Turbo-0301”，该模型在2023年3月1日之后未进行更新。随后，我们从CVE/NVD数据库[55]中收集了自2023年3月1日之后报告的来自19个关键软件项目（如Linux内核）的55个漏洞样本。采用我们的VSP提示策略，该模型在40.00%的准确率下正确发现了22个真正例漏洞。在不使用VSP的情况下，仅准确检测到9个漏洞，准确率仅为16.36%。附录中的表16展示了这些漏洞的详细列表。这证明了我们的VSP策略在辅助大型语言模型发现零日漏洞方面的潜力。

7.2 为什么VSP有效

VSP提高大型语言模型漏洞分析有效性的主要原因是，它使模型能够专注于对理解漏洞最为重要的部分，即本研究中的漏洞语义。图3展示了一个例子，其中GPT-3.5在使用VSP时正确识别了CWE476漏洞，但在使用标准提示时则未能识别。在使用标准提示时，GPT-3.5只是简单地扫描代码，并注意到有检查确保指针不为NULL，因此它预测代码不存在漏洞。然而，它并未进一步分析指针解引用及其上下文。实际上，虽然第10行的检查确保了ctx.match_data.cmp不为NULL，但并未确保ctx.match_data不为NULL。如果不关注代码的这一部分，很容易忽略这个漏洞。相比之下，在使用VSP时，GPT-3.5专注于代码的这一部分，并注意到指针ctx.match_data的解引用可能为NULL。在这种情况下，模型正确识别了漏洞。这表明关注漏洞语义是VSP效果更好的主要原因。

VSP更有效的另一个原因是，它消除了可能在推理步骤中分散大型语言模型注意力的无关信息。这可以从我们的结果中看出，即朴素思维链（CoT）学习的性能不如VSP。在使用朴素CoT学习时，无论代码行是否与漏洞相关，都会逐行分析代码，从而导致注意力分散，进而削弱了所需的核心推理。

为了进一步证实第二个原因，我们进行了一项关于漏洞发现的实验。在示例中，我们不仅推理了与样本特定的漏洞，还推理了其他常见的漏洞类型。图4展示了一个与图1(c)相关的额外文本实例。包含这些不必要的信息会使GPT-3.5在CVE数据集上的微平均F1值从36.34%降低到26.37%，宏平均F1值从36.89%降低到17.02%。这强调了在推理过程中消除无关细节对于VSP达到良好效果的重要性。

7.3 失败原因及建议

7.3.1 上下文信息不足

我们发现，由于上下文信息不足，大型语言模型（LLMs）在处理现实世界样本时常常出现分析失败的情况。现实世界中的项目通常规模庞大，涉及众多函数和文件，许多漏洞是跨过程的。如果仅提供一个函数进行分析，漏洞分析就会变得困难重重。然而，鉴于大型语言模型一次只能处理有限数量的标记（例如，GPT-3.5 最多处理 16K 个标记），不太可能将整个项目输入模型进行分析。
因此，针对这一问题的一个可能解决方案是在代码中提供上下文信息（例如，通过添加代码注释）。例如，当在分析的函数中调用外部函数时，可以添加注释说明该外部函数的作用，以及在该函数中已采取或未采取哪些安全保障措施。附录中的图 5 展示了为外部函数调用添加注释的示例。采取这种方式后，原本的分析失败问题得以避免。

7.3.2 忽略通用弱点枚举（CWE）

我们发现，大型语言模型偶尔会“忘记”正在分析的 CWE，这可能是由于输入和输出文本过长（在 4.3 节中已讨论）。为了验证这一点，我们对 CVE 数据集中不同失败原因的代码长度进行了分析，结果如表 8 所示。表现出“忽略 CWE”情况的样本平均长度明显高于其他样本。这表明，“忽略 CWE”的情况更有可能出现在较长的代码样本中。
针对这一问题，一个潜在的解决办法是在代码样本之后重新提出问题，并明确界定 CWE 的含义。附录中的图 6 提供了一个漏洞识别的示例。采取这种方式后，生成的文本更贴近问题中明确含义的 CWE 标识符，从而避免了“忘记”问题。

7.3.3 控制流和数据流分析不完整

我们发现，虽然大型语言模型在一定程度上具备理解代码语义和进行基于代码的分析的能力，但在进行全面、深入的控制流和数据流分析方面，它们仍不及传统的静态/动态分析技术。现实世界中的代码复杂多样，包含各种控制流结构（例如分支结构）以及变量定义/使用情况，仅依赖大型语言模型是不够的，因为这可能导致推理过程过长。
因此，对于高级漏洞分析，我们建议将传统的代码分析技术与基于漏洞搜索模式（VSP）的方法相结合。具体而言，可以使用静态代码分析工具提取（潜在）漏洞行的上下文，因为实际的漏洞上下文可能距离这些行较远。

7.4 与近期工作的比较

与基于大型语言模型（LLM）工作的比较

Pearce 等人[65]最近研究了利用大型语言模型进行零样本漏洞修复，他们在自动生成、手工制作和现实世界的数据集上开展了实验。他们评估了各种零样本提示策略和参数配置。然而，他们的数据集是专门为漏洞修复测试量身定制的，相对较为简单。此外，他们的现实世界数据集在提示中直接包含了编辑后的代码行，这在实际应用中不太现实。相比之下，我们的研究在公开可用的数据集上，以现实条件对大型语言模型进行了评估，仅提供存在漏洞的代码行。此外，我们新颖的提示策略聚焦于漏洞语义并采用示例，对大型语言模型的潜力和局限性进行了全面评估。

与基于传统深度学习（DL）工作的比较

基于深度学习的漏洞分析在检测和修复方面都展现出了令人瞩目的有效性[11, 20, 48, 53, 86]。然而，由于不切实际的测试设置，例如使用部分训练集进行测试[64]，这些技术的性能常常被高估。当在独立的（未见过的）现实世界测试集上进行评估时，这些技术的表现会大幅下降，检测技术的 F1 值最高仅为 16.43%，修复技术的 top-1 准确率最高仅为 8.55%[61]。缓解性能不佳的一种方法是数据增强[62, 63]。然而，即使使用最新的数据增强技术，用 15,039 个高质量的漏洞样本和更多的正常样本对训练数据集进行增强后，这些数值在检测方面仅提高到 20.1%，在修复方面仅提高到 21.05%[61]。相比之下，漏洞搜索模式（VSP）在漏洞发现（比他们的二元检测更具挑战性）方面 F1 值最高可达 48.35%，在使用仅 20 个示例进行补丁修复时 top-1 准确率最高可达 20%。虽然我们的现实世界测试数据集与[61]中的不同，但基于大型语言模型的 VSP 在漏洞分析方面展现出了比现有基于深度学习的方法更好的潜力。

做个总结：

本文进行了第一次广泛的研究，探索如何通过漏洞语义引 导提示(VSP)来利用 LLMs 进行软件漏洞分析的潜力。受思 维链(CoT)提示的启发，VSP 在向 LLM 演示漏洞分析推理步 骤时，重点关注导致漏洞的最基本的程序行为。本文在两 个数据集和三个 LLM 上对三个具有代表性的软件漏洞防御 任务(识别、发现和修补)的实验和案例研究揭示了 VSP 相 对于五个基于 LLM 的方法作为基线的显著优点。