这期分享的安全会议论文是来自安全顶级会议之一的usenix security 2025 best paper，题目是We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs）（我们为您准备了一个包裹！代码生成 LLM 对软件包幻觉的全面分析），官网链接为 www.usenix.org/conference/…
一、研究背景
最近的研究表明，多达 97% 的开发者在某种程度上使用代码生成 LLM，项目中大约 30% 的代码是由 AI 生成的，这些数字反映出代码生成 LLM 在项目开发方面对于效率的显著提升。然而 LLM 存在一个关键问题即存在“幻觉”——生成的在事实上不正确、毫无意义或与输入任务完全无关的输出。
本篇论文聚焦于代码生成过程中 LLM 的包幻觉，如今编程语言高度依赖于集中式的包仓库（如 PyPI 和 npm），而代码生成 LLMs 虽然极大提升了编程效率，但也引入了一种新的威胁——包幻觉，即生成不真实或错误的包推荐。包幻觉是由于事实冲突错误产生的，这种现象可能被攻击者利用，通过故意将恶意软件包命名为与合法软件包相似，从而导致软件供应链的包混淆攻击。文章强调了研究包幻觉的重要性，这是软件安全中一个日益严重的问题。
二、论文工作概述
这篇论文旨在调查“包幻觉”现象，分析其在不同 LLMs 中的表现。研究的主要贡献包括：
- 包幻觉的普遍性：文章量化了在不同商业和开源模型中，Python 和 JavaScript 代码生成时包幻觉的发生频率。
- 模型设置的影响：研究了细化训练、温度设置和解码策略等因素对幻觉率的影响。
- 缓解策略：提出并测试了几种减少包幻觉的策略，旨在不牺牲代码质量的前提下降低幻觉率。
三、实验设计
3.1 数据集收集
文章认为现有代码基准（HumanEval、EvalPlus）提示词数量太少、主题不够“日常”，所以自行设计两套数据量更大、种类更多样的数据集，并且都做了“时间分层”（recent vs all-time）来研究“新知识/新包”对幻觉的影响。
A. Stack Overflow 数据集（更贴近真实用户提问）
- 选择 Stack Overflow 的“tag”体系：挑选与 Python/JS 相关且问题数 > 5000 的 tag，人工筛出约 240 个 tag。
- 每个 tag 取点赞最高的 20 个问题，得到 4,800 prompts（每种语言各一份）。
- 为做“时间 recency”分析：把问题分成 2023 年与 2023 年之前两段，各自取同样策略，最终翻倍到每种语言 9,600 prompts。
B. LLM 生成的数据集（覆盖“包生态主题空间”）
- 思路：软件任务往往围绕库/包，因此用包仓库的“热门包描述”来生成 prompt，覆盖面更广。
- 取 Python 与 JS 各 5,000 个下载量最高的包，爬取 PyPI/npm 上的官方描述；再用 Llama-2 70B 把“包描述”改写成“用户会问的编程任务提示词”。
- 清理：无描述/非英文描述会丢弃，所以最终每种语言大约 4,800 prompts。
- 同样做时间分层：2023 热门 vs 2023 之前热门；如果某包两边都出现，会从 “all-time” 里移除避免重叠，确保“recent”确实代表近一年流行度上升的主题。
3.2 代码生成场景
A. 模型选择
- 以 EvalPlus 排行榜作为“代码能力”的参考，选一批商业与开源模型，并且尽量避免同家族低于基础模型的重复微调版本（只保留代表）。
- GPT 系列（3.5/4/4 Turbo）被视为商业代表；开源模型选取了包括 CodeLlama、DeepSeek Coder、WizardCoder、Mistral、Mixtral、OpenChat 等，总计 16 个模型，如下图，其中 CodeLlama 选取了 7B,13B,34B 三种参数大小，Deepseek 选取了 1.3B，6.7B，33B 三种参数大小。
B. 语言选择
- 聚焦 Python + JavaScript：理由是它们最流行且高度依赖中心化包仓库（PyPI/npm），更容易形成“包名 → 安装 → 执行”的供应链风险；而 Java/C/C++ 没有同等形态的中心化开源包仓库依赖（至少不如 PyPI/npm 直接）。
C. 测试环境一致性
- 开源模型用 Hugging Face transformers 跑，并采用 GPTQ 量化（论文强调对准确率影响可忽略但更贴近普通硬件的可用性）。
- 每个模型用同一套 system message/输出约束，以减少“提示词差异”对结果的影响。
3.3 幻觉检测
本文并不只靠解析 import/require 来确定“需要安装的包”，因为 import 的是模块名，模块与包并非一一对应，而且很多代码片段不足以唯一推断依赖。因此采用三条启发式来“尽可能贴近用户真实行为”地抽取包名，再去对照仓库列表判断是否存在。
A. 直接抓安装命令
- 从生成文本/代码里解析
pip install或npm install命令里出现的包名。 - 这类输出仅占总输出约 7%，但对攻击最关键，因为用户可能直接复制执行，立刻触发安装恶意包的可能性。
B. 把“生成的代码”再喂回同一个模型，让它列依赖
- 做法：每份代码样本再作为输入，问同一个模型“运行这段代码需要哪些 packages？”
- 这模拟用户实际会做的事：代码跑不起来 → 问模型“缺什么包”。
C. 用“原始任务 prompt”问模型需要哪些 packages
- 做法：不用代码，直接拿最初的任务描述问“完成这个任务需要哪些 packages？”
- 模拟另一种真实用法：用户可能先问“要装哪些库”，再让模型写代码。
四、实验结果
4.1 包幻觉的普遍性
包幻觉在所有测试的模型中都是普遍存在的，商业模型的包幻觉率相对较低，而开源模型则表现出更高的幻觉率。具体来说：
- 商业模型（如 GPT-4 Turbo）的幻觉率在 4%-6% 之间。
- 开源模型（如 CodeLlama、DeepSeek）的幻觉率则高达 21.7%
- Python 代码的幻觉率（15.8%）低于 JavaScript 代码的幻觉率（21.3%），但两者呈正相关，即同一模型对两种语言的幻觉表现有相似趋势。
4.2 模型设置对幻觉的影响
- 温度设置：随着温度（模型生成输出的“随机性”）的增加，包幻觉的发生率显著上升。高温度（例如 2）会导致模型生成更多幻觉包，而低温度则有助于减少幻觉。
- 解码策略：尝试调整解码参数（如 top-p、top-k 和 min-p）对减少包幻觉的影响较小，表明包幻觉并非仅由这些参数引起。
- 近期主题：模型对于 2023 年后的新包生成的幻觉率更高，表明模型无法实时更新其训练数据，导致对新包的认知产生偏差。
4.3 模型行为的分析
- 重复幻觉：有 43% 的包幻觉在同一模型的多次查询中重复出现，这表明幻觉不是偶然的，而是具有持久性。这种重复性使得幻觉更容易被恶意攻击者利用。
- 模型输出的“啰嗦”程度：更多包名的生成（即“啰嗦”模型）通常会导致更高的包幻觉率。
4.4 包幻觉的特征
- 跨语言幻觉：JavaScript 是唯一显著的跨语言幻觉源头，8.7% 的 Python 幻觉包与 JavaScript 中有效包名匹配。
- 语义相似性：大多数包幻觉与有效包名在 Levenshtein 距离上相差较大，意味着这些幻觉并非简单的拼写错误，而是生成过程中的复杂错误
五、缓解措施
论文给了基线与三种策略、以及“组合（ensemble）”的对比（核心趋势如下）：
- RAG： 两个模型都明显下降（尤其对 CodeLlama 降幅很大），说明“真实包锚点”是普适有效的方向。
- Self-Refinement： 对 DeepSeek 更有效，对 CodeLlama 效果很弱；原因与 RQ3 呼应——CodeLlama 在“判别包名真伪”上有偏置，倾向把大多数包都判为 valid，导致自我纠错失灵。
- Fine-tuning： 幻觉率下降最显著（DeepSeek 甚至压到低于 GPT 系列在主实验中的水平），但代码质量会掉，即“安全性/可靠性”与“代码能力”存在现实代价。
- Ensemble： 把 RAG + Self-Refinement + Fine-tuning 叠加能进一步压低幻觉率，是论文展示的最强组合，但同样会继承 fine-tuning 的质量代价。
六、艾体宝 Mend.io（原 Whitesource）方案的价值
从这篇论文可以发现，即使是主流代码生成模型，也会稳定地产生幻觉包，而且这种现象并不只是偶发噪声，而是可重复、可被攻击者利用的。
而 Mend 的价值不在于从模型内部“消灭幻觉”，而在于在代码进入仓库、CI/CD 和制品流转之前，建立一层面向依赖和供应链的外部控制面。Mend 的 SCA/Software Supply Chain Security 能覆盖 repositories、CI/CD pipelines 等环节，并对恶意包与可利用漏洞进行检测和阻断。也就是说，即便前面的 AI 助手犯错，企业仍然可以在后面的工程链路里把风险拦下来。
