AI幻想出的代码依赖构成新型软件供应链风险

受 LLM 驱动的代码生成工具的崛起，正在重塑开发人员编写软件的方法，并在此过程中引入新的软件供应链风险。

这些AI编程助手和一般的大语言模型一样，都有幻觉的习惯，它们会给出集成并不存在的软件包代码的建议。

去年3月和9月，安全和学术研究员就发现AI代码助手会编造程序包名称。最近开展的一项研究发现，商用模型建议的约5.2%的包是不存在的，而开源或开放可用的模型生成不存在包的比例是21.7%。当导入不存在的包时，运行该代码可导致错误发生，而恶意人员发现了这种幻觉的可利用性。

攻击者所需做的就是创建一个恶意软件包，并根据幻想出的包的名称命名它，之后将该恶意包上传到包注册表或索引如 PyPI 或 npm 进行发行。之后，当AI代码助手再次幻想出这一名称，安装依赖和执行代码的流程就会运行该恶意软件。

这种重现似乎遵循一种双峰模式——一些被幻想出的名称会在提示符再次运行时重复出现，而其它名称则会完全消失——这说明某些提示会可靠地生成同样的幻觉包。

Socket 公司提到，去年研究此主题的学术研究人员发现，运行10次相同的幻觉触发提示，会导致43%的被幻想的包每次都会重复，而39%的永远不会再次出现。

利用被幻想出的包名称是 typosquatting 的一种形式，即常用词的变体或错误拼写被用于欺骗。Python 软件基金会的自研安全开发人员 Seth Michael Larson 将其命名为“slopsquatting”，而”slop（泔水）”是针对AI模型输出的常见贬损之词。

Larson 提到，“从生态系统级别来看这个问题，我们尚处于非常早期的阶段。LLM幻觉如果没有LLM提供商提供更多的透明度，那么量化安装尝试次数是困难的甚至不可能完成的。LLM生成代码、程序包和信息的用户应当仔细检查LLM输出是否符合事实，之后才能将该信息应用于运营中，否则会对真实世界造成多种后果。”

Larson 表示，开发人员尝试安装并不存在的包，原因很多，包括错误拼写了包名称、在未检查这些名称是否已经存在于公开索引就错误地安装了内部包（依赖混淆）、包名称和模块名称之间的差异等。

Socket 公司的首席执行官 Feross Aboukhadijeh 提到，“我们正在见证开发人员编写代码方式的真正变化。AI工具正在成为很多开发人员的默认助手，‘氛围编程’即刻发生。开发人员提示AI、复制建议并继续编写。或者更糟糕的是，该AI代理自行安装所推荐的程序包。问题在于，这些代码建议通常会包括看似真实但却不存在的幻想出的包名称。我亲自见到了这一情况，将建议粘贴到终端而安装失败，或者更糟糕的情况是它并未失败，因为有人slopsquatt 这个包名称。” Aboukhadijeh 表示，这些虚假包看似非常令人信服。他提到，“当我们调查时，有时会看到看似真实的 README、虚假的GitHub 仓库、甚至是让程序包看似真实的简单的博客文章。”

尽管并未有证据表明攻击者已经开始利用这种新型攻击类型，但研究人员提醒称，幻想出的包的名称很常见、反复出现并在语法上看似是合理的，因此制造出一种能被轻易武器化的攻击面。研究人员提到，“整体而言，58%的幻想出的包会在每10轮后至少重复一次，这说明大多数幻觉并非只是随机噪音，而是可重复的关于模型如何响应某些提示的工件。这种可重复性增加了它们对于攻击者的价值，使其通过观测少量模型输出，就能更轻松地找到可行的slopsquatting 目标。”

缓解措施

缓解该风险的唯一方法是手动验证程序包名称，并永远不要假设由AI生成的代码片段中提到的程序包是真实安全的。

使用依赖扫描器、锁定文件以及哈希验证将程序包与已知的可信任版本关联，是提升安全性的一种有效方法。

这项研究表明，降低AI的“温度”设置（更少的随机性）减少幻觉，因此对于使用AI协助或“氛围编程”的用户而言，这是需要考虑的一个重要因素。