焦秀文“依赖混淆”这个词，在供应链安全圈子里已经不算新鲜了。但最近我在复盘一次红队演练时，突然意识到一个更值得警惕的变种：当AI代码助手成为开发者的“第二双手”，依赖混淆攻击从“广撒网捞鱼”变成了“精准狙击”。过去攻击者抢注包名，靠的是撞运气；现在有了AI的自动补全机制，攻击者可以通过污染AI的“认知”，让恶意包名直接出现在目标开发者的候选列表里，等着他亲手按下回车。
这篇文章我不会只讲概念。我会从依赖混淆1.0的原理说起，重点拆解AI代码助手如何放大攻击面、精准投毒的完整链路怎么走、以及作为开发者和安全团队，我们到底该怎么防。内容偏实战，适合正在用AI编码工具的开发者、做供应链安全治理的同学，以及任何对“代码从哪来”这件事有警惕心的人。
1. 依赖混淆1.0到2.0：从广撒网到定点打击
1.1 依赖混淆1.0的经典原理
依赖混淆攻击的核心逻辑并不复杂。现代软件开发高度依赖包管理器，无论是Python的pip、Node.js的npm，还是Java的Maven，本质上都是从“源”拉取依赖包。企业内部通常会搭建私有源，存放自己的内部组件，但包管理器的解析顺序往往存在一个默认行为：如果私有源找不到某个包，就自动回退到公共源。
这个回退机制就是1.0攻击的温床。攻击者的操作很简单：猜一个你内部可能存在的包名，然后去公共源注册同名包。比如你们公司内部有个包叫internal-auth-utils，你在npm的公共源上把这个名字注册下来，里面塞一段恶意代码。只要某台开发机器或CI环境没有正确配置私有源优先级，pip install internal-auth-utils或npm install internal-auth-utils就会从公共源拉下这个恶意包，攻击即告成功。
1.0时代，攻击者面临的最大问题是“不确定性”。他不知道你的内部包名是什么，不知道你的构建环境配置有没有漏洞，也不知道你会在什么场景下安装依赖。所以只能广撒网，大量注册可能的包名，赌概率。攻击的成功率虽然存在，但往往需要配合信息泄露才能精准命中，实际利用成本不低。
1.2 为什么AI代码助手把局面彻底改变了
AI代码助手（比如各类Copilot类工具）出现后，这条攻击链发生了一个关键变化：攻击者不再需要知道你的内部包名，他可以让AI“替他”把包名递到开发者面前。
这个变化的根本原因在于AI代码助手的训练和推理机制。这些工具基于大规模公开代码库训练，模型从海量开源项目中学习了“什么上下文应该补全什么代码”的模式。当开发者在IDE里输入一个函数调用或import语句的开头时，模型会根据整段代码的上下文、文件路径、项目结构，预测接下来最可能出现的代码片段——包括包名。
攻击者盯上的就是这条“预测链路”。如果他能让AI模型在特定上下文中“认为”某个恶意包名是最合理的补全结果，那么开发者使用AI助手时，就会自然而然地看到这个包名，甚至直接接受补全。整个过程，攻击者不需要接触目标系统，不需要猜测内部包名，只需要“污染”AI的判断依据。
我把这种攻击称为依赖混淆2.0，因为它的攻击对象从“包管理器的解析逻辑”变成了“AI模型的认知”，攻击方式从“等待受害者引入”变成了“主动推荐给受害者”。这是两种完全不同的武器。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 自动补全的“信任盲区”：一个危险的日常瞬间
2.1 补全机制如何运作：预测而非检索
要理解依赖混淆2.0为什么危险，得先搞清楚AI代码助手的自动补全到底是怎么工作的。
大多数人以为AI补全像IDE的自动补全一样，是基于语法和索引的检索——你输入import xxx，它查一下本地缓存或在线索引，返回匹配的包名。但大模型驱动的编码工具完全不是这个逻辑。它本质上是“逐token预测”：模型根据你之前输入的代码（甚至包括光标前几百行的上下文）、当前文件的注释、项目里其他文件的命名风格，预测下一个最可能的token序列。
举个例子。你在一个Python项目里写爬虫相关的代码，前面几行已经import requests、定义了fetch_page函数，接下来你敲了一个import，AI很可能补全成import bs4或from bs4 import BeautifulSoup，因为训练数据里“爬虫代码常见import bs4”这个模式太常见了。这不是AI去“查看”了你的环境，而是它从海量代码的统计规律中“推断”出来的。
这里有个关键点：**模型没有能力区分“这个包是否真的存在于你的项目依赖中”。**它只负责预测“在类似情境下，人类最可能写什么”。所以只要训练数据——或者能够影响模型判断的公开信息——中出现过某种关联，模型就可能把一个从未被目标环境允许的包名推荐出来。
2.2 人对补全结果的审查心理：效率压倒警惕
接下来是第二个问题：为什么开发者会真的接受AI推荐的恶意包？
心理学上有个概念叫“自动化偏见”，意思是当人类依赖自动化系统时，会不自觉地降低对结果的质疑程度。AI代码助手把这个偏见放到了最大。高速编码时，开发者的大脑处于“心流状态”，连续敲击键盘、跨过函数、补全样板代码，精力几乎都花在“我想让程序做什么”上，而不是“AI推荐了什么我不熟悉的东西”。
我见过太多真实场景：开发者敲npm install，AI补全了包名lodash-es，开发者甚至没看一眼就直接回车。这种半自动化的操作习惯，让补全结果像“顺势滑入”代码库一样，缺乏应有的刹车。尤其当AI推荐的包名和内部命名的风格高度相似时，几乎不会有任何人停下来查一下这个包是不是真的存在。
这就是自动补全的“信任盲区”：它让你在不知不觉中，把一个本不该出现的依赖，以“顺理成章”的方式装进了项目。攻击者最想利用的恰恰是这一点。
3. 精准投毒的链路推演：从目标画像到安装执行
3.1 从2.0视角拆解攻击的完整链路
结合依赖混淆攻击的既有手法和AI自动补全的特点，依赖混淆2.0的攻击链路大致可以分为六个环节。我这里只做概念性拆解，重点讲清楚“为什么能成立”，而不是提供一个可复制的操作手册。
环节一：目标画像。 攻击者选定攻击目标后，首先会尽可能多地收集目标组织的技术信息。公开渠道的资源非常丰富：技术博客会泄露团队的技术栈选择，GitHub组织下的开源仓库会暴露内部代码风格，招聘JD会写明使用什么框架、什么语言，甚至员工个人主页上展示的项目也会透露细节。这些信息帮助攻击者构建一幅“这个团队平时怎么写代码”的画像。
环节二：包名策略。 有了画像，攻击者就可以设计“高可信包名”。这不是瞎猜，而是利用AI的语义联想规律。比如目标团队是Java/Spring重度的公司，AI在补全依赖时很容易想到常见的Spring生态包。攻击者会注册一些与内部包名语义相近、拼写相似、或者刚好是内部包常用别名的公共包名。关键是让这个包名在AI看来“非常合理”。
环节三：公共源抢注。 攻击者在npm、PyPI、Maven等公共源注册这些经过选择的包名，并在包内嵌入恶意代码。这部分和传统的恶意包没有本质区别，真正的差异化在后面。
环节四：认知污染。 这是依赖混淆2.0最核心的一环。攻击者需要让AI模型在特定上下文中“学会”推荐这个恶意包名。AI模型的训练数据源自公共互联网上的海量代码库、技术文档和社区讨论。攻击者可以刻意制造一些“看似正常的证据”：在一个公开仓库里写下正常的业务代码，其中包含import 恶意包名这样的语句；在技术问答社区中提问如何解决某个包含该包名的报错；在README文档中展示使用该包的典型代码。这些公开信息一旦被AI的训练数据或检索增强生成（RAG）系统捕获，模型就会在后续的补全中认为“在这个上下文中，这个包名是一个合理选择”。
环节五：触达目标。 目标开发者在IDE中使用AI辅助编码时，在某个合适的上下文中敲下import或pip install等前缀，AI补全出恶意包名。由于包名在上下文中看起来非常“自然”，加上自动化偏见的存在，开发者大概率会直接接受。
环节六：安装执行。 依赖被写入配置文件，接着在本地或CI环境中安装。恶意代码在安装阶段（如pip的setup.py、npm的preinstall脚本）触发执行，攻击者拿到远程控制权限或窃取敏感信息。
3.2 为什么“认知污染”能生效：基于代码统计的联想规律
看到这里可能有人会问：AI这么大一个模型，怎么可能因为攻击者随便提交几个公开仓库就能改它的行为？
这个问题要分两层看。
对于在线的大模型，修改参数集的难度极高，攻击者不可能通过几个样本直接调整模型权重。但现在的AI编程工具普遍采用了“长上下文窗口+检索增强（RAG）”的架构，实时检索相关的公开代码片段，把相关内容融入当前上下文再补全。这意味着攻击者不需要“重新训练模型”，只需要让自己的恶意包名出现在AI检索系统能搜到的公开信息里，就有机会在推理阶段影响输出。
对于训练基础模型，攻击者的目标不是“全世界范围的泛化”，而是“特定上下文的关联”。如果攻击者部署大量包含恶意包名的开源仓库，这些数据被当作训练语料抓取后，模型会在统计学意义上增加“在某个上下文推荐该包名”的概率。这种影响未必立刻全网可见，但对于通过RAG或微调来提升代码补全效果的工具来说，同样存在可乘之机。
更值得关注的是，这种攻击完全不依赖目标系统内部存在漏洞。它攻击的是“人+AI”的决策链路，是生态系统的信任边界。即便目标团队的代码完全合规、依赖锁定完全正确，只要开发者信任AI补全，攻击链就可能被激活。
3.3 与依赖混淆1.0的关键差异对比
| 维度 | 依赖混淆1.0 | 依赖混淆2.0 |
|---|---|---|
| 攻击对象 | 包管理器的解析逻辑 | AI模型的补全决策 |
| 触达方式 | 开发者手动安装时踩坑 | AI补全主动推荐 |
| 信息依赖 | 需要猜测内部包名 | 需要目标技术画像 |
| 精准程度 | 广撒网、低命中 | 定向投喂、高命中 |
| 前置条件 | 私有源配置不当 | 开发者使用AI编码助手 |
| 防御重点 | registry配置、锁文件 | 包名来源审计、AI补全监控 |
4. 开发者与安全团队的防御清单
面对依赖混淆2.0，传统的“升级依赖、扫描漏洞”远远不够。真正有效的防御，要从依赖管理的每个触点下手，从“事后扫描”前移到“源头管控”。
4.1 开发者侧：让每个包名都有迹可循
第一，回归包管理器的基础纪律。
无论AI补全多顺滑，包名落进配置文件的那一刻，必须经过人工确认。我在自己的项目里定了一条铁律：凡是AI补全出来的依赖，不允许直接进入锁文件。我会先单独执行一次“信息核查”：
- 这个包在公共源上是否真实存在？下载量、更新时间、维护者信息是否合理？
- 这个包名是否与项目里的内部包命名风格过于相似？
- 如果包是从私有源拉取的，registry配置是否锁定了私有源优先级？
第二，锁定registry，从源头收紧回退通道。
以npm为例，~/.npmrc或项目根目录的.npmrc可以配置scope级别的registry，确保内部包只从内部源获取，不落到公共源：
ini复制@company:registry=https://registry.internal.company.com/
registry=https://registry.npmjs.org/
Python生态可以用pip config或uv的index策略锁定源：
bash复制# 使用uv时，限定只能从内部索引安装，公共PyPI作为兜底
uv pip install --index-url https://pypi.internal.company.com/simple --extra-index-url https://pypi.org/simple
但要注意，单纯配置extra-index-url并不能完全阻止依赖混淆。部分包管理器解析时会把多个源的结果合并取最高版本，反而可能让公共源的恶意包“浮上来”。最稳妥的方式是对私有包使用scoped registry或完全隔离的索引，配合lockfile固定版本。
第三，安装依赖后及时核对锁文件变更。
很多CI流水线已经启用了lockfile，但开发者的本地环境往往是漏洞高发区。一个常见的做法是：在CI中增加“锁文件与声明文件一致性校验”，任何依赖的变更都必须有明确的提交记录，不符合预期的diff直接阻断构建。
4.2 安全团队侧：从登记到监控建立闭环
第一，建立内部包名台账。
安全团队要搞清楚一个最基本的问题：我们内部到底有哪些包名？很多公司其实并不清楚自己的私有包全家桶。建立一份完整的内部包名登记表，包含包名、版本、维护者、代码仓库地址、负责人联系方式，这是防御依赖混淆1.0和2.0的共同基础。
有了台账，就可以做一件很重要的事：持续监控公共源是否存在与内部包名相同或高度相似的注册包。 当监控系统发现某个公共包的名称与内部包名一致，或只是末尾多了连接符、版本号异常时，立即触发告警。这些很可能就是攻击者提前埋下的雷。
第二，对AI编码工具做“来源标注”。
如果团队已经大范围启用AI代码助手，建议把IDE中AI补全的“来源标注”功能打开，并提醒团队成员注意查看。这个功能目前在不同工具里的实现方式略有差异，但大体思路一致：当你接受了一个补全结果，IDE会用小字标注这段代码可能来自哪些公开仓库或上下文来源。这虽然不能直接阻止恶意包，但能大幅提高开发者的审查意识。
更进一步，可以结合代码扫描工具，为AI补全的依赖增加“白名单校验”：如果AI推荐的包名不在项目已有依赖、不在企业白名单内，就在IDE中显示一个显眼的警告横幅。目前市面上已有部分IDE插件实现了这个能力，安全团队可以通过定制内部的IDE扩展来接入。
第三，对安装行为做动态监控。
传统的SCA扫描是静态的，对“安装时触发恶意代码”这类行为难以感知。我更推荐在CI/CD流水线和关键开发机部署动态执行监控，关注依赖安装过程中的异常行为：有没有执行与安装无关的命令？有没有访问外网域名？有没有读取敏感文件？这类行为在正常情况下几乎不可能出现，一旦出现就值得立即拉响警报。
4.3 一条实用规则：补全包名的“一秒怀疑”
最后分享一个我自己强制养成的习惯。每次AI补全出一个我不确定来源的包名时，我会在心里停顿一秒，问自己两个问题：
问题一：这个包名为什么会出现在我的上下文里？ 是项目本身就在用，还是它“合理地”出现在了一个需要新依赖的场合？
问题二：如果不用AI补全，我会搜索什么关键字来找到这个包？ 如果搜索出来的结果与AI补全的包名不一致，说明AI的推荐很可能来自一个我不熟悉的来源，这时候必须停下来。
这个习惯的成本只有一秒，却足以打断“无意识回车”的自动化偏见。依赖混淆2.0攻击链条里，最脆弱、最可干预的环节恰恰是开发者接纳补全结果的瞬间。
5. 供应链安全的重心转移：从防护漏洞到守护决策
依赖混淆2.0揭示了一个更深层的变化：在AI参与编码的时代，供应链安全的防御对象已经不只是“代码里有没有漏洞”，而是“代码从哪来、经过什么决策机制进入你的项目”。
传统供应链安全的核心是“软件物料清单”（SBOM）和漏洞扫描，回答的是“我的软件里包含哪些组件、这些组件有没有已知漏洞”。但依赖混淆2.0的攻击链表明，组件本身的选择过程就是一个全新的攻击面。攻击者不再攻击一个具体的仓库或软件包，而是攻击“人选择组件”的行为模式。AI自动补全作为高效编码的助手，恰好成了这个选择过程的中枢。
这意味着未来的防御需要几个方向上的突破：
一是可信补全。AI编码工具应当提供“包名来源可追溯性”的能力，在补全依赖时明确标注这个包名的来源域（公共源、私有源、未注册名称）、注册时间、下载量、签名状态。就像浏览器地址栏对HTTPS证书的标注一样，让开发者在几毫秒内判断这个包是否值得信任。
二是依赖决策留痕。每一次新依赖引入，都应该记录“为什么选择这个版本、这个来源”，而不仅仅是最终lockfile里的版本号。当团队事后审计时，能够还原当时的选择链路——这次引入是人为决定，还是AI补全后的机械接受？
三是自动化投毒情报的共享。恶意包抢注和认知污染的特征往往具有重复性，比如同一批注册者、相似的包名变体、相同的恶意安装脚本。安全社区如果能建立更高效的包名投毒情报交换机制，就能在整个生态内缩短攻击者的“武器利用窗口期”。
这些方向不是某个单一工具能解决的，需要IDE厂商、包管理器维护者、安全团队和开发者共同推进。但在此之前，每个人都应该先把自己手头的基础纪律捡起来：锁好源、核好名、不盲信补全。
我在实际使用AI编码工具的过程中，最大的感受是：工具越智能，越需要人去补足它“看不见”的那部分。AI擅长的是把高频模式变成高效输出，但它不关心这个模式是否来自一个恶意源头。依赖混淆2.0之所以能成立，恰恰是因为我们默认了AI的推荐“无恶意”。这个默认假设，正在成为供应链上最危险的盲区。
所以，下一次AI帮你补全了一个陌生包名时，多看一眼那个名字。也许就是这一眼，替你挡下了一条本不该存在的依赖链。