依赖幻觉与供应链安全
一句话定义
依赖幻觉是模型推荐不存在的包名；当攻击者抢注这些「幻觉包名」并植入恶意代码时（slopsquatting），一次不经意的安装就变成供应链入侵——防线是「先查注册表再安装」的硬规则加锁文件与成分扫描。
为什么重要
AI 生成的 import 语句看起来总是那么可信。幻觉包名的风险有二层：轻则安装失败浪费时间；重则包名真实存在——被抢注的幻觉名（slopsquatting）或形近的官方包（typosquatting），安装即执行攻击者的安装脚本，可窃取凭据、植入后门。这类攻击不需要模型或平台的任何漏洞，只需要开发者「顺手照抄 AI 给的包名」。它是 AI 编程特有的新攻击面，必须成为团队的硬规则。
前置知识
kp-021（审查清单第二层——依赖核验是其检查项之一）。
核心概念
- 依赖幻觉：模型生成语法正确、名称可信但实际不存在的包。根源：模型对包名做的是概率续写，不是数据库查询。
- Slopsquatting：攻击者批量收集 AI 常产出的幻觉包名，提前在 npm/PyPI 等注册表抢注，等待受害者安装。
- Typosquatting：与知名包形近的恶意包（如多一个字母），AI 也会犯错引入。
- 防线三件套：
- 硬规则：AI 推荐的任何依赖，安装前必须在官方注册表人工核验（存在性、维护者、下载量、发布历史）；
- 锁文件：lockfile 提交入库，CI 只按锁安装；
- 成分扫描（SCA）：用工具比对已知漏洞库与包名形近告警。
原理与机制
幻觉包名的产生机制与普通幻觉一致：模型在「这个功能需要一个做 X 的库」的语境下，按训练数据里的命名惯例生成一个「最像真的」名字。风险被放大的机制在于：概率上，常见前缀组合（如 fast-、py-、easy-）生成的名字有非零概率命中空位——而空位正是抢注者的靶位。防御因此必须从「信任输出」切换到「验证存在性」：注册表查询是唯一真值来源。锁文件与 CI 固定来源的作用是把「验证一次、处处可信」固化，防止后续环境安装时被重新解析到恶意版本。
实例或案例
操作步骤（新依赖核验五步，逐项过完才允许安装）：
- 存在性：在官方注册表（npm/PyPI/Maven Central）搜包名，精确匹配。
- 来源：看仓库链接是否指向可信组织；发布者账号年龄与名下其他包。
- 健康度：周下载量、最近发布时间、issue 活跃度——下载量异常低的新包最危险。
- 必要性：仓库里是否已有功能等价的依赖（对照 kp-021 第三层）。
- 落锁：确认后写入清单文件，提交 lockfile，之后不再手改版本。
排错清单：
- 已经装了可疑包 → 立即卸载；检查其安装脚本执行期是否有网络外发与文件改动；若在 CI/生产执行过 → 按凭据泄露处理（kp-024 应急流程）。
- 团队反复被 AI 推荐幻觉包 → 规则文件加红线：「新增依赖必须先经人工核验，AI 不得直接安装」。
- CI 里出现未锁定的版本漂移 → 检查 lockfile 是否入库、安装命令是否用了锁定模式。
- 内部私有包与公共包重名 → 配置注册表镜像优先级，防公共源抢答。
公式或模型
本节不适用：攻击面统计数字随时间快速变化，本库不引用具体比例以免失真；防线以流程规则表达。
图示
AI 生成 import 幻觉包名
│
▼
[核验五步] ──不存在──▶ 打回（让AI改用已有依赖或标准库）
│存在但可疑（低下载/新账号/形近）
▼
人工裁决 ──拒绝──▶ 打回
│通过
▼
写入清单 + 提交 lockfile ──▶ CI 按锁安装 + SCA 扫描直观类比
像收快递：AI 给你的「地址」再像真的，签收前也要查这户人家是否存在（注册表）、是不是老住户（账号历史）、平时有没有人往来（下载量）——空地上的新住户最可能是陷阱。
常见误区
- 「报错的包才危险」：装上了但没人审计的包才是真危险；安装成功不等于安全。
- 用 AI 复核 AI：「帮我确认这个包安全吗」——模型没有注册表实时数据，必须人工查官方源。
- 只防幻觉名不防形近名：typosquatting 是更老的攻击，AI 同样会引入。
与其他知识点的关系
kp-018 的网络与安装权限是技术层防线；kp-023 处理核验通过后的许可证维度。
自测题
要点：抢注 AI 常产出的幻觉包名等待误装；后者是仿冒知名包形近名。共同点：安装即中招。
要点：存在性、来源、健康度、必要性、落锁——全过才安装。
- 什么是 slopsquatting？它与 typosquatting 的区别？
- 新依赖核验五步？
延伸阅读
本节不适用：slopsquatting 属新兴威胁，研究数据迭代快，建议以本节流程 + 最新官方安全公告为准。