AI供应链安全：你的AI应用里90%的代码不是你写的

一个被99%的AI开发者忽略的事实

2026年，你开发一个AI应用，代码量可能只有几千行。但你的应用依赖的第三方组件——从PyTorch到Transformers，从LangChain到向量数据库——代码量可能是几百万行。

你写的代码只占10%，剩下90%的代码不是你写的，你也不了解它们。

这就是AI供应链安全的核心问题：你的AI应用的安全性，取决于供应链中最薄弱的一环。

攻击面一：AI框架。 PyTorch、TensorFlow、JAX——这些AI框架是你整个AI应用的基础。如果这些框架有安全漏洞，你的应用就有安全漏洞。

2024年，PyTorch的一个安全漏洞（CVE-2024-XXXX）允许攻击者通过精心构造的模型文件，在模型加载时执行任意代码。这个漏洞影响了几十万个AI应用。

攻击面二：AI模型。 你从HuggingFace下载的预训练模型，是"二进制文件"——你不知道里面有什么。2025年，安全研究人员在HuggingFace上发现了多个"恶意模型"——看起来是正常的开源模型，但实际包含后门代码。

攻击面三：AI库和工具。 Transformers、LangChain、LlamaIndex——这些库让你快速开发AI应用，但它们也是供应链中的一环。2025年，LangChain的一个安全漏洞允许攻击者通过Prompt注入执行任意Python代码。

攻击面四：向量数据库。 Pinecone、Weaviate、Chroma——这些向量数据库存储你的AI应用的"记忆"。如果向量数据库被攻击，攻击者可以窃取、篡改或投毒你的数据。

攻击面五：数据管道。 你的训练数据、微调数据、RAG数据——这些数据从哪来？经过了几次转手？每一步都可能被攻击者投毒。

案例一：PyTorch恶意依赖（2022年12月）。攻击者在PyPI上发布了一个名为"torchtriton"的恶意包（与PyTorch依赖的"pytorch-triton"名字相似）。这个恶意包会窃取用户的SSH密钥。几百个开发者在不知情的情况下安装了这个恶意包。

案例二：HuggingFace恶意模型（2024年）。安全研究人员在HuggingFace上发现了多个包含恶意代码的模型。这些模型利用Pickle反序列化漏洞，在模型加载时执行任意代码。HuggingFace随后加强了模型安全审查，但问题并未完全解决。

案例三：LLM插件安全漏洞（2024年）。ChatGPT插件中的一个安全漏洞，允许攻击者通过一个恶意网站，窃取用户的聊天记录。这个漏洞影响了所有使用该插件的用户。

传统软件供应链：你可以审查代码、检查依赖、使用SBOM（软件物料清单）来追踪每一个组件。代码是"透明"的。

AI供应链：模型是"二进制黑箱"——你无法通过审查代码来发现模型中的后门。模型可能"记住"了敏感数据，可能"学会"了恶意行为，可能被"投毒"了——但你完全无法通过代码审查来发现这些问题。

AI供应链的另一个挑战：模型更新频繁。HuggingFace上每天有数千个模型更新。你无法追踪每一个更新，也无法验证每一个更新的安全性。

SBOM for AI（AI物料清单）：记录你的AI应用的每一个组件——模型、框架、库、数据来源、训练方法。这不是"做了就安全"，而是"出问题时知道该查哪里"。

模型签名和验证：使用数字签名验证模型的完整性和来源。确保你加载的模型确实来自你信任的来源，且未被篡改。HuggingFace在2026年已经开始支持模型签名。

依赖扫描：使用工具扫描你的AI依赖，检测已知的安全漏洞。Dependabot、Snyk、Safety等工具可以检测Python包的安全漏洞，但对AI模型的"安全扫描"目前还很有限。

沙箱加载：在沙箱中加载和运行模型，限制模型对系统资源的访问。即使模型包含恶意代码，攻击者也无法突破沙箱。

最小权限原则：AI应用应该只有完成当前任务所需的最小权限。一个AI客服Agent不需要访问数据库——即使模型被攻击，攻击者也无法窃取数据。

AI供应链安全正在成为一个新的安全赛道。2026年，出现了多个AI供应链安全创业公司：

AI供应链安全，不是"做了就安全"，而是"没做肯定不安全"。 2026年，每一个AI应用开发者都应该把供应链安全作为研发流程的一部分，而不是事后补救。