1.本文主旨:
这篇论文探讨了使用大型语言模型(LLM)进行零射击漏洞修复的方法。人类开发人员编写的代码可能存在网络安全漏洞,新兴的智能代码补全工具是否能帮助修复这些漏洞呢?在本文中,作者研究了大型语言模型(如 OpenAI 的 Codex 和 AI21 的 Jurassic J-1)在零射击漏洞修复中的使用。他们研究了如何设计提示来引导 LLM 生成不安全代码的修复版本,这由于自然语言在语义和句法上有很多种表达方式而变得困难。作者对五个商业可用的、黑盒的、“开箱即用”的 LLM 以及一个开源模型和本地训练的模型进行了大规模研究,在合成、手工制作和真实的网络安全漏洞场景中进行测试。他们的实验表明,尽管该方法具有前景(这些 LLM 能够修复我们合成的和手工制作的所有场景),但通过对历史真实世界示例的定性评估,生成功能正确代码方面仍然存在挑战。
在这篇论文中,"Zero-Shot"指的是在没有进行特定领域或任务的训练的情况下,使用大型语言模型(LLMs)来执行特定任务。具体而言,作者研究了大型语言模型在修复软件漏洞时的零-shot能力,即在没有专门对安全漏洞修复进行训练的情况下,通过构建适当的提示来引导LLMs生成修复漏洞的代码。这种零-shot方法使得LLMs能够在没有专门训练的情况下理解和生成特定领域的任务。
1. 选择漏洞问题和场景设计:选择了多个高影响力的漏洞问题(根据MITRE的“Top 25”列表)作为实验场景,并设计了各种不同的场景,包括Python Web开发和C缓冲区和指针等不同层级的漏洞。
第一阶段是模型参数扫描,以识别用于LLM代码修复生成的良好“典型”参数
第二阶段调查提示,以确定随着“错误上下文”的增加,不同的提示模式是否会对黑盒llm生成的代码质量产生影响:
先将有缺陷的程序(场景)提供给安全评估工具并生成缺陷报告;采用了CodeQL ,因为它能够静态分析几种类型的bug。从bug报告和原始程序中,我们得到了一个提供给LLM的提示。
2. 修复提示设计:通过分析CodeQL找出有漏洞的代码后,为每个场景设计了多个可能的修复提示模板。这些模板根据提供给LLMs的上下文信息的不同,包括不提供任何信息、提供详细注释和提示等等。设计了五个合理的模板。
3. 运行实验:使用五个商业可用的LLMs(OpenAI的Codex和AI21的Jurassic J-1等)以及一个开源模型和本地训练的模型,对一系列合成的、手工制作的和真实世界的安全漏洞场景进行了大规模实验。评估LLMs生成修复代码的表现。
4. 结果分析:实验结果显示,LLMs在处理合成和手工制作的场景时表现出了潜力,能够修复100%的场景。然而,在对历史真实世界案例进行定性评估时,发现生成的代码在功能上存在一定的问题。
我的思考:
1.温度是怎么影响代码的?在本文的实验中,温度是影响大型语言模型(LLM)生成代码的一个参数。温度控制了生成的代码的多样性和随机性。较高的温度值会增加生成的代码的多样性,而较低的温度值会使生成的代码更加确定和保守。具体来说,对于修复安全漏洞的实验,较高的温度值可能会导致生成的修复代码变得不安全或不正确,而较低的温度值可能会导致生成的修复代码过于保守或不创新。 在论文中,作者在温度值为{0.00, 0.25, 0.50, 0.75, 1.00}的范围内进行了实验,以探究不同温度值对LLMs生成修复代码质量的影响。他们发现合适的温度值可以提高修复代码的质量,并在实验中对修复代码的准确性和安全性进行了评估。 总之,温度是调整LLMs生成修复代码的重要参数,不同的温度值可以对生成的代码多样性和质量产生影响。在实验中,作者通过调整温度值来探索最佳参数配置,以获得高质量的修复代码。
2.本文(2023-5)和Automated Repair of Programs from Large Language Models(2023-5)的区别:设计了三种构建Codex-e编辑指令的策略:
- Codex-e :告知Codex-e存在程序中的错误并请求其修复。
- Codex-e :利用现有的自动程序修复技术,通过统计故障定位(Ochiai)获取可能修复行的序列,作为修复提示提供给Codex-e。
- Codex-e :直接使用可疑语句而不是可疑行号作为指令,进一步探究Codex-e的响应。它们都是想要利用大语言模型来修复代码漏洞,并且思想都是给语言模型生成一些提示,来调节生成补丁,它们有什么本质的不同呢?还需要我再思考一下。