G.O.S.S.I.P 阅读推荐 2025-03-10 LLM 在前，漏挖人能否保住饭碗（Yet?）

LLM 在代码理解上表现出了强大的能力，相信漏挖选手都已经对 LLM 跃跃欲试。今天我们介绍的这篇来自 IEEE S&P 2024 的论文LLMsCannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks 对 LLM 的漏洞识别能力进行了一番测评，虽然 LLM 的能力仍在快速迭代，一些实验结论可能随时被推翻，但文章依然有助于我们熟悉这位新朋友。全程无广，各位共赏。

文章构建了一个由 C 和 Python 漏洞代码片段组成的数据集SecLLMHolmes，结合多种 prompt 方案，对 8 个常用的 LLM 识别漏洞的能力进行了评估。数据集总共包括 228 段代码，其中包含 48 段手动构造的漏洞代码，30 段真实漏洞代码，150 段通过 code augumentation (改函数名、变量名、添加无用代码等）得到代码，每个实验根据不同测试需求选择代码进行测试。测评的 LLM 列表如下图。由于论文实验时间较早，实验只覆盖到了 gpt-4。就这些模型而言，gpt-4 在文章实验中整体表现较好。

实验总结了五点结论：

（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 有助于提升输出稳定性。

接下来，作者改变 prompt，要求 LLM 在判断代码是否存在漏洞的同时进一步说明为什么做出这样的判断。结果表明，LLM 至少在找漏洞这个方面常常口是心非。实验结果见下表，绿色部分是推理和结论一致的情况。

文章也给出了一个口是心非的案例：chat-bison 在推理中明确说明了代码可能有 SQL 注入的问题，但最终认为代码没有漏洞。这组实验也说明了文章测试的几款 LLM 并非依赖自身推理做出决策。（这种情况在现在的推理模型中应该会有所改善？）

随后，文章观察了 LLM 是否会因为代码片段的微小修改改变判定结果。代码修改分为两种：Trival code augementation（自动化地将变量名修改为随机值、添加空格等简单修改）和 Non-trival code augementation（将函数名改为 secure-func，unsecure-func 等有特别含义的高级修改）。具体改法论文中有更详细的说明，修改都不影响漏洞本身。

实验结果如下表所示（其中代码修改导致结果改变的情况已经高亮）。文章发现，即使仅仅是简单添加空格，也可能导致输出改变（但我们要考虑到这也可能是 LLM 自身输出不确定性导致的）。显然 Non-
trival 手法会给 LLM 带来更大的干扰，这说明想要恶意对抗 LLM 漏洞检测现阶段还是非常容易的。

其实还有另一篇论文（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

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2025-03-10 LLM 在前，漏挖人能否保住饭碗（Yet?）