AI 写代码后的新供应链风险：别让一个不存在的包进了生产

AI 发明一个听起来合理的包名，就像导航凭空说出一家加油站；更危险的是，攻击者可以真的在那个位置开一家假店。

AI 编程工具让从想法到运行代码的距离缩短了，但也缩短了“建议一个依赖”到“执行安装脚本”的距离。模型可能生成不存在的 npm 或 PyPI 包名。攻击者如果注册这些反复出现的幻觉名称，就能把普通错误变成供应链入口，这类风险被称为 slopsquatting。

2025 年 USENIX 相关研究和后续论文说明，包幻觉不是偶发拼写错误，而且某些名称会在不同提示和模型中重复。到 2026 年，模型整体能力提高并没有让这个攻击面自动消失。防守不能只要求 AI 再确认一次，因为模型可能对自己的错误同样自信。

依赖名出现时，先问它从哪里来

每个新增依赖都应在官方 Registry 和项目主页核对：包是否真实存在、创建多久、维护者是谁、源码仓库是否对应、下载量是否突然异常、最近版本改了什么。名字相似不是可信证据，README 写得完整也不是。攻击者可以自动生成看起来专业的文档。

要求 AI 解释“为什么不用标准库或现有依赖”，能减少为了几行代码引入整个供应链。小项目尤其应该克制：每个依赖都带来更新、许可证、安装脚本和传递依赖。代码少一点，审计面也小一点。

安装脚本是最早执行的陌生代码

npm、pip 和其他包管理器的安装过程可能执行构建脚本或原生代码。不要在拥有 SSH Key、云凭据和生产网络的开发机上直接试装陌生包。先在无秘密的容器或沙箱中查看元数据、下载内容和安装行为，限制出站网络。

AI Agent 具备自动终端权限时，应禁止它根据生成结果直接安装新依赖。新增包属于供应链变更，需要单独审批。审批信息至少显示 Registry 链接、版本、维护者、发布时间、许可证和安装脚本。

锁文件、哈希和版本固定

锁文件记录解析后的完整依赖图，让不同时间构建更接近一致。生产环境使用冻结安装模式，拒绝在部署时悄悄更新锁文件。对支持哈希校验的生态启用哈希，对容器镜像固定版本或 digest。latest 与宽松版本范围让回滚和取证都缺少基准。

固定版本也会冻结漏洞，因此要配合定期更新和依赖扫描。正确模式是“可控地更新”，不是永不更新。每次更新都生成清晰 diff，解释直接依赖和传递依赖变化。

构建来源需要可证明

SBOM 告诉你产物包含什么，provenance 或 artifact attestation 告诉你产物从哪个源码和工作流构建。它们不保证源码安全，却能识别发布资产被替换、来源不明或构建链偏离。GitHub 已把 artifact attestations 和 immutable releases 纳入供应链能力。

对于个人项目，不必一开始建立复杂签名体系，但至少保存 Git commit、锁文件、构建命令、镜像 digest 和发布时间。未来发现漏洞时，才能回答哪些运行实例受影响。

AI 代码评审要换问题

不要只问“这段代码有没有 bug”，还要问：新增了哪些依赖和权限；是否出现陌生网络目标；是否读取环境变量、家目录或系统命令；错误处理会不会输出秘密；示例代码是否把测试配置带进生产。让 AI 先列变更面，再由测试和人工验证。

同一个模型既生成又评审，容易共享盲点。关键变更使用不同工具、静态分析或独立人工检查。最可靠的证据仍是 Registry、源码、锁文件、测试和运行时行为，而不是第二段更自信的文字。

可以直接照着做的检查清单

• 逐个核对 AI 建议包的 Registry、源码、维护者和发布时间。
• 在无秘密、受限网络的沙箱试装陌生依赖。
• 禁止 Agent 自动安装新包；依赖变更单独审批。
• 提交锁文件，生产使用冻结安装并固定容器版本或 digest。
• 保存 SBOM、构建来源、commit 与运行镜像的对应关系。
• 评审 AI 代码时检查权限、网络、秘密与安装脚本，不只看功能。

延伸阅读

• USENIX: Package Hallucinations in Code-Generating LLMs
• Importing Phantoms Research
• GitHub Dependency Review
• GitHub Artifact Attestations

AI 可以加速写代码，但依赖进入生产前仍要出示身份证、行程单和来源证明。