Page 194 - 《软件学报》2026年第7期

赵祖威 等: 软件供应链安全中 LLM 生成代码逻辑性缺陷检测 2879

公式 (8)、(9) 中, 第 1 项对应阶段 2 生成测试输入的时间与空间开销, 第 2 项对应阶段 3 符号执行在最坏情
况下搜索路径并求解路径约束生成测试用例的开销, 第 3 项对应阶段 4 执行所有测试用例的开销. 其中, 第 1 项和
第 3 项的开销相对稳定, 主要由测试用例数量决定, 因此其对整体复杂度的影响有限. 在第 2 项中, 尽管符号执行
路径数在最坏情况下呈指数级增长, 但由于目前在软件供应链项目中, LLM 生成的程序通常规模较小, 复杂度有
限, 条件分支数 k 一般不超过 10, 因此符号执行所产生的开销仍可控制在合理范围内, 从而保证了本文方法的可
行性与实用性.

3 实验分析

在本文中, 我们设计并实现了一个软件供应链安全中的 LLM 生成代码缺陷检测方法, 并进行实验评估以回答
以下研究问题.
● RQ1: 将符号执行集成进传统 LLM 代码生成缺陷检测方法中, 能否提升对生成代码的缺陷检测效果?
● RQ2: 为什么集成了符号执行的方法能更有效地检测出 LLM 生成代码中的缺陷?

3.1 实验数据与实验设置
[7]
本文使用来自 HumanEval 、EvalPlus [15] 和 KLEE [17,19] 测试集中的基准程序对我们的缺陷检测框架进行评估.
HumanEval 和 EvalPlus 是此前针对 LLM 生成代码的主流缺陷检测框架, 主要基于模糊测试技术. 从这些基准中,
我们选取 152 个与符号执行引擎兼容的程序作为主要测试任务. 此外, 我们还从符号执行引擎 KLEE 中选取了 14
个测试程序, 作为补充的代码生成测试任务. 本文中的所有实验均在 Ubuntu 22.04 平台上进行, 该平台配备了主频
为 2.60 GHz 的 Intel Xeon Gold 6240 CPU 处理器和 64 GB 物理内存. 实验中 KLEE 符号执行引擎的运行时间上限
设定为 20 min, 其余参数均保持默认配置.
表 1 展示了不同方法生成的测试用例分布情况. HumanEval 中的测试用例均来自基准测试集中. 对于 14 个补
充的测试任务, 我们基于与原始 HumanEval 测试用例相同的分布生成了一个替代测试集, 以尽量减少偏差. 在该
替代测试集中, 测试用例一半为随机生成, 另一半则由 GPT-4-Turbo 根据程序直接生成. EvalPlus 的测试用例则是
使用 EvalPlus 测试方法生成.

表 1 不同缺陷检测方法中的测试用例数量分布

方法 平均值 中间值 最小值 最大值
HumanEval 8.9 7.0 1 105
EvalPlus 756.6 977.5 12 1 100
SymExGen 78.9 66.5 1 150

SymExGen 的测试用例是采用本文提出的方法生成的, 包含由 SMT 求解器成功求解生成的测试用例. 如表 1
所示, EvalPlus 生成了大量的测试用例. 相比之下, 本文基于符号执行的方法生成的测试用例数量较少. 这表明, 本
文方法能够以更低的测试成本生成更准确的测试用例.
表 2 给出了在 166 个测试任务中, 本文方法在缺陷检测过程中的 CPU 时间与内存开销情况. 实验结果显示,
本文方法在绝大多数任务中均能在可接受的时间和内存开销范围内完成缺陷检测, 因此本文方法在真实软件供应
链项目中具有较高的可行性与实用性.

表 2 单任务 CPU 时间与内存开销统计

开销类型 平均值 中间值 最小值 最大值
CPU时间 (s) 451.7 206.9 5.1 1 200.0
内存 (MB) 288.2 268.1 220.7 442.7

3.2 RQ1: 将符号执行集成进传统 LLM 代码生成缺陷检测方法中, 能否提升对生成代码的缺陷检测效果?
我们部署了 11 个 LLM 来评估我们的缺陷检测框架. 这些模型来自 LMSYS Chatbot Arena, 这是一个用于评