大语言模型（LLM）近期成为安全研究和竞赛中的热门话题，涵盖了大模型在安全领域的应用以及自身的安全性等方向，这一趋势为许多非大模型安全研究领域的研究者提供了了解和探索的机会。得益于强大的上下文理解与模式识别能力，大模型被认为具备从已知漏洞中学习特征并检测、修复未知漏洞的潜力。DataCon曾为大家介绍过大模型与漏洞相关话题，<a href="https://mp.weixin.qq.com/s/EJw7-VPEseLEueRmQhy8Vg" target="_blank">点击了解：浅谈大模型辅助漏洞挖掘。</a><img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1742197171498_8dd77b93.png" alt style="" />除此之外，今天还要为大家推荐的是一篇来自 IEEE S&amp;P 2024 的论文 LLMsCannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks 。文章对LLM 的漏洞识别能力进行了一番测评，虽然 LLM 的能力仍在快速迭代，一些实验结论可能随时被推翻，但文章依然有助于我们熟悉这位新朋友。<img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1742197181795_d901bc10.png" alt style="">文章构建了一个由 C 和 Python 漏洞代码片段组成的数据集<code>SecLLMHolmes</code>，结合多种 prompt 方案，对 8 个常用的 LLM 识别漏洞的能力进行了评估。数据集总共包括 228 段代码，其中包含 48 段手动构造的漏洞代码，30 段真实漏洞代码，150 段通过 code augumentation (改函数名、变量名、添加无用代码等）得到代码，每个实验根据不同测试需求选择代码进行测试。测评的 LLM 列表如下图。由于论文实验时间较早，实验只覆盖到了 gpt-4。就这些模型而言，gpt-4 在文章实验中整体表现较好。<img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1742197187989_d90ba662.png" alt style="">实验总结了五点结论：（1）LLM 的表现严重受 prompt 影响，但无论使用何种技术，被测的 LLM 都有比较高的误报率；（2）对于相同的代码片段，LLM 输出是不确定的（non-deterministic），时对时错；（3）即使 LLM 正确判断了代码是否包含漏洞，它给出的理由也常常是错误的；（4）对代码进行微小的改变，比如修改函数名，就可能导致 LLM 给出错误结论，即使使用 Chain-of-thought 这类 prompt 策略也是如此；（5）LLM 在真实世界的漏洞上表现不佳。第一点是所有静态分析都难以避免的问题，想客观评价 LLM 的准确性，还需要拿真实代码数据集和传统方案进行对比。我们直接从第二点开始。SecLLMHolmes 选取了两段经典漏洞代码（CWE-787 “out-of-bound write” 和 CWE-89 “SQL injection” ）和它们 patch 后的版本作为数据集，对每个 LLM 重复测试十次，分析 LLM 能否给出稳定的输出。论文进行了两组实验，一组按 OpenAI 文档建议，配置 Temperature = 0.2，另一组配置 Temperature = 0.0，两组结果见下表，输出不一致的情况在图中红色高亮（没有高亮的既有稳定全对的，也有稳定全错的）。整体来说越界写漏洞检出的稳定性明显弱于 SQL 注入，而降低 Temperature 有助于提升输出稳定性。<img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1742197201381_e89f83aa.png" alt style=""><img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1742197201441_aef7c745.png" alt style="">接下来，作者改变 prompt，要求 LLM 在判断代码是否存在漏洞的同时进一步说明为什么做出这样的判断。结果表明，LLM 至少在找漏洞这个方面常常口是心非。实验结果见下表，绿色部分是推理和结论一致的情况。<img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1742197209649_a42987db.png" alt style="">文章也给出了一个口是心非的案例：chat-bison 在推理中明确说明了代码可能有 SQL 注入的问题，但最终认为代码没有漏洞。这组实验也说明了文章测试的几款 LLM 并非依赖自身推理做出决策。（这种情况在现在的推理模型中应该会有所改善？）<img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1742197214802_1b69e219.png" alt style="">随后，文章观察了 LLM 是否会因为代码片段的微小修改改变判定结果。代码修改分为两种：Trival code augementation（自动化地将变量名修改为随机值、添加空格等简单修改）和 Non-trival code augementation（将函数名改为 secure-func，unsecure-func 等有特别含义的高级修改）。具体改法论文中有更详细的说明，修改都不影响漏洞本身。实验结果如下表所示（其中代码修改导致结果改变的情况已经高亮）。文章发现，即使仅仅是简单添加空格，也可能导致输出改变（但我们要考虑到这也可能是 LLM 自身输出不确定性导致的）。显然 Non- trival 手法会给 LLM 带来更大的干扰，这说明想要恶意对抗 LLM 漏洞检测现阶段还是非常容易的。<img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1742197224230_bd45e038.png" alt style="">其实还有另一篇论文（Uncovering the Limits of Machine Learning for Automatic Vulnerability Detection）对类似的代码修改对 LLM 漏挖的影响做了更细致的验证，结论是相似的，LLM 会明显受代码改动带来的噪声干扰，但实验规模更大，评测也更细致，感兴趣的朋友可以自己去搜索该论文查看细节。除了人工构造的漏洞代码片段，文章也用 Linux，Libdiff，gpac 等软件的真实 CVE 验证了 LLM 的漏挖能力。整体来说错误率比较高，表格比较长，结论也不算意外，各位可以自行查看。除此以外，论文还有一些实验也很有意思。比如评估了不同的 prompt 策略组合，包括 zero-shot/few-shot，task-oriented(任务导向)/role-oriented(角色扮演)，直接给结论/逐步推理/在prompt中提供漏洞定义等，整体的结论是不同模型适合不同的策略，没有哪种方案呈现出显著的优势。即使是我们熟知的角色扮演策略，也对不了所有 LLM 的胃口。这部分细节比较多，且结论可能随着模型更新随时变化，实际使用还是得自行测试。最后夹带一段私货，LLM 是否会抢走我们漏挖人的饭碗呢？从论文结果来看，LLM 在代码审计方面还有很长的路要走，但文章设置的实验是相对简单粗暴的，要求 LLM 对代码是否存在漏洞给出结论，而现在更常见的做法是仅在部分环节利用 LLM 的能力辅助漏挖。随着 LLM 能力的增强，想必过去不少漏挖工作（以及大家手头正在做的一些工作…）会被迅速淘汰，但技术发展向来都是将人类从低级劳动中解放出来，去思考更复杂的问题。漏挖不是新话题，但长远来看，无论是人工审计还是自动化漏挖都还在相当初级的阶段，或许这正是各位开拓新战场的好时机。论文链接如下：https://www.bu.edu/peaclab/files/2024/05/saad_ullah_llm_final.pdf

LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks

Abstract—Large Language Models (LLMs) have been suggested for use in automated vulnerability repair, but benchmarks showing they can consistently identify security-related
bugs are lacking.

LLM技术浪潮下，“漏挖人”能否保住饭碗？

LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks