大模型安全之四:供应链安全

1、引言

2026年3月，全球约2500家企业经历了一个难忘的凌晨。在约40分钟的攻击窗口内，AI API 网关 LiteLLM 遭到供应链投毒，攻击者卷走了195TB的凭据数据，波及英伟达、三星、亚马逊、思科等数十家科技巨头。安全公司CloudSEK将此次事件定义为2026年最大规模的AI供应链泄露。

这不是演习，而是AI供应链安全的真实警钟。随着AI相关产品的爆发式开发，供应链安全问题已从技术选型问题上升为关乎企业生存的战略问题。AI产品的供应链安全与传统软件供应链安全之间，是"继承"与"扩展"的关系------它们在很多基础层面保持一致，但因为AI引入了"模型""数据"和"智能体"这些全新要素，也带来了一系列独特的风险和挑战。

本文将从相同点、不同点、安全合规差异和治理策略四个方面，系统剖析两种供应链的全貌，并通过真实攻击事件帮助理解风险的现实形态。

2、共同根基：AI与软件供应链的相同之处

AI产品供应链安全建立在传统软件供应链安全的基础之上，两者的核心关切和目标是一致的。

2.1. 共享软件供应链的通用风险

AI产品也由代码构成，依赖于操作系统、编程语言库、第三方软件包、开发工具和CI/CD管道等基础设施。因此，它会遇到所有传统软件都会遇到的风险：开源组件漏洞、依赖项投毒、代码仓库被篡改、开发管道被入侵等。这些共同的风险点构成了AI供应链安全的"地基"。

2.2. 都需要对"物料"进行管理与追踪

传统软件供应链强调软件物料清单（SBOM） 。AI产品也引入了与之类似的管理清单，如AI物料清单（AI BOM），用于记录模型所依赖的组件、数据源和算法版本。管理逻辑相通------通过"物料清单化"实现供应链的可视化和可审计性。

2.3. 都遵循相似的治理框架

无论是传统软件还是AI产品，供应链安全治理都遵循"识别-保护-检测-响应-恢复"的基本逻辑。NIST发布的AI网络安全框架指南，其核心架构就基于通用的NIST CSF 2.0框架。优秀的安全实践在AI领域依然适用。

3、根本差异：AI供应链的独特挑战

AI产品供应链与传统软件供应链最大的不同，在于它引入了数据、模型和AI智能体 三个全新的核心元素。中国电子技术标准化研究院的分析指出，AI时代的软件供应链呈现出三大新特征：开发模式智能化、组件依赖复杂化、数据模型一体化。

3.1. 核心资产的差异：从"代码"到"数据+模型+代码"

对比维度	传统软件供应链	AI产品供应链
核心资产	源代码和编译产物	数据、模型权重、代码、AI Agent技能
资产保护重心	代码不被篡改	模型和数据的完整性更为关键
新增资产	无	训练数据集、预训练模型、Agent技能/插件

AI核心资产的安全风险可分为四类：

• 数据供应链风险：训练数据污染（注入恶意数据、篡改标签）、数据泄露与滥用、数据质量缺陷传导

• 模型供应链风险：模型后门（预训练模型被植入隐蔽后门）、模型投毒、模型泄露、模型滥用

• 开源组件与工具链风险：开源库漏洞、AI工具链被植入恶意代码、依赖关系管理混乱

• 全生命周期安全管理风险

3.2. 攻击面的扩展：从"代码漏洞"到多重攻击向量

AI供应链引入了全新的攻击向量，攻击面从"代码层"扩展到了多个层面：

攻击层面	传统软件供应链	AI产品供应链
软件/代码层	漏洞利用、开源组件漏洞	同样存在，且AI代码助手可能生成含漏洞的代码
数据层	配置文件被篡改	数据投毒：攻击者向训练数据注入恶意数据，植入后门
模型层	不存在	模型后门/篡改 ：后门向下游所有应用传递 模型逆向/窃取：通过API窃取模型参数
Agent/工具链层	不存在	Agent技能投毒 、Prompt注入导致行为失控

4、真实攻击事件：AI供应链的风险现实

事件1：LiteLLM 投毒------2026年最大规模AI供应链泄露

发生时间：2026年3月

攻击手法：攻击者TeamPCP没有直接攻击LiteLLM 本身，而是盯上了其CI/CD流水线中用到的开源安全扫描工具Trivy。他们重写了Trivy的Git标签，把恶意代码塞进v0.69.4版本。LiteLLM的流水线没有锁定Trivy的具体版本号，每次都拉最新版。恶意代码就这样混进了构建环境，偷走了PyPI的发布令牌。

拿到令牌后，攻击者向PyPI推送了两个带毒的LiteLLM 版本（1.82.7和1.82.8）。从上传到PyPI隔离，整个过程不到3小时，但恶意版本被下载了超过11.9万次。

攻击后果：恶意代码将受害者机器上能找到的所有凭据打包传走，包括：

• 云服务商密钥（AWS、Azure、GCP）

• Git仓库Token

• SSH私钥

• Kubernetes配置

• AI服务商的API Key

• 加密钱包和SSL私钥

泄露数据显示，仅CI/CD流水线凭据就约43.4万条。受影响企业包括英伟达、亚马逊、三星、思科、Salesforce、西门子、大众汽车等数十家知名企业。

关键漏洞 ：PyPI从恶意包上传到第一个用户举报，间隔了1小时19分钟 ，没有任何自动化安全机制发现异常。OpenAI创始人Andrej Karpathy评论称，如果不是恶意代码本身有个实现缺陷（触发递归分叉炸弹把机器搞崩溃），这个恶意软件本可以静默运行更长时间，造成的破坏会大得多。

事件2：Mini Shai-Hulud供应链蠕虫

发生时间：2026年5月

攻击范围 ：该蠕虫攻击了TanStack、Mistral AI SDK、UiPath等组织的npm/PyPI包，影响超过170个软件包 。攻击者还注册了拼写近似域名git-tanstack[.]com进行钓鱼。

攻击手法 ：利用GitHub Actions的pull_request_target触发器和跨fork缓存读取漏洞，攻击者通过恶意PR从受保护的CI/CD环境中窃取发布凭证，然后用窃取的Token向npm/PyPI发布恶意版本。恶意包在安装时会搜集所有可及的凭据并外传。

事件3：FlowiseCVE-2025-59528------配置路径变RCE

2026年4月，攻击者开始积极利用Flowise（一个LLM应用低代码平台）的最大严重性漏洞。该漏洞涉及对CustomMCP配置数据的不安全处理，允许注入任意JavaScript代码并执行。这意味着AI工作流的"配置"表面直接变成了代码执行路径，数千个暴露的AI工作流实例面临服务器失陷风险。

5、AI Agent带来的新型供应链风险

传统供应链管控（签名、扫描、信任仓库）是为"静态组件"设计的。但AI Agent通过LLM在运行时解释指令来决定行为，其"意图"而非"代码"驱动动作。这种行为可审计，但行为背后的"推理"可能是不可知的。

关键风险点

1. Agent行为的不确定性：传统软件组件行为是确定性的、可扫描验证的；AI Agent的行为由LLM运行时动态组装，无法通过静态扫描预判。

2. 权限继承放大风险 ：Agent技能库允许经验不足的开发者上传未经验证的技能。研究发现，ClawHub上3984个AI技能中534个存在关键安全漏洞 ，另有824个恶意技能。传统npm/PyPI被攻破后恶意代码在应用边界内执行，但AI技能可继承Agent的全部权限，影响范围大幅扩大。

3. Prompt注入导致动态行为失控：攻击者可在文档、PDF或邮件中嵌入隐蔽指令，LLM可能将这些指令解释为应遵循的行动，Agent随之执行数据窃取、权限滥用等操作。

4. MCP（模型上下文协议）新攻击面 ：AI Agent广泛使用的MCP STDIO传输层存在风险------如果允许用户控制输入流向命令、参数或环境变量字段，攻击者可实现远程代码执行。安全研究识别出超过7000个公开暴露的MCP服务器，本应仅供本地开发者使用。

6、安全合规的差异与关键要点

6.1. 核心差异对比

对比维度	传统软件供应链	AI产品供应链
合规基础义务	提供软件物料清单（SBOM），确保代码来源与组件的透明性	在SBOM基础上，还需建立 "AI物料清单（AI BOM）" ，记录模型来源、训练数据、算法版本等AI特有信息
核心风险焦点	开源组件漏洞与投毒，依赖关系复杂，一个恶意包即可污染下游项目	风险扩展至模型后门、数据投毒、算法偏见、模型"幻觉" 等AI特有风险
法规驱动因素	遵循通用供应链安全法规（如中国《产业链供应链安全规定》国务院令第834号）	除通用法规外，还需遵守专门的AI法规（如欧盟AI Act、中国《人工智能安全治理框架》），面临更严格的市场准入和合规审查
地缘政治影响	主要关注出口管制对芯片等技术获取的限制	遭遇双重挤压：美国通过出口管制限制技术获取，欧盟通过《人工智能法案》等规则设置市场壁垒，合规成本与地缘政治风险叠加
供应链"断供"风险	关键软件或服务（如操作系统、数据库）被禁用的风险	核心风险变为AI模型本身被限制访问。例如，Anthropic的Claude模型就曾因合规要求限制外国用户访问，导致服务中断
监管与透明度要求	强调代码级别的可审计性与可追溯性	增加模型可解释性、算法透明度、训练数据合法性等要求，面对"黑盒"模型，合规证明难度陡增

6.2. AI供应链合规五大要点

针对以上差异，企业在AI产品供应链安全合规上需特别注意以下五点：

① 搭建"双清单"体系

在传统SBOM 基础上，并行建立 "AI BOM" 。AI BOM应详细记录每个AI模型所用的基础模型来源、微调数据集、训练框架及版本、超参数配置等信息，确保从原始数据到最终模型部署的完整链路可追溯。这是应对监管审计和市场准入的基本前提。

② 模型来源的合规审查

对引入的每一个开源或商业模型进行严格的来源审查与安全评估。这包括：

• 分析模型是否存在后门、偏见或有害知识

• 评估模型开发方的背景、信誉和地缘政治风险

• 审查模型许可证的合规性和使用限制

• 确保应用的自主可控，避免因上游模型断供导致业务中断

③ 构建"区域策略配置"能力

鉴于全球AI法规（如欧盟AI Act、中国《生成式人工智能服务管理暂行办法》、美国AI行政令）日趋碎片化 ，AI产品可能需在不同地区提供不同的功能或合规披露。产品设计需具备策略配置层，能根据部署地区自动切换：

• 数据路由（数据存在哪里、流向哪里）

• 功能权限（哪些功能可在该地区使用）

• 审计日志记录级别（满足不同地区的日志留存要求）

• 模型版本（为不同地区部署合规的模型版本）

④ 强化数据与算法备案

在中国，需密切关注并遵循《人工智能安全治理框架》等指引，可能涉及算法备案、安全评估等强制性要求。确保：

• 训练数据的合法合规（数据来源合法、授权清晰）

• 算法透明度和可解释性（满足备案审查要求）

• 内容安全机制（防止生成违法和不良信息）

⑤ 管理供应商的"集中度风险"

金融监管总局等机构已明确要求，防范对个别AI技术服务商的过度依赖。建议：

• 建立多模型架构（可切换不同基础模型）

• 采用多云/本地部署的混合架构

• 定期评估供应商的合规状态和稳定性

• 避免单一供应商因断供、制裁或合规问题导致业务中断

7、治理建议

7.1 管理层面

1. 推行AI BOM：将AI物料清单作为产品交付的标准组成部分。

2. 强化供应商管理：将AI供应商的安全能力、合规性和稳定性作为核心评估指标。

3. **将AI Agent视为"数字员工"**进行身份化、权限化、行为审计化管理。

4. 将AI安全融入现有体系：将AI特有风险纳入组织整体的风险管理框架，如NIST CSF 2.0所建议的，而非另起炉灶。

7.2 技术层面

1. 数据安全：对训练数据进行严格的来源验证、清洗和审计，防止数据投毒。建立数据版本管理机制，确保每一步数据变更都可追溯。

2. 模型安全：对使用的预训练模型进行安全检测，扫描后门和漏洞；对模型接口的访问实施最小权限原则和严格的日志监控；建立模型版本管理机制。

3. 应用安全：在模型上线后，持续监控其输入输出，拦截恶意提示词注入攻击，并建立应急响应预案。

4. 建立专门团队：设立跨部门的安全工作组，或与外部安全实验室合作，专门应对AI供应链带来的新挑战。

8、总结

AI产品供应链安全与传统软件供应链安全是"继承"与"扩展"的关系，而非"替代"关系。企业在应对AI供应链安全挑战时，无需抛弃已有的软件供应链安全体系，而是在其基础上进行认知升级和能力扩展。

AI供应链安全的关键在于将安全思维从"软件代码"扩展到"数据与模型"，从"单点防护"升级为"全生命周期治理"，从"管好自己的代码"延伸到"管好别人的模型"和"应对全球规则碎片化"。只有这样，才能在AI时代构建真正安全、可信、合规的供应链体系。