AI总是不停编造软件依赖项，并破坏一切

幻构的包名助长了“slopsquatting”

AI驱动的代码生成工具的兴起正在重塑开发者编写软件的方式——同时也为软件供应链引入了新的风险。

像大型语言模型一样，AI代码助手也有一种“幻构”的习惯。它们会建议包含不存在的软件包的代码。

正如我们去年 三月 和 九月 指出的那样，安全和学术研究人员发现，AI代码助手会发明包名。最近的一项研究发现，来自商业模型的包建议中，大约有5.2%是不存在的，而来自开源模型的包建议中，这一比例为21.7%。

运行这些代码应该会在导入不存在的包时导致错误。但是，不法分子已经意识到，他们可以劫持这种幻构行为，以谋取私利。

所需要的只是创建一个恶意软件包，使用一个幻构的包名，然后将这个恶意包上传到包注册表或索引（例如 PyPI 或 npm）进行分发。此后，当AI代码助手再次幻构出被劫持的名称时，安装依赖项和执行代码的过程就会运行恶意软件。

这种重复出现似乎遵循一种双峰模式——一些幻构的名称在重新运行提示时会重复出现，而另一些则完全消失——这表明某些提示会可靠地产生相同的虚假包。

正如安全公司 Socket 最近 指出的，去年探索该主题的学术研究人员发现，重新运行相同的幻构触发提示十次，导致 43% 的幻构包每次都会重复出现，而 39% 的幻构包则永远不会再次出现。

利用幻构的包名代表了一种 typosquatting 的形式，即使用常见术语的变体或拼写错误来欺骗人们。Python Software Foundation 的常驻安全开发者 Seth Michael Larson 将其称为“slopsquatting”——“slop”是 AI 模型输出的常见贬义词。

Larson 告诉 The Register：“我们正处于从生态系统层面看待这个问题的早期阶段。很难，而且可能不可能量化有多少次尝试安装是因为 LLM 幻觉造成的，除非 LLM 提供商提供更多的透明度。LLM 生成的代码、包和信息的用户在将任何这些信息投入运营之前，应该仔细检查 LLM 的输出是否符合现实，否则可能会产生现实世界的后果。”

Larson 表示，开发者可能尝试安装不存在的包有很多原因，包括拼写错误包名、错误地安装内部包而未检查这些名称是否已存在于公共索引中（依赖混淆）、包名和模块名不同等等。

安全公司 Socket 的 CEO Feross Aboukhadijeh 告诉 The Register：“我们正在看到开发者编写代码方式的真正转变。随着 AI 工具成为许多人的默认助手，'vibe coding' 不断发生。开发者提示 AI，复制建议，然后继续。或者更糟的是，AI 代理直接安装推荐的包。”

问题是，这些代码建议通常包括听起来真实但不存在的幻构包名。

“问题是，这些代码建议通常包括听起来真实但不存在的幻构包名。我亲眼见过这种情况。你将其粘贴到你的终端中，安装失败——或者更糟的是，它没有失败，因为有人已经对该确切的包名进行了 slop-squatting。”

Aboukhadijeh 说，这些假包看起来非常具有迷惑性。

“当我们调查时，我们有时会发现看起来很逼真的 README、虚假的 GitHub 仓库，甚至是粗略的博客，这些都使该包看起来很正宗，”他说，并补充说 Socket 的安全扫描会捕获这些包，因为它们会分析代码的工作方式。

更糟糕的是，当你用 Google 搜索其中一个 slop-squatted 包名时，你通常会从 Google 本身获得 AI 生成的摘要，自信地赞扬该包，说它有用、稳定、维护良好。但这只是鹦鹉学舌该包自己的 README，没有怀疑，没有上下文。对于匆忙的开发者来说，它给人一种虚假的合法感。

“我们生活在一个什么样的世界：AI 幻构的包被另一个过于热心提供帮助的 AI 验证和盖章。”

Aboukhadijeh 指出了 一月份发生的一件事，其中 Google 的 AI Overview 使用 AI 生成的文本回复搜索查询，建议使用恶意 npm 包 @async-mutex/mutex，该包是对合法包 async-mutex 的 typosquatting。

他还指出，最近一个使用名称“_Iain”的威胁行为者在暗网论坛上发布了一个 playbook，详细说明了如何使用恶意 npm 包构建基于区块链的僵尸网络。

Aboukhadijeh 解释说，_Iain “自动化了数千个 typosquatting 包的创建（其中许多针对加密库），甚至使用 ChatGPT 大规模地生成了真实包名的逼真变体。他分享了视频教程，指导其他人完成整个过程，从发布包到通过 GUI 在受感染的机器上执行有效负载。这是一个清晰的例子，说明攻击者如何利用 AI 来加速软件供应链攻击。”

Larson 说，Python Software Foundation 正在不断努力使包滥用更加困难，并补充说，这样的工作需要时间和资源。

他说：“Alpha-Omega 赞助了我们的 PyPI 安全工程师 Mike Fiedler 的工作，以减少 PyPI 上恶意软件的风险，例如通过实施一个程序化的 API 来报告恶意软件，与现有的恶意软件报告团队合作，并实施更好的检测来发现顶级项目的 typosquatting。”

“PyPI 和包管理器的用户通常应该检查他们正在安装的包是否是一个现有的知名包，名称中没有拼写错误，并且在安装之前已经审查了包的内容。更好的是，组织可以在他们自己的组织内镜像 PyPI 的一个子集，以便对开发者可用的包进行更多的控制。” ®