AI 编码助手供应链安全：包幻觉攻击与防御体系

📖 读完本文你将获得：

• 理解 包幻觉攻击（Slopsquatting） 的完整攻击链：从 LLM 幻觉到恶意包被执行
• 看清 PHR（Package Hallucination Rate） 这一量化指标及其研究揭示的真实规模
• 理解为什么 agentic 编码时代 会把「人类安装恶意包」的风险升级为「Agent 自动执行恶意命令」
• 掌握覆盖 CI/CD 流水线与 agentic 运行时 的双层防御体系

适用人群： 使用 AI 编码助手的开发者、DevSecOps 工程师、负责软件供应链安全的团队负责人。

传统供应链攻击利用的是「信任真实存在的包」——比如抢注一个与流行包只差一个字母的名字（typosquatting）。包幻觉攻击颠覆了这个前提：它利用的是 AI 推荐了根本不存在的包。

1.1 什么是包幻觉

大语言模型在生成代码时，会自信地写出一些看起来完全合理、但在包注册表（npm、PyPI、Maven 等）里 根本不存在 的包名。这不是偶发错误，而是 LLM 的固有倾向——模型基于「什么包名看起来合理」来生成，而不是基于「什么包真实存在」来检索。研究者把这种倾向量化为 PHR（Package Hallucination Rate，包幻觉率）：AI 推荐的包中，有多少比例是不存在的。

1.2 从幻觉到攻击：Slopsquatting

攻击者的逻辑简单而致命：既然 AI 会反复幻觉出同一批不存在的包名，那我就抢先把这些名字注册成真实包，植入恶意代码，然后等。 当某个开发者让 AI 助手写代码、AI 自信地推荐了这个幻觉包、开发者照单全收执行了安装命令——恶意包就落地了。这种攻击被命名为 Slopsquatting（slop 指 AI 生成的低质内容，squatting 指抢注），2026 年 7 月特拉维夫大学、Technion 与 Intuit 的研究者以 HalluSquatting 之名做了系统披露。

1.3 为什么它特别危险

包幻觉攻击继承了供应链攻击的全部危害（在导入时执行任意代码：窃取环境变量、盗取凭据、建立反向 shell、植入持久化后门），却 绕过了传统供应链防御的心理前提。开发者审查依赖时，默认「AI 推荐的包是真实且常用的」，警惕性远低于面对一个陌生包名。对 AI 的信任，被转化成了对恶意包的信任。

把 HalluSquatting 拆解为可操作的攻击链，能看清每一环攻击者做了什么、防御者该在哪一环拦截。

2.1 第一环：探测高频幻觉包名

攻击者首先 大规模测试 AI 编码助手：用常见的开发任务提示（「写一个处理 JWT 的模块」「帮我做数据可视化」）反复询问多个模型，记录它们推荐的、但在注册表中不存在的包名。凡是多个模型、多次生成中反复出现的幻觉包名，就是高价值抢注目标——因为反复出现意味着未来会有大量开发者被推荐到同一个名字。

2.2 第二环：抢注与植入载荷

攻击者在 npm/PyPI 等注册表上注册这些幻觉包名，包的外观做得尽量可信——它甚至可能真的实现了所描述的功能，同时在 「import」 或安装钩子中执行恶意载荷。这一步与传统恶意包无异：窃取环境变量与凭据、建立反向 shell、植入持久化。

2.3 第三环：等待 AI 推荐与开发者执行

攻击者无需主动投递，只需等待。当某个开发者向 AI 助手提出相关任务，AI 自信地推荐了这个已被抢注的幻觉包，开发者执行 「npm install」 或 「pip install」——恶意代码在开发者完全信任的状态下运行。2026 年的研究进一步指出，这类技术可被用于 把 AI 编码助手变成僵尸网络的投递通道：大量被幻觉引导的安装，构成一张被感染的开发者机器网络。

2.4 跨生态系统的隐形放大

一个尤其隐蔽的变种：研究发现 约 8.7% 被 AI 幻觉出的 Python 包名，恰好是真实存在的 JavaScript 包（反之亦然）。模型「正确地联想到了一个真实的东西，只是生态系统搞错了」。这意味着攻击者可以 专门去其他生态系统抢注这些跨生态幻觉名——一个 Python 开发者被推荐安装某个包，它其实是攻击者在 npm 上抢注的同名恶意包。这类跨生态混淆极难被人工审查发现。

包幻觉不是小概率边缘现象，而是有量化规模的主流问题。理解这些数据，才能判断防御投入的优先级。

3.1 PHR：把幻觉变成可测量的指标

Package Hallucination Rate（PHR） 定义为「AI 推荐的不存在包数 / 推荐总包数」。它已经成为评估代码生成 LLM 供应链风险的事实标准指标，评估方法是系统性地从 AI 输出中提取包引用，再到权威注册表（PyPI、npm、Go 等）逐一核验。

3.2 大规模研究的发现

一项覆盖 57.6 万样本、16 个 LLM 的综合研究（《We Have a Package for You!》）给出了几个关键数字：

• 整体 PHR 约 19.7%——即平均每五个被推荐的包里，就有一个是不存在的
• 43% 的幻觉包名会跨生成重复出现——这正是 Slopsquatting 可行的根本原因：重复意味着可预测，可预测意味着可被批量抢注
• 开源模型幻觉率约 21.7%，而 GPT-4 Turbo 低于 5%——能力更强的模型幻觉更少，但没有任何模型降到零

3.3 这些数字意味着什么

把三个数字串起来看：近五分之一的推荐是幻觉，其中近半数会重复出现，且会被攻击者批量抢注。对一个每天让 AI 生成大量依赖建议的团队，这意味着持续暴露在风险中。而「重复率 43%」这个指标尤其值得警惕——它直接量化了「攻击者抢注一个名字后，能命中多少未来受害者」的期望值。

如果说包幻觉攻击在「人类复制粘贴 AI 代码」的阶段已经危险，那么进入 agentic 编码时代，它会被成倍放大。这是 2026 年最值得警惕的趋势。

4.1 从「人类安装」到「Agent 自动执行」

在传统工作流里，AI 推荐幻觉包后，中间还隔着一个人——人会犹豫、会搜索、可能发现包不存在。但在 agentic 工作流里，编码 Agent 会自己读文件、执行命令、安装包、改仓库，整个链条无需人工确认。一个被幻觉引导的 「npm install 恶意包」 命令，可能由 Agent 在几秒钟内自动执行完毕。人类审查这道最后的缓冲被移除了。

4.2 真实案例：无人种植的幻觉包在 Agent 间传播

安全研究者 Charlie Eriksen（Aikido）在 2026 年 1 月观察到一个更诡异的现象：一个名为 「react-codeshift」 的 npm 包在真实的 AI 基础设施中传播，有多个真实 Agent 试图执行它——而这个包没有任何人刻意种植。它是「幻觉混淆」的自然产物（由两个真实包 「jscodeshift」 等的名字融合而来），被 Eriksen 抢注以研究。这说明：即便没有攻击者，幻觉包名也会在 Agent 生态中自然流动；攻击者的介入只是时间问题。

4.3 结构性根源：安全层管聊天，管不了执行

研究者在 2026 年 7 月的一周内连续披露多个相关攻击（工作流越狱、HalluSquatting、GuardFall），它们共同指向一个结构性结论：治理 AI 编码 Agent「在聊天里说什么」的安全层，并不能治理它「往你文件里写什么、在终端里执行什么」。对话层面的安全护栏与 agentic 运行时的真实操作之间存在断层——安全姿态必须跟随 Agent 的行动，而不只是跟随它的提示词。

把包幻觉攻击放进供应链攻击的谱系里对比，能更准确地定位它的防御位置。

5.1 关键区别

Slopsquatting 与前三者的根本区别在于 攻击面的来源：前三者利用的是「人或系统的既有信任」（信任流行包、信任内部包、信任维护者），而 Slopsquatting 利用的是 AI 凭空创造的、本不存在的「需求」。攻击者不是在「蹭」已有的信任，而是在「收割」AI 制造的虚假需求。

5.2 防御的共性与特性

共性上，lockfile、版本锁定、SBOM（软件物料清单）、最小权限等传统供应链防御依然有效且必要。特性上，Slopsquatting 要求新增一道 「包真实性校验」 关口：在安装任何 AI 推荐的包之前，确认它（1）在注册表中真实存在、（2）有足够的下载量/维护历史/可信发布者、（3）不是最近才被抢注的空壳。这道关口是经典供应链防御里没有的，因为经典场景不需要怀疑「这个包是否本来就不该存在」。

针对包幻觉攻击，防御必须覆盖两个层面：传统的 CI/CD 流水线，以及新兴的 agentic 运行时。两者缺一不可。

6.1 第一层：CI/CD 流水线防御

这是拦截「人类采纳 AI 建议后进入代码库」的关口：

• lockfile 强制 + 版本锁定：所有依赖锁定到确切版本，禁止安装时动态解析最新版本，杜绝临时抢注包趁虚而入
• 包真实性与信誉校验：在 「install」 前自动核验每个包在注册表中真实存在、下载量与维护历史达标、发布者可信；对新近注册、低下载量的包告警或阻断
• 私有注册表代理 + allow-list：所有依赖通过组织控制的注册表代理拉取，只允许白名单内的包进入，外部抢注包根本无法被解析到
• SBOM 与依赖审计：生成并持续审计软件物料清单，对新增依赖做来源审查；用 「npm audit」/「pip-audit」/OSV 等工具扫描已知恶意包
• 隔离的构建环境：构建在无网络或受限网络的环境中进行，即便恶意包被安装，其反向 shell/数据外发也被网络策略阻断

6.2 第二层：agentic 运行时防御

这是拦截「Agent 自动执行」的关口，也是 agentic 时代新增的必要防线：

• 安装命令的显式门禁：编码 Agent 执行 「install」 类命令前要求人工确认，或至少记录并延迟执行，保留人类缓冲
• 运行时命令拦截：在 Agent 的 shell 执行层拦截高危命令（安装、网络外发、凭据读取），对未知包的安装做实时信誉查询
• 能力最小化：默认不给编码 Agent 「自由安装任意依赖 + 自由网络访问」的组合能力；需要的依赖由人预先在受控环境备好
• 安全姿态跟随行动：把对话层的安全策略延伸到运行时——Agent 能执行什么命令、能装什么包、能访问什么网络，都要有独立于提示词的硬性策略

围绕包幻觉攻击，有几个高频误区。

误区一：「我只用知名模型，幻觉率低，不用担心。」 不够。即便 GPT-4 Turbo 的 PHR 也接近 5% 而非零，且「幻觉重复率」才是攻击可行性的关键——只要某个幻觉包名反复出现，它就会被抢注，与你用哪个模型无关。更何况很多团队在用幻觉率更高的开源模型。「幻觉率低」降低概率，但不消除风险，校验关口不能省。

误区二：「lockfile 锁了版本就安全了。」 不完全。lockfile 防的是「已锁定依赖被替换」，但当你 新增一个 AI 推荐的依赖 时，lockfile 里还没有它——第一次 「install」 仍可能装进被抢注的恶意包。lockfile 必须与「新增依赖的真实性校验」配合，而非互相替代。

误区三：「这是注册表运营方（npm/PyPI）该管的事。」 注册表方确实在加强恶意包检测，但他们难以区分「抢注幻觉包的恶意行为」和「正常注册一个新包」——因为幻觉包在被抢注前本就不存在，没有「被仿冒的正主」可供比对。防御责任必然落在使用者一侧。

误区四：「agentic 编码很方便，给它完全权限效率最高。」 这正是风险所在。给编码 Agent「自由安装 + 自由网络」的完全权限，等于把供应链攻击的最后一道人类缓冲也拆掉了。便利与安全需要权衡：高风险操作（安装、网络、凭据）应当设门禁，而非默认放行。

面试延展： 如果被问「AI 编码助手带来了哪些新的供应链风险，如何防御」，可按「机制 → 规模 → 放大 → 防御」展开：先讲 Slopsquatting 机制（AI 幻觉包名被抢注，利用对 AI 的信任）；再引 PHR 数据（约 19.7% 幻觉、43% 重复）说明规模；然后点出 agentic 时代「从人安装到 Agent 自动执行」的放大效应和「安全层管聊天管不了执行」的结构性根源；最后给出 CI/CD + agentic 运行时双层防御，并强调「包真实性校验」是经典供应链防御里缺失的新关口。这个回答既展示对前沿攻击的了解，又体现体系化防御思维。

本文把重心放在「不会过时的机制与框架」，因为包幻觉攻击的根源是 LLM 的固有属性，而非某个可被修复的实现缺陷。

第一，幻觉是生成式模型的固有倾向，不会消失。 LLM 基于「什么看起来合理」生成，而非基于「什么真实存在」检索。在生成式架构被彻底改造、或「生成时实时检索注册表核验」成为标配之前，包幻觉会持续存在。PHR 可以下降，但难以归零。

第二，攻击面随 AI 编码普及而扩大。 2026 年越来越多的代码由 AI 辅助甚至主导生成，意味着每天产生的「幻觉包推荐」总量在激增。攻击者抢注一个高频幻觉包名能命中的受害者数量，只会越来越大。这是一个随生态扩张而恶化的攻击面。

第三，agentic 化移除了最后的人类缓冲。 从「AI 建议、人执行」到「Agent 自主执行」的演进，是效率的胜利，也是安全的挑战。它要求防御从「保护人不犯错」转向「约束 Agent 的行动权限」——这是一套全新的、仍在发展中的防御范式。

把视野拉长：软件供应链攻击的每一步演进——从源码投毒、到依赖混淆、再到如今的幻觉抢注——本质上都是攻击者在寻找「开发者信任链条上最薄弱、最不设防的一环」。AI 时代，这一环变成了「对 AI 输出的无条件信任」。守住这一环的方法始终如一：不要把信任给任何未经独立验证的输入，无论它来自人、来自系统，还是来自一个自信满满的 AI。 这条原则，六个月后、六年后依然成立。