幽灵依赖:Agentic Coding 范式下的新型供应链安全威胁
Author: Tianchu Chen of Tencent Xuanwu Lab
0x00 简介
随着 LLM(大语言模型)能力的跃升,AI 软件开发模式正从“人写代码,AI 补全”的 Copilot 模式,向“AI 主导决策,自动执行”的 Agentic Coding 模式演进。在 Agentic Coding 模式下,AI 不再仅仅是生成代码的辅助工具,而是转变成了能够自主规划任务、选择技术栈、操作文件系统甚至执行命令的智能体。
然而,这种控制权的转移引入了新的攻击面:AI Agent 代替用户主动进行决策,但这些决策未必总是安全的。我们在市面上主流的 Agentic Coding 工具及其背后的 LLM 进行了深入的测试和分析,发现了一些普遍存在的 AI 决策风险。其中,与软件供应链相关的一类 AI 决策风险可能产生持久而隐蔽的影响,我们将其命名为“幽灵依赖”。
通过进一步的分析和实验,我们确认了“幽灵依赖”风险在真实世界的 Agentic Coding 工作流中普遍存在,这一风险不仅导致 AI 编程产出质量的不稳定性,还引入了现实安全威胁:攻击者利用通过分析特定模型在特定场景下的“幽灵依赖”行为模式,即可通过利用已知 N-day 漏洞、供应链投毒等方式,将恶意代码植入到 AI 生成项目中。
针对这些风险,我们提出了基于 Pre-Execution Hooks 的 AI 供应链决策风险防御架构,并开发了插件式解决方案:Atuin(阿图因)。这一防护方案已上架腾讯云 CodeBuddy Code 官方插件市场。
0x01 技术背景
在传统的软件开发流程中,人类开发者是产生、执行决策的主体,安全责任边界相对清晰。但在 Agentic Coding 场景中,IDE、CLI 环境为 AI Agent 提供了自主产生、执行决策的能力。其典型工作流如下:
- 意图理解:AI 处理用户输入的模糊指令,例如:“建立一个 Django 网站”。
- 产生决策:AI 在思考过程中,自主决定引入哪些第三方库、选择哪个版本。
- 执行决策:AI 自动生成组件依赖清单文件(requirements.txt、package.json), 并执行pip install、npm install 等命令完成下载、安装的过程。
在这类工作流中,AI Agent 为真正产生和执行决策的主体,用户不再参与其中,这种控制权的转移带来了威胁模型的变更:试图进行供应链攻击的攻击者不再需要想办法欺骗人类开发者,只需利用 LLM 本身存在的缺陷,即可在用户信任 AI Agent 并放任其执行供应链决策的过程中,通过欺骗 AI 植入恶意代码。
0x02 威胁模型
在 Agentic Coding 场景下,AI 模型需要自主完成供应链决策工作。在对主流 Agentic Coding 工具、和业界先进 LLM 模型的供应链决策过程测试过程中,我们发现了普遍存在的一种供应链安全风险。这些风险是由于 LLM 的概率预测本质导致的,我们将其命名为“幽灵依赖”:
- R1 - “版本幽灵”:LLM 倾向于引入训练数据中高频出现的旧版组件,而非最新版本。
- R2 - “名称幽灵”:我们进一步发现,LLM 有概率“捏造”出不存在的组件名。这一“幻觉”行为与特定模型相关且具备可预测性。
基于这些安全风险,我们定义了以下两种针对 Agentic Coding 开发模式的供应链威胁:
- T1 - 过时组件版本的 N-day 漏洞利用: 攻击者利用 LLM 引入过时版本组件的行为模式,扫描出 AI 生成项目存在的 N-day 漏洞并利用。
- T2 - 针对幻觉组件名的定向投毒: 攻击者利用 LLM 在“组件名幻觉”方面的可预测性,针对特定 LLM 模型预测并抢注 AI 可能“捏造”的包名。当 Agent 产生相同幻觉时,自动下载恶意包。
需要指出的是,针对组件名的定向投毒并非 Agentic Coding 所特有的新型威胁。在“AI 编程”这一概念出现之前,就存在大量试图利用人类开发者的拼写错误,在公共组件仓库中注册易混淆的名称并植入恶意代码的供应链投毒攻击案例。尽管公共组件仓库中的“组件名投毒”攻击是早已存在的安全威胁,但 Agentic Coding 范式的普及显著集中并放大了这一威胁的危害性:
- LLM 输出“幻觉组件名”的可预测性更强:与人类开发者的随机拼写错误相比,特定 LLM 更加倾向于产生有规律、可预测的“幻觉组件名”,更强的可预测性大幅降低了投毒攻击的成本。
- AI Agent 的下载、安装行为会被自动执行,无需人类介入:在传统的人类主导的开发模式下,人类开发者遇到不熟悉的组件时,可通过官网、官方仓库等渠道确认组件名拼写是否准确。与其相反的是,AI 主导的 Agentic Coding 工作流中,决策由 LLM 自主产生并通常自动执行、无需人类干预,这一控制权的转变导致针对 AI Agent 的“幻觉组件名”投毒攻击更难以被人类提前发现和阻止。
0x03 实验与分析
我们选取了一个模型(以下用“模型 A”指代)作为测试对象,这一模型在数学、编码、工具调用等方面的测试基准上接近前沿水平,API 调用量在 OpenRouter 上排名前五,是当前主流编程模型之一。
在我们针对模型 A 的多次调用、测试过程中,我们发现了普遍存在的“幽灵依赖”风险:
- Python 开发场景下几乎总是存在的“版本幽灵”风险:我们发现,受限于训练数据集分布,在 Python Web 开发场景下,模型 A 输出的 requirements.txt 几乎总是包含发布于 2023 年甚至更早时间的过时组件版本。
- 特定复杂需求下触发概率高达 40% 的“名称幽灵”风险:我们进一步对模型 A 提出更为复杂、涉及到特定长尾需求的请求,例如:要求模型引入能改善 Web 项目视觉效果的组件。在我们的测试场景下,模型 A 编造组件名的幻觉率高达 40%,这些“组件名幻觉”集中在几个特定的模式上,容易被攻击者预测。
对模型的测试工作表明,在没有被植入恶意提示词/恶意代码的“干净”开发环境中,仅仅是正常部署 Coding Agent 并放任其自主产生供应链决策,T1、T2 威胁都具备较高的触发率和可预测性。
为了进一步分析这些威胁在现实世界的影响,我们在真实世界的 Agentic Coding 工作流中设计了一些实验:
- 过时组件版本的 N-day 漏洞利用尝试:基于模型 A 在过时组件版本方面的倾向,我们在主流 Agentic Coding 开发环境中,完全由 AI 构建并部署了一个 Python Web 应用。在开发过程中,由于模型 A 引入了存在高危 SQL 注入漏洞的过时组件版本,导致这一 Web 应用“出厂即自带后门”。攻击者利用这一 N-day 漏洞,即可远程窃取数据库中的敏感信息。
- 针对幻觉组件名的注册尝试:针对模型 A 的某一高频“幻觉组件名”,我们尝试在公共组件仓库中注册这一名称,注册过程中使用了多个模型 A 高概率输出的版本号。去除镜像服务器同步导致的非安装下载量后,在 20 天的观察窗口内,这一“幻觉组件名”被下载了 500 次以上,下载量接近“原版”组件的千分之一,显著高于仓库中无人使用的组件。
这些实验表明,在真实世界的 Agentic Coding 开发环境和 AI 生成项目的部署环境中,外部攻击者可以利用模型的“幽灵依赖”风险,以较低成本产生隐蔽、持久的严重威胁:扫描 AI 生成项目中组件 N-day 漏洞即能窃取敏感信息;在公共组件仓库中注册“幻觉组件名”并上传恶意代码即可“一次投毒、持续受益”。
注:实验过程遵循“最小影响”原则:N-day 漏洞利用尝试在可控的模拟环境中执行;在注册“幻觉组件名”时,我们仅上传了必要的组件名称、版本等元数据,不包含可执行的代码;组件下载量统计数据来源于公共组件仓库提供的公开数据集;在完成观察后,我们删除了公共组件仓库中“幻觉组件名”的所有组件版本,同时保留对组件名称的占位,从而在避免这一组件后续被产生幻觉的 AI Agent 安装的同时,防止组件名被恶意用户抢注。
0x04 防护方案
传统的代码扫描(SAST)和依赖检查(SCA)通常是设计为在代码提交后、发版之前执行的安全检测流程。当开发模式迁移到 Agentic Coding 后,由于 AI 已代替用户直接进行供应链决策,并即时执行下载、安装第三方组件等风险操作,传统防御方式存在明显的滞后性劣势,无法应对 AI 自主行为导致的即时存在的威胁。
为了解决这一问题,我们认为有必要将防御边界从传统的“代码提交后”阶段,左移至 Coding Agent 产生、执行决策的瞬间。
基于这一思想,我们设计了 Atuin 插件的防御方案。这一方案利用了现有 Coding Agent 的 Pre-Execution Hooks 能力,在 AI Agent 做出决策之后、执行具体决策之前进行介入,验证并排除安全风险。
方案的工作流程如下:
Pre-Execution Hook 触发:在 Agent 试图写入组件依赖清单文件(如 requirements.txt),或执行组件安装相关命令(如 pip install)等行为之前,触发 Atuin 插件的审计流程。
行为审计:
- 组件信息获取:基于 Atuin 所积累的供应链组件数据库,获取组件信息。
- 版本评估:比对 Atuin 供应链安全风险数据库,检测选定版本是否包含高危 N-day 漏洞。
- 幻觉和恶意组件检测:分析 AI 试图安装的组件是否为已知的恶意组件、排除 AI 的“组件名幻觉”。
干预措施决策:Atuin 根据行为的风险级别、以及静默修复的可行性,进行干预措施的决策:
- 放行:无风险行为直接放行。
- 静默修复:将已知存在风险的版本替换为最新的安全 Patch 版本;将幻觉包名修正为真实包名。
- 重试:将风险告知 AI Agent,并要求其再次尝试。
- 阻断:检测到恶意组件风险时,直接终止操作并告警。
0x05 案例展示
在启用 Atuin 插件的环境中,用户要求 Coding Agent 生成一个 Python Web 网站。AI 随即生成了一份依赖清单文件 (requirements.txt):

这一依赖清单引入了存在 SQL 注入漏洞的 Django 4.2.7,和一个 AI 编造出来、实际上并不存在的“幻觉组件名”。
Atuin 插件在 requirements.txt 文件被写入前即检测到问题,把 Django 替换成最新安全版本,把已知“幻觉组件名”替换成正确组件名称。整个过程不需要人工干预,在修复完成后继续将控制权交给 Coding Agent 以完成后续工作。
人类开发者在输入 Prompt(提示词)时的拼写错误,同样可能导致 Agent 自动执行危险行为。当用户输入“安装 aihottp 组件”时,AI 被用户的拼写错误所影响,试图安装已被投毒的组件。Atuin 插件在执行安装指令之前即检测到 Agent 的行为存在执行恶意代码的风险,随即介入并自动阻断风险操作:

玄武 Atuin 插件当前已覆盖 Python、JavaScript、Go、Rust、PHP 五大主流语言生态。针对不同风险场景,插件会采取不同策略:确认安全的操作直接放行;可修复的问题自动替换为安全版本;无法自动修复时引导 AI 重新选择;检测到恶意包则立即阻断整个操作。
0x06 未来方向
我们还在探索把玄武实验室既往积累的一些基础能力用于解决 AI Coding 中的其它问题——
HaS 脱敏技术
在软件开发过程中,代码仓库可能包含大量敏感信息。硬编码的云服务 AK 密钥、数据库连接字符串、企业内部设施的认证凭据甚至个人隐私数据往往会在代码文件、变更记录中留存。在 AI Coding 场景中,Agent 工作时会自动将本地仓库中的大量代码片段上传到云端大模型 API 进行推理,导致机密信息流出企业安全边界,面临被模型厂商获取的风险。
玄武实验室通过 2 年多的探索和打磨,首创了一套“基于语义同构标签的大模型脱敏技术 HaS(Hide and Seek)”。仅通过端侧部署的小型模型,HaS 就能够实现数据的“出站脱敏”:在本地文件被上传至云端大模型之前,先分析其中的隐私数据并脱敏,将 API Key 等敏感信息替换成占位标签。同时,针对云端大模型返回的数据,进行“入站还原”工作:HaS 会根据之前的替换映射关系,将模型输出中的占位标签还原成原始的敏感信息。
我们正在持续探索 AI Coding 场景中隐私保护能力的落地形态。
实时供应链文档注入
受限于大模型的训练数据分布和训练截止时间,在企业内部框架、长尾第三方组件和前沿领域等场景,AI 编程助手往往会产生大量幻觉:包括臆造不存在 API、使用已废弃的接口等等。
此外,在“从零开始”创建项目时,由于上下文中缺乏最佳实践案例,AI 编程助手通常只是追求“能跑就行”,随意产生仅仅“可运行”的代码,而在代码安全性、可维护性等方面存在高随机性。
为了解决这一难题,Atuin 插件将基于玄武在供应链安全研究中积累的大量高质量第三方组件文档与领域内开发规范,提供实时供应链文档注入能力:当 AI 编程助手用到供应链上组件时,玄武插件可检索该组件的最新文档、API 定义和最佳实践,注入到大模型的上下文中。
这一功能未来会以插件更新的形式发布。
0x07 Atuin 插件背后的技术能力
Atuin 插件源自玄武的“阿图因”软件空间测绘系统。
“阿图因”软件空间测绘系统由玄武实验室于 2015 年开始研发,具有可跨平台、自动发现、安装、分析全网软件的全流程自动化的大规模检测能力,并引入了人工智能、语义识别等多种技术,是世界范围内第一次实现的无需任何人工适配的、面向全网所有软件的全自动安装系统,是一个“面向二进制软件空间的‘搜索引擎’”。
目前“阿图因”已收录了跨平台各类软件、应用 5000万+,以及各平台各类组件、SDK 样本超千万。“阿图因”曾多次支持国家网络安全主管部门的应急响应工作,2017 年入选世界互联网大会领先科技成果,2025 年获中国商业联合会科学技术奖技术发明特等奖。
0x08 如何使用?
目前,Atuin 插件已在腾讯云 CodeBuddy Code 官方插件市场发布,向所有 CodeBuddy Code 用户免费开放,安装只需一行命令:
1 | /plugin install atuin@codebuddy-plugins-official |
安装完成并重启 CodeBuddy Code 后,插件会自动在后台运行,对开发流程完全透明。它无缝嵌入现有的 AI 编程工作流,在不干扰开发者正常操作的前提下,实现对供应链风险的持续监测与防御。