修炼AI技能
AI 教程 / AI 安全与对齐 / AI 供应链安全：依赖、模型与数据三道关卡

AI 供应链安全：依赖、模型与数据三道关卡

当你加载一个开源模型、安装一个 Python 包、或喂入一批训练数据时，你引入的并不只是功能，还有这些产物背后整条供应链的信任。传统软件供应链攻击（投毒依赖、伪造发布）在 AI 时代被放大了：模型权重本身是可执行载荷，训练数据能改变模型行为，部署管线则把这一切接进生产系统。本文按「代码依赖、模型权重、训练数据」三道关卡拆解 AI 供应链的投毒风险，并给出可落地的防护清单。文中与本站「llm-security」「data-privacy-ai」两篇互补，点到为止。

什么是 AI 供应链

AI 系统的构建不是从零写代码，而是不断复用他人的产物。一条典型的 AI 供应链由以下环节串联：

代码依赖（第三方包、CLI 工具）至 模型权重（预训练/微调后的 checkpoint）
至 训练与微调数据（公开语料、标注集、合成数据）
至 部署管线（推理服务、向量库、插件、agent 工具）

每一环都可能成为投毒入口。攻击者不需要攻破你的服务器，只需在你信任的某个上游环节埋入恶意内容，它就会顺着依赖关系一路流向最终产品。这正是供应链攻击比普通漏洞更难防御的原因：你信任的，未必值得信任。

代码依赖投毒

AI 项目高度依赖 Python 生态（torch、transformers、numpy 等）以及各类命令行工具。代码依赖投毒主要有三种手法。

抢注相似包名（typosquatting）

攻击者在 PyPI、npm 等公共仓库发布与知名包仅差一两个字符的恶意包，例如把 torch 伪装成 torcg、t0rch。开发者手误或复制粘贴时就会装错。恶意包在 import 阶段即可执行任意代码。

私仓名被公网抢注（dependency confusion）

企业常在内部私有仓库用专属包名（如 company-ai-utils）。若构建配置同时允许公网源，攻击者只需在公共仓库抢注同名包并写入更高的版本号，包管理器可能优先拉取公网版本，从而把恶意代码带进内网构建。关键风险在于：内部包名对外是「未占用的」，等于一块公开的空地。

恶意 postinstall 脚本

部分包在 pip install 或 npm install 时自动执行安装后脚本。即便包名无误，其 setup.py 或生命周期脚本里也可能藏有外联、提权或挖矿逻辑。因为脚本在「安装」阶段就以当前用户权限运行，危害往往在安装完成时已经发生。

案例：xz-utils 后门（CVE-2024-3094）

2024 年 3 月，开源压缩库 xz-utils（含 liblzma）被发现在上游发布包中植入了后门。该后门自 5.6.0 版本起进入上游 tarball，通过一系列复杂混淆，在 liblzma 构建过程中从一个伪装的测试文件里释放出预编译目标文件，进而改写 liblzma 的特定函数。被篡改的库可被任何链接它的软件调用，从而拦截并篡改与该库的数据交互。由于 sshd 等程序经由系统库间接依赖 liblzma，该后门被广泛报道可针对 SSH 连接实施认证绕过。

该漏洞编号为 CVE-2024-3094，NVD 评定为 CVSS 3.1 基础分 10.0（CRITICAL），关联弱点类型 CWE-506（内嵌恶意代码），受影响版本为 xz 5.6.0 与 5.6.1，于 2024 年 3 月 29 日由 oss-security 邮件列表公开披露。这起事件并非「装错包」，而是攻击者长期渗透上游维护者、直接污染官方发布物，是供应链攻击的标杆案例。

CVE-2024-3094 关键事实（已核验）
- 受影响软件：xz / liblzma，版本 5.6.0、5.6.1
- 危害：构建期释放后门，可拦截并篡改库的数据交互，波及 SSH 等链路
- 评级：CVSS 3.1 基础分 10.0 CRITICAL，CWE-506
- 披露：2024-03-29，经 oss-security 邮件列表公开

模型供应链

模型权重是 AI 供应链里最特殊的产物：它既是数据也是可执行载荷。加载一个恶意权重文件，可能比装一个恶意包更直接地危害你的环境。

模型权重投毒

攻击者在开源权重中埋入后门：平时模型表现正常，一旦输入命中特定触发模式（trigger），就输出攻击者预设的恶意结果。例如一个被投毒的审查模型，对带特定水印的样本「放行」违规内容；或一个被投毒的分类器，在金融风控场景下对特定实体给出错误判定。这类后门在权重文件里难以靠肉眼发现。

来源可信：恶意仓库与反序列化风险

Hugging Face 等社区托管了大量模型仓库，其中混杂着未经验证的第三方内容。两类典型风险值得注意：

一是恶意仓库本身。攻击者可能发布名称仿冒知名模型的仓库，或在仓库中夹带可执行脚本（如 model.py、自定义的加载逻辑），诱导使用者运行。

二是 pickle 反序列化风险。PyTorch 默认的权重格式（pytorch_model.bin 等）基于 Python 的 pickle 序列化。pickle 在「反序列化」时会执行其中的指令流（opcode），这意味着加载一个恶意 pickle 文件即可触发任意代码执行。官方文档明确指出：不要对不可信来源的数据执行反序列化。Hugging Face 为此提供了 Pickle Import 扫描，会把 pickle 文件引用的导入列表展示出来并高亮可疑项，同时结合 ClamAV 做基础扫描，但官方也声明这并非百分之百可靠，最终仍需使用者自行判断。

用 safetensors 替代 pickle

Hugging Face 提出并推广了 safetensors 这一更安全的权重序列化格式。它的核心区别在于：只保存张量数据，不做任意代码执行，因而在加载时不会触发反序列化攻击。在条件允许时，优先下载和使用 .safetensors 格式权重，是用最小成本挡住 pickle 风险的有效手段。

校验哈希与签名

对下载的权重文件，应校验其哈希值（如 SHA-256）是否与发布方公布的一致，并尽量使用带 GPG 签名的 commit 来确认来源。签名不能保证文件内容绝对安全，但能确认「这个文件确实出自你所信任的那个人」。

# 校验权重文件哈希是否匹配发布方公布的值
sha256sum model.safetensors

# 优先加载 safetensors，并对来源仓库做签名/可信度确认（示例伪流程）
python -c "from safetensors.torch import load_file; w = load_file('model.safetensors')"

模型供应链防护要点（已核验要点来自 Hugging Face 安全文档）
- 避免加载不可信来源的 pickle 文件（反序列化即可能执行代码）
- 优先使用 safetensors 格式权重
- 加载 TF / Flax 格式权重再转 PyTorch 也可规避 pickle 风险
- 用 GPG 签名 commit 确认来源，靠 Hub 的 Pickle Import 扫描做二次检查

数据投毒

训练与微调数据决定了模型「学到什么」。数据投毒指攻击者在训练集、微调集或检索语料中注入精心构造的恶意样本，使模型习得后门或偏见。

典型情形包括：

  • 在公开爬取的语料里掺入带触发词的样本，让模型对特定输入产生错误行为。
  • 在用于微调的标注集中替换标签，使模型在关键场景判定失误。
  • 在 RAG 系统的知识库文档中嵌入隐藏指令，间接影响模型输出。

数据投毒的危害具有隐蔽性：模型在常规评测上表现正常，直到触发条件出现才暴露。防护上应对训练数据做来源核验、去重与异常检测，对高敏感场景的微调数据做人工抽检，并在上线前用对抗样本与触发词探测进行红队验证。

防护清单

把上述三道关卡落到工程实践，可归纳为以下清单：

第一关：代码依赖
- 锁定依赖：提交 lockfile（如 requirements.txt 锁定版本、poetry.lock），禁止浮动版本
- 使用私有镜像或内部代理源，关闭公网回源，杜绝 dependency confusion
- 安装前审查包名拼写，警惕与知名包高度相似的名称
- 扫描依赖漏洞：pip-audit、Safety 定期扫描并接入 CI
- 在隔离环境安装，限制 postinstall 脚本的执行权限

第二关：模型权重
- 只用可信来源的模型，优先 safetensors 格式
- 校验权重哈希，尽量核对 GPG 签名 commit
- 借助 Hugging Face 的恶意模型/Pickle 扫描做二次确认
- 加载模型在沙箱或容器中执行，限制其文件系统与网络权限

第三关：训练数据
- 训练/微调数据集记录来源与版本，可回溯
- 对外部语料做去重、异常与触发词检测
- 高敏感数据做人工抽检，上线前红队验证

通用底线
- 最小权限：模型运行账户、Agent 令牌只授予必要权限
- 沙箱化：依赖安装、模型加载、工具调用均在受限环境中执行
- 人类在环：不可逆动作需人工确认，关键操作留审计痕迹

# 依赖漏洞扫描示例
pip install pip-audit safety
pip-audit
safety check

# 用私有镜像源安装，避免公网回源造成依赖混淆
pip install -i https://your-internal-mirror/simple/ transformers

关联 OWASP LLM Top 10

供应链风险已被主流安全框架明确收录。在 OWASP 维护的《Top 10 for Large Language Model Applications》2023 v1.1 发布版中，第 LLM05 条即为「Supply Chain Vulnerabilities（供应链漏洞）」，其定义为：依赖被攻陷的组件、服务或数据集，会破坏系统完整性，导致数据泄漏与系统故障。这与本文三道关卡一一对应：代码依赖对应被投毒的包与组件，模型权重对应被投毒的模型，训练数据对应被投毒的数据集。

此外，LLM03「Training Data Poisoning（训练数据投毒）」与本篇第四部分直接呼应，说明数据投毒在框架中既属于供应链范畴，也被单独列为独立风险。值得注意：OWASP 已于 2026 年推出新版 GenAI LLM Top 10，条目编号与命名可能发生变化，具体以官方最新发布为准（待核实）。

OWASP LLM Top 10（2023 v1.1，已核验）
LLM01  Prompt Injection              提示注入
LLM02  Insecure Output Handling      不当输出处理
LLM03  Training Data Poisoning       训练数据投毒
LLM04  Model Denial of Service       模型拒绝服务
LLM05  Supply Chain Vulnerabilities  供应链漏洞（含投毒的包/模型/数据集）
LLM06  Sensitive Information Disclosure 敏感信息泄漏
LLM07  Insecure Plugin Design        不安全插件设计
LLM08  Excessive Agency              过度代理
LLM09  Overreliance                  过度依赖
LLM10  Model Theft                   模型窃取

小结

AI 供应链把「代码依赖、模型权重、训练数据」三道关卡串成一条信任链，任何一环被投毒都会顺流危及最终系统。代码依赖侧要警惕抢注相似包名、私仓名被公网抢注与恶意安装脚本，xz-utils 后门（CVE-2024-3094）证明了上游发布物本身也可能被污染。模型侧要规避 pickle 反序列化执行风险、优先采用 safetensors、并校验哈希与签名。数据侧需对训练与微调样本做来源核验与后门探测。工程上以锁定依赖、私有镜像、漏洞扫描、模型来源校验、最小权限与沙箱构成纵深防御，并与 OWASP LLM Top 10 的 LLM05、LLM03 对齐落地。

参考与延伸阅读

本文累计阅读 — 次