这篇文章翻译自 CAN LARGE LANGUAGE MODELS FIND AND FIX
VULNERABLE SOFTWARE? 大型语言模型能否实现软件漏洞的检测与修复？
先说说结论和一些有意思的发现，以及这篇文章最重要的一个点：
那肯定是可以的，
- 此前实验已证实GPT-4的漏洞检出率是Snyk的4倍（393 vs 99），修复后漏洞减少90%
- PHP/JavaScript高危漏洞集中修正案例佐证LLMs跨语言修复能力
- 参数规模（1750亿+）与误报率（4/213）的量化关系支撑技术可行性结论
对于LLMs的最大争议：其输出常因底层基于"下一词预测"的优化机制而被认为不可靠或易产生幻觉。尽管OpenAI在聊天界面明确声明"ChatGPT可能生成关于人物、地点或事实的不准确信息"，但本研究探索了一种自反式验证机制------要求模型为识别的漏洞提供修复方案，迫使其重新评估初始结论。这种"漏洞-修复匹配"的良性循环，为LLMs与传统静态代码分析工具的协同提供了理论支撑。
啥意思，就是想要减少大模型的幻觉，我们可以让他在识别漏洞的过程中让他给出补丁的修改方案，这样可以有效抑制LLM的幻觉。这个我觉得是本文中最重要的一个发现。
本文摘要
在本研究中，作者评估了大型语言模型（LLMs），特别是OpenAI的GPT-4在检测软件漏洞方面的能力，并将其性能与Snyk、Fortify等传统静态代码分析工具进行对比。我们的分析覆盖了包括美国国家航空航天局（NASA）和国防部在内的多个代码仓库。结果显示，GPT-4发现的漏洞数量约为传统工具的4倍，且对每个漏洞均能提供可行的修复方案，同时展现出较低的误报率。
实验测试了涵盖8种编程语言的129个代码样本，其中PHP和JavaScript代码的漏洞率最高。通过GPT-4的代码修正，漏洞数量减少90%，而仅需增加11%的代码量。研究还发现LLMs具有自我审查能力：其不仅能识别漏洞，还能主动建议修复方案，体现了精准的检测能力。未来研究应着重探索系统级漏洞检测，并整合多种静态代码分析工具，以全面评估LLMs在软件安全领域的潜力。
引言
随着软件系统日益复杂且无处不在，确保其安全性需要更先进的方法。传统的基于规则的静态代码分析工具（如HP Fortify或Snyk）虽在识别软件漏洞方面发挥了重要作用，但其规则驱动特性可能导致遗漏某些细微或不断演变的威胁[1-9]。以OpenAI的ChatGPT为代表的大型语言模型（LLMs）[10-29]为应对这一挑战提供了新途径。通过海量文本数据训练，LLMs已展现出理解和生成代码的潜力，表明其可能擅长定位并修复软件漏洞[10,16]。
近期研究揭示了LLMs在安全漏洞检测方面的能力，有时甚至超越传统方法[2,3]。例如，某LLM在单一代码库中识别出213个安全漏洞，凸显其作为安全工具的潜力[2]。此外，LLMs已被应用于多种编码场景------从可视化编程到Java函数开发，常显示出对代码生成与理解的精通[18,21]。更值得注意的是，LLMs展现出强大的适应性，能够应对代码演化、高性能计算及自协作代码生成等复杂挑战[25,26,27]。
在本文中，我们全面审视LLMs在识别与修复软件漏洞方面的表现。通过使用LLMs和传统代码分析工具对GitHub上大量代码库进行检测，我们旨在对比两者在解决软件安全问题上的效能。这一对比将揭示LLMs在软件漏洞检测与修复中的优势与局限。如表1所示，我们从目标定位和设计理念维度对两种方法的软件漏洞识别能力进行了系统比较。
尽管部分评估表明ChatGPT在漏洞检测中具备潜力，但大型语言模型（LLMs）对软件安全的更广泛影响仍待探索[28]。随着软件生态的持续发展，将LLMs与传统方法结合利用，可能为构建更安全、更健壮的系统开辟新路径。本研究旨在推动这一前沿讨论，明晰LLMs在软件安全领域的实际定位。此前研究[20-27]多关注LLMs基于文本描述生成代码的能力，而本文扩展了漏洞识别工作[2-3, 28]，纳入漏洞缓解措施与修复方案。
我们将测试数据集从传统编程漏洞（如缓冲区溢出、命令注入）扩展至分析公共科学项目代码库，包括NASA飞行系统[30]、国家地理空间情报局[31]、国防部挑战项目[32]、Android战术突击套件（ATAK）[33]、前沿AI视觉项目[34]，以及微软研究院的智能体与强化学习库[35]。通过超越单一编程案例的局限，我们试图与科学界建立联系[29]------这些领域的研究者常借助协作编码工具提升技能，但自身未必追求成为专业开发者。这一群体可通过个性化编码助手直接激发数学、物理、化学、生物学及软件工程[16]等领域的问题解决新思路[9,26-27,29]。
以下是表格内容的翻译：
| 对比维度 | 静态代码分析工具（如Snyk、Fortify） | 大型语言模型（LLMs） |
|---|---|---|
| 用途与设计 | 专为识别代码中已知的安全漏洞设计 | 旨在理解和生成类人文本（包括代码） |
| 代码表示形式 | 使用抽象语法树（AST）或控制流图（CFG） | 将代码表示为符号（Token）序列 |
| 学习与适应能力 | 依赖预定义规则和特征库；传统上不具备"学习"能力 | 通过训练数据持续学习；基于已识别模式动态适应 |
| 泛化能力 | 精准且特定，基于已知模式/特征库 | 可泛化至多种编码模式与风格 |
| 反馈与迭代 | 基于规则匹配的确定性反馈 | 提供上下文相关的描述性反馈 |
| 覆盖范围 | 受限于预定义规则/特征库 | 因泛化训练可能更广泛，但可能缺乏精准性 |
| 运行原理 | 基于规则 | 基于训练数据的模式识别 |
| 适应性 | 固定（除非更新规则） | 因模式识别能力而灵活 |
| 主要应用场景 | 安全漏洞检测 | 文本理解、生成及上下文推理 |
关键点总结：
- 静态工具：强在精准检测已知漏洞，但依赖人工规则更新，覆盖范围受限。
- LLMs：通过模式识别泛化能力强，适合灵活生成与推理，但可能牺牲部分精准性。
- 互补性：静态工具提供确定性结果，LLMs扩展可能性，两者结合或能平衡安全与创新。
本研究涵盖通过聊天接口自动调用的最新OpenAI模型（GPT-4），并为其设定系统上下文指令："作为适用于所有主流编程语言的全球最强大静态代码分析器。我将提供代码片段，你需要识别其语言并分析漏洞。输出格式要求：文件名、检测到的漏洞（编号列表）、建议修复方案（独立编号列表）"。我们将此上下文应用于OpenAI的7个不同参数规模的LLMs模型[37]，其参数跨度达四个数量级：
- 350M（Ada）
- 6.7B（Curie）
- 175B（达芬奇/GPT3/GPT-3.5-turbo-16k）
- 1.7万亿（GPT-4）
然而，较大模型的训练细节属于专有信息。例如，Curie模型基于数十GB的多语言GitHub软件仓库数据及OpenAI Codex源代码训练。实践中，当参数规模超过130亿时，模型开始展现出超越代码注释或基于训练数据记忆的自动补全能力，初步具备编程技能。自2023年2月相关研究[2]发表以来，多个GPT版本更新已证明参数规模数量级增长带来的显著进步。OpenAI通过一系列能力指标评估编码性能提升[10]，例如在（初级）LeetCode测试中，正确率从12/41（GPT-3.5）提升至31/41（GPT-4）。
关键要点：
- 模型规模与能力跃迁：参数规模从3.5亿到1.7万亿的跨越，驱动代码分析能力质变。
- 专有训练数据：大模型依赖多源代码库（如GitHub）和专有语料（如Codex）训练。
- 规模阈值效应：130亿参数成为基础编程能力出现的临界点。
- 性能量化评估：LeetCode测试分数等指标客观反映代际性能差异。
总结：
-
研究定位：
- 当前研究聚焦LLMs在漏洞检测与修复中的应用潜力，试图填补传统规则工具与新兴AI模型间的能力空白。
- 突破以往仅关注LLMs生成代码的研究局限[20-27]，新增漏洞缓解与修复分析维度[2-3,28]。
-
数据集扩展：
- 涵盖跨领域科学项目（如NASA、国防部、AI视觉等），验证LLMs在复杂实际场景中的适用性。
- 针对非专业开发者群体（如科研人员），探索LLMs作为协作工具在跨学科问题解决中的价值。
-
核心价值：
- 为LLMs与软件安全交叉领域提供系统性评估框架，推动学术界与工业界对AI驱动安全工具的认知升级。
- 强调LLMs的"辅助者"角色，助力科学界通过低门槛编码工具加速创新（如数学建模、工程问题优化）。
方法论
以下是这段话的翻译：
在所有测试案例中，我们通过API自动调用大型语言模型（LLMs），设定系统上下文指令以检测漏洞并提供修复方案，随后输入涵盖8种主流编程语言（C、Ruby、PHP、Java、JavaScript、C#、Go和Python）的代码样本。每次测试均要求LLM完成以下任务：识别编程语言、定位漏洞并提出修复建议。
安全漏洞统一代码库[2]包含128个代码片段，覆盖上述8种语言，涉及33类漏洞（从缓冲区溢出到敏感数据泄露）。其中50个案例聚焦PHP语言，主要针对文件包含漏洞和命令注入漏洞。
我们将GitHub上的6个公共代码仓库[30-36]提交至自动化静态代码扫描工具Snyk[1]进行分析。该工具被亚马逊AWS、谷歌、Salesforce、Atlassian和Twilio等数百万开发者及企业用户采用。这些多样化扫描旨在揭示LLMs可识别的海量漏洞（"发现能力"）及其跨语言问题的解决广度。
针对每个代码文件，Snyk提供漏洞智能仪表板，包含以下核心指标：
- 严重程度（严重、高、中、低）
- 优先级评分（0-1000）
- 可修复性（可修复、部分可修复、无法修复）
- 漏洞利用成熟度（成熟利用、概念验证、无已知利用、无数据）
- 状态（未处理、已修复、已忽略）
- 依赖项问题
在最终评估阶段，我们通过API将所有128个代码样本[2]自动提交至GPT-4，但此次指令仅要求生成修复后的代码。系统提示设定为："作为适用于所有主流编程语言的全球顶尖静态代码分析器，我将提供代码片段，你需要分析并重写代码以消除所有已识别的漏洞。无需解释，仅返回修正后的代码及其格式。"
将GPT-4返回的代码进行后处理并上传至可扫描的GitHub仓库后，我们将修复后的代码库重新提交至Snyk，与原始漏洞代码库进行对比。通过这一流程，评估旨在量化LLMs的自我纠错能力------不仅能自动化识别漏洞，还能通过代码重写实现全代码库的安全加固，且修复效果由第三方静态代码扫描工具客观验证。
静态代码分析工具与LLMs的对比案例
图1展示了静态代码分析工具（HP Fortify）与大型语言模型（OpenAI的GPT-4 2023年8月3日版本）的初步对比案例。两者均正确识别了Objective-C文件HtmlViewController.m中的3个漏洞。但GPT-4的独特之处在于：
- 解释能力：以通俗英语说明漏洞成因及攻击者如何通过用户输入利用漏洞。
- 修复方案：为每个漏洞提供3种修复建议，并生成修正代码------包括输入净化、文件读取后错误检查及字符串格式验证。
基准测试数据
安全漏洞统一代码库[2]的测试显示：
- GPT-3（text-davinci-003）识别出213个安全问题，远高于Snyk的99个（排除Snyk不支持的C和Go语言16个文件）。
- 随机抽样验证：在GPT-3报告的213个漏洞中随机检查60个，仅4个为误报；但两种工具（DaVinci和Snyk）均存在大量漏报。
当前研究结果
- Snyk：检测到98个漏洞，其中约三分之二为高危（高-66，中-20，低-12）。
- GPT-4（2023年8月3日API版本）：识别393个漏洞，几乎是DaVinci（213）的两倍、Snyk（99）的四倍。
- GPT-3-Turbo-16K：检测217个漏洞，与文献[2]中GPT-3结果一致。
- 低参数模型（如Curie、Ada）：仅重复行业术语，无法提出具体修复方案。这表明当参数规模达到60亿至1750亿时，OpenAI GPT系列模型开始具备显著的代码理解能力。
误报率验证
GPT-4提出的398个修复方案与其低误报率密切相关------要求模型生成修复方案迫使其必须验证漏洞存在的合理性，从而减少误判或虚构响应。图2按漏洞数量对129个文件排序后，展示了漏洞发现与修复建议的关联性。图表印证了一个关键原则：真实漏洞必须对应至少一个修复方案（某些情况下甚至多个）。
核心结论
- 规模效应：参数规模突破临界值后，LLMs的代码分析能力呈指数级提升。
- 修复即验证：要求生成修复方案可作为降低误报率的有效机制。
- 工具定位：静态工具擅长规则化检测，LLMs胜在上下文推理与灵活修复。
以下是这段话的翻译：
关键图表与数据解析
图3对比了GPT-4与Snyk在漏洞类型检测上的表现。在两类最高危漏洞（路径遍历 和文件包含）中，GPT-4发现的漏洞数量是Snyk的3-4倍，并为每个漏洞均提供了修复方案。
表2总结了LLM自动化代码修正的评估结果：
- 代码量变化：相较于原始漏洞代码库，GPT-4通过增加11%的代码行数（264行）实现了漏洞修复。
- 漏洞消减率：经Snyk评估，修正后高危漏洞减少94%（66→4），中危减少75%（20→5），低危减少92%（12→1）。总体漏洞数量从98个降至10个。
| 代码库及参考 | 代码行数(SLOC) | 严重© | 高危(H) | 中危(M) | 低危(L) |
|---|---|---|---|---|---|
| 原始GitHub仓库[2] | 2372 | 0 | 66 | 20 | 12 |
| GPT-4修正后仓库[38] | 2636 (+264) | 0 | 4 (-94%) | 5 (-75%) | 1 (-92%) |
图4展示了GPT-4按编程语言分类的漏洞发现与修复分布，其中PHP和JavaScript占检测总量的近半数。值得注意的是，GPT-4无需系统提示即可自动识别代码语言类型（如Python），这为复杂遗留系统的自动化分析提供了技术基础。
附录B以PHP编写的漏洞图片上传功能为例，并列对比了Snyk与GPT-4的分析结果，直观呈现LLM在上下文推理和修复建议生成上的优势。
核心结论
- 效率跃升：GPT-4以少量代码增量实现漏洞数量级减少，验证其修复方案的工程可行性。
- 语言泛化：跨语言自动识别能力突破传统工具的技术限制。
- 高危治理：对94%高危漏洞的精准消减，凸显LLMs在关键安全场景的应用价值。
以下是这段话的翻译：
现实场景大型代码库漏洞分析
为探索更具实际意义的大型复杂代码库，我们将GitHub上的7个公共仓库提交至Snyk进行扫描，其漏洞数量与严重性统计如表3所示。其中：
- 国防部Hack a Satellite（HAS）项目[32]：作为DEFCON黑客大赛预选挑战代码库，刻意保留潜在漏洞以测试攻防能力
- NASA软件验证与确认（VnV）工具[36]：Snyk检测出第二高的漏洞数量，凸显航天关键软件的安全隐患
| 代码库及参考 | 星标数 | 代码行数(SLOC) | 严重© | 高危(H) | 中危(M) | 低危(L) |
|---|---|---|---|---|---|---|
| 国防部卫星攻防项目[32] | 92 | 573万 | 59 | 209 | 274 | 4000 |
| NASA软件VnV工具-ikos[36] | 1800 | 4.4万 | 4 | 58 | 999 | 1300 |
| 国防部战术突击套件[33] | 650 | 144万 | 140 | 863 | 55 | - |
| NGA雷达卫星处理工具SarPy[31] | 195 | 14.4万 | 1 | 15 | 10 | - |
| Ultralytics YOLOv5[34] | 40900 | 1.5万 | 55 | 7 | - | - |
| 微软网络攻防模拟器[35] | 1500 | 8000 | 3 | 6 | - | - |
指标说明：
- 星标数：反映项目流行度，数值越高潜在被攻击风险越大
- 代码行数(SLOC)：通过cloc工具计算，作为代码复杂度的代理指标
关键洞察：
- 规模风险正相关：国防部573万行代码项目含4000+低危漏洞，验证「代码越复杂，长尾漏洞越多」规律
- 高星项目攻击面：YOLOv5（4万星标）检测出55个严重漏洞，揭示流行开源项目的潜在供应链风险
- NASA中危隐患：VnV工具999个中危漏洞集中暴露航天软件验证流程的薄弱环节
以下是这段话的翻译：
重点代码库分析
本研究所选代码库中，最受欢迎的是Ultralytics开发的目标检测库YOLOv5[34]，其被众多计算机视觉项目广泛采用。2022年最热门仓库为TensorFlow（17.7万星标）和Linux（15.6万星标），相比之下，YOLOv5以4.09万星标的量级，已可匹敌部分顶级开源项目的流行度。
关键对比数据：
- 代码规模：YOLOv5的代码行数(SLOC)仅为基准漏洞代码库[2]的4倍，表明两者代码复杂度相近。
- 潜在风险：YOLOv5依赖OpenCV等未经扫描的第三方库，其Python代码存在供应链安全隐患。
NASA软件扫描工具的特殊性
NASA的软件验证工具代码库（用于航天关键资产认证）若存在未修复漏洞，可能危及太空设备或人员生命安全。尽管其星标数（1800）低于商业项目，但检测出的999个中危漏洞仍需深度调查。
技术细节补充
- 扫描工具对比：附录B展示了基于规则的传统扫描工具与LLMs在此类项目中的具体分析案例。
- 复杂度指标：SLOC（代码行数）和星标数被用作评估代码复杂度和攻击面的代理指标。
核心洞察
- 流行度≠安全性：高星标项目（如YOLOv5）仍存在严重漏洞，凸显开源生态的"受攻击面膨胀"现象。
- 航天软件脆弱性：NASA工具的中危漏洞集群暴露关键基础设施的隐蔽风险。
- 供应链依赖陷阱：即使核心代码简洁，未扫描的第三方库（如OpenCV）可能成为攻击突破口。
研究动机与核心发现
本研究的核心目标之一是将《安全漏洞统一代码库》基准扩展至漏报检测领域，并系统归类漏洞修复方案在编程语言及漏洞类型中的分布。我们重点验证了一个假设：GitHub上Python、C和Java等主流语言的海量代码是否提升了LLMs识别漏洞的能力。
另一动机源于对LLMs的争议：其输出常因底层基于"下一词预测"的优化机制而被认为不可靠或易产生幻觉。尽管OpenAI在聊天界面明确声明"ChatGPT可能生成关于人物、地点或事实的不准确信息"，但本研究探索了一种自反式验证机制------要求模型为识别的漏洞提供修复方案，迫使其重新评估初始结论。这种"漏洞-修复匹配"的良性循环，为LLMs与传统静态代码分析工具的协同提供了理论支撑。
关键验证结果
- 参数规模效应：当参数规模从60亿提升至1750亿至1.7万亿时，LLMs的漏报率较小型模型降低50%，较Snyk减少75%。
- 系统级限制：当前测试限于500个token内的短代码片段（约数十至数百行），无法分析依赖库或系统级漏洞。未来可借助OpenAI新发布的代码解释器[39]突破此限制（附录B演示）。
- 效率突破：GPT-4作为代码扫描工具发现的漏洞数量是传统工具的4倍，其修正方案使漏洞总量减少90%，仅需增加11%的代码量即可消除安全隐患。
未来展望
当前API的响应长度限制（1024 token）虽适用于单元测试，但人工交互式提问可深度挖掘模型潜力。值得注意的是，向代码'提问'的交互模式能激发静态分析工具难以捕捉的洞见------未来的编程助手或将演化为"导师-学徒"关系，通过人机协作优先处理软件需求，实现高效且安全的代码交付。如图4所示，GPT-4的跨语言漏洞发现与修复能力已展现出这种协作范式的雏形。