一句话定义
依赖混淆（Dependency Confusion）是一种软件供应链攻击：攻击者在公共包仓库里注册一个和某公司内部私有包完全同名的包，利用包管理器"先查公共源"或"版本号高者优先"的规则，让正常的构建流程主动把恶意代码拉进项目。
它怎么得逞的
现代项目装依赖，靠的是"名字 + 版本号"，而不是"从哪来"。比如某公司内部有个私有包叫 internal-utils，放在自己的私有仓库里，员工本该只从那里取。
问题出在解析规则上。很多包管理器（npm、pip、Maven 等）支持配置多个源，默认行为往往是：先在公共仓库里找有没有这个名字，找到就用；或者对同一个名字，谁声明的版本号更高就选谁。攻击者只需要在公共仓库注册 internal-utils，再发布一个版本号很高的版本，包管理器就可能"择优录取"，把攻击者的包装进来，而开发者本地什么错都没犯。
打个比方：公司楼下有个内部小卖部，专卖"老王牌辣酱"。采购员下单时只写了"老王牌辣酱"，系统却很聪明——先去全网电商搜一圈，看到有人卖同名辣酱还标着"最新第 N 版"，就下单了。攻击者要做的，就是提前在电商上开一家同名店铺。
和相邻概念的区别
| 手法 | 名字拼对了吗 | 关键漏洞 |
|---|---|---|
| 依赖混淆 | 对 | 源选错了，装到了公共仓库的同名包 |
| 错字抢注（Typosquatting） | 错（如 reqeusts） | 开发者手滑打错字 |
| 包投毒 / 账号劫持 | 对 | 源也对，但维护者账号被盗后发布恶意版本 |
一句话：依赖混淆是"名字对、来源错"。
为什么编码智能体放大了它
这类攻击在 AI 编码智能体（coding agent）时代更值得警惕，因为智能体的工作循环恰恰是：看到 ModuleNotFoundError，就去公共仓库搜同名包并安装，然后重跑测试。
它没有"这个包是我们内部的"这种组织常识，也不会先问人。而它通常跑在有网络、有凭据的容器里，装进去的恶意包可以在安装脚本阶段就执行代码。人手打错字是偶发的，智能体的自动修复是每分钟好几轮的。
怎么防
- 限定作用域：内部包统一用命名空间前缀（如
@公司名/包名），并在配置里把该前缀显式绑定到私有源。 - 别让公共源当默认：在 CI 和智能体沙箱里把私有源设为唯一来源，或对外网做白名单代理。
- 锁文件 + 哈希校验：提交 lockfile，校验完整性，拒绝"计划外"的依赖变更。
- 给智能体瘦身权限：网络、凭据、密钥都按最小必要给，并审计它新增的每一个依赖。
具体各包管理器的源配置语法和行为差异较大，以官方文档为准。