外观
AI 框架、依赖与包生态安全研究综述
摘要
AI 应用继承传统软件供应链风险，并新增由生成代码“推荐”不存在包名的攻击路径。攻击者注册这些幻觉包名后，开发者可能按模型建议安装恶意依赖，这一现象通常称为 Slopsquatting。它的根因位于包分发和依赖选择链，不应仅归为模型幻觉。
分类介绍
本领域覆盖 Python、JavaScript、Rust 等包生态，ML 框架依赖、构建插件、容器依赖和生成代码提出的包名。已部署框架服务的 RCE 与错误配置归 A4；依赖被选择、解析、下载和构建时的风险归本类。
主要安全风险
- 依赖混淆利用公有与私有命名空间、版本优先级或镜像配置差异。
- 拼写抢注（Typosquatting）与幻觉包名抢注（Slopsquatting）利用名称相似或不存在包名的信任空白。
- 安装脚本、编译扩展和构建后 Hook 使包安装本身成为代码执行。
- 深层传递依赖与宽松版本范围削弱人工审查和可复现性。
防护措施与验证方法
使用锁文件、私有命名空间策略、可信镜像、哈希校验和最小化构建网络；新依赖需验证真实项目、维护历史、所有者和用途；对 AI 生成的依赖建议执行与人工代码相同的审查。生成 SBOM 并持续关联漏洞与撤回事件。
局限与待验证问题
- 哪些模型和开发场景最容易产生可重复的幻觉包名？
- 包注册机构如何在不妨碍合法项目的情况下处置 Slopsquatting？
- AI 编码 Agent 自动安装依赖时需要什么批准和隔离边界？
历史研究成果
该分类下的独立研究覆盖包生态的选择、执行与检测链。ChainDrop 自传播 npm 蠕虫事件复盘 2026 年 8 月针对 keyv、cacheable 等 npm 包的自传播活动（ChainDrop / Mini Shai-Hulud）——恶意版本既可在安装阶段执行，也可借助仓库中的 Claude Code SessionStart Hook 和 VS Code folderOpen 任务提前到“打开工作区或启动编码 Agent”时运行，再搜集开发者主机与 CI/CD 中的令牌和发布凭据并继续传播；文章只合并可由一手披露交叉确认的机制事实，不同来源对受影响包数量口径不一。LLM 构建门禁的依赖身份验证绕过则证明，即使直接提示词注入大多被拦截，审查模型仍无法从一行依赖差异证明 Maven 命名空间、发布者和构建期行为；演讲中的最终变体在 20 次测试中通过 1 次，实际执行依赖注解处理器和 CI 权限。ProfMalPlus 是应对这类风险的检测方法，组合对象敏感行为图、带静态证据的代码切片和多 Agent 判定，在 1,090 个恶意包、3,000 个良性包上报告 F1 98.1%，并在 2026 年 4–6 月扫描 107,287 个新包时发现 597 个经确认移除的恶意包。三者共同说明：包生态既需要验证依赖身份和真实构建路径，也需要能在生产规模运行并控制误报的检测方法。
针对 Slopsquatting，Names Can Hurt进一步表明“包名能在 PyPI 解析”不足以证明依赖可信：其两层检测先检查包是否存在，再用包名与元数据特征识别已注册的低质量仿冒包，并以受限的导入名映射处理 cv2 与 opencv-python 一类安装名差异。在 300 条人工整理的 Python 编码 prompt 上，流水线有 76% 的运行产出不含幻觉包名的代码；主模型在重试后仍有 86/300（28.7%）耗尽预算，跨模型回退在实际执行的 85 例中恢复 14 例（16.5%）。约一半被标记的幻觉包名已在 PyPI 注册，同模型家族回退又复现约 84% 的主模型失败，说明仅做存在性检查或同族自检都不足以形成独立门禁。该结果只覆盖作者构造的 300 条 prompt、两种 Agent 生成模型和当前特征集；分类器尚未证明能抵抗专门伪造维护者数量、项目链接等元数据的攻击者，24 人同伴用户研究也不能代表生产开发团队。