AI 资产清单实战：SBOM 生成与模型后门防御手册

软件供应链（Software Supply Chain）是指一个软件产品从开发到交付所依赖的所有组件的集合。在传统的软件开发中，这包括代码库、第三方库、构建工具、部署脚本等。而在 AI 系统中，供应链的范围大幅扩展——它不仅包含传统软件组件，还包括训练数据、预训练模型、微调权重、评估数据集、推理框架、提示模板等 AI 特有的资产。

AI 供应链的独特复杂性在于：一个典型的 AI 应用可能依赖数百个开源 Python 包（如 PyTorch、Transformers、NumPy）、一个数十亿参数的预训练模型（可能来自 Hugging Face 或企业内部模型库）、一个用于数据预处理的自定义脚本、以及多个外部 API（如 OpenAI API、向量数据库 API）。每个依赖项都是一个潜在的攻击入口。

2024-2026 年间，AI 供应链攻击事件呈指数级增长。2024 年的 PyTorch 供应链投毒事件（攻击者篡改了 PyPI 上的 pytorch-triton 包）、2025 年的 Hugging Face 模型后门事件（攻击者在开源模型中植入隐藏后门）、以及 2026 年初的 npm 314 包供应链攻击（Mini Shai-Hulud 攻击者再次篡改开源包），都表明AI 供应链已经成为安全防御中最薄弱的环节。

传统供应链安全的核心理念是**「信任但验证」——你可以使用第三方组件，但必须验证其来源和完整性。AI 供应链安全在此基础上增加了一个新的维度：「验证但理解」**——你不仅要验证组件没有被篡改，还要理解组件的行为是否符合预期。这是因为 AI 模型的行为是概率性的，即使模型文件没有被修改，它的输出也可能因为输入数据的微妙变化而产生意想不到的结果。

AI 供应链安全的终极目标：确保 AI 系统的每个依赖项——从代码到数据到模型——都来源可信、内容完整、行为可预期。

AI 供应链的攻击面可以分为四个层次，每一层都有独特的攻击方式和防御策略。

第一层：代码依赖攻击（Dependency Attack）——这是最传统的供应链攻击方式。攻击者篡改或冒充开源库，使其在导入时执行恶意代码。2026 年初的 npm 314 包攻击就是典型案例：攻击者篡改了 314 个 npm 包，在其中注入了窃取环境变量的代码。Python 生态同样面临威胁——2024 年的 typosquatting 攻击（攻击者发布名称与热门库相似的恶意包，如 "rquests" 冒充 "requests"）在 AI 项目中尤为常见，因为 AI 项目通常依赖大量的第三方 Python 包。

第二层：数据投毒攻击（Data Poisoning Attack）——攻击者在训练数据中注入恶意样本，使得训练后的模型表现出特定的恶意行为。与代码依赖攻击不同，数据投毒是「隐形的」——模型文件本身看起来完全正常，但在特定触发条件下会输出攻击者预期的结果。2025 年，有研究者发现 Hugging Face 上多个热门 NLP 模型的训练数据被投毒，模型在处理特定类型的输入时会输出误导性结果。

第三层：模型后门攻击（Model Backdoor Attack）——攻击者在预训练模型或微调模型中植入后门。这种攻击比数据投毒更加隐蔽，因为攻击者直接篡改了模型权重，而非训练数据。模型在正常输入下表现良好，但当输入包含特定的「触发器」（Trigger）时，模型会输出攻击者指定的结果。例如，一个图像分类模型在被投毒后，对于正常图片分类准确，但当图片的某个角落包含一个特定像素模式时，就会被分类为攻击者指定的类别。

第四层：基础设施攻击（Infrastructure Attack）——攻击者针对模型部署和推理的基础设施进行攻击。这包括：模型服务 API 的中间人攻击（Man-in-the-Middle）、推理框架的漏洞利用（如 PyTorch 的序列化漏洞）、以及向量数据库的注入攻击。2026 年，有安全研究人员演示了通过向量数据库的查询注入，可以向 RAG（检索增强生成）系统注入恶意指令，实现间接的提示注入攻击。

攻击面扩展的新趋势： 随着 AI Agent 系统的普及，供应链攻击面还在继续扩大。Agent 系统通常可以调用外部工具（如搜索引擎、代码执行引擎、数据库），攻击者可以通过伪造工具响应来欺骗 Agent 执行恶意操作。这种**「工具响应伪造攻击」**（Tool Response Spoofing）是 2026 年 AI 安全领域的新兴威胁。

软件物料清单（Software Bill of Materials，SBOM）是供应链安全的核心基础设施。SBOM 的概念来源于制造业——如果你制造一辆汽车，你需要知道每个零件的来源、供应商、规格和质检报告。软件 SBOM 做了同样的事情：列出软件产品中使用的所有组件及其依赖关系。

在 AI 系统中，SBOM 的范围需要大幅扩展。传统软件 SBOM 只包含代码依赖（如 Python 包、npm 模块），而 AI SBOM 需要额外包含：预训练模型（来源、版本、哈希值）、训练数据（来源、时间、许可协议）、微调权重、评估指标、以及部署配置（推理框架版本、硬件规格）。

目前主流的 SBOM 格式有三种：SPDX（Software Package Data Exchange）、CycloneDX、和 SWID（Software Identification Tags）。在 AI 场景中，CycloneDX 最为适用，因为它原生支持组件的层级关系，可以表达「模型→数据→代码→依赖」的多层依赖链。

生成 AI SBOM 的实操步骤：

第一步，代码依赖盘点：使用工具如 pip freeze、npm ls、或专业的 SBOM 生成工具（如 Syft、Trivy）自动扫描项目依赖。

第二步，模型资产登记：记录所有使用的预训练模型——来源（Hugging Face、企业内部）、模型 ID、版本号、文件哈希（SHA-256）、以及模型的许可证（如 Apache 2.0、MIT）。

第三步，数据来源追溯：对于训练和评估数据，记录数据来源、采集时间、数据规模、许可协议、以及任何数据清洗或预处理的步骤。

第四步，依赖链追踪：使用依赖追踪工具（如 Dependabot、Renovate）监控依赖项的更新和已知漏洞。

AI Master 的实践经验： 建立一个自动化的 SBOM 生成流程，将其集成到 CI/CD 流水线中。每次代码或模型更新时，自动生成新的 SBOM，并与之前的版本进行差异对比。这样可以在第一时间发现异常——例如，某个依赖项的版本突然变化、或某个新依赖被引入。

以下是一个实际操作示例，展示如何使用 Syft 工具为一个典型的 AI 项目生成 CycloneDX 格式的 SBOM。假设你的 AI 项目依赖以下组件：Python 包（PyTorch、Transformers、NumPy）、预训练模型（Hugging Face bert-base-uncased）、和推理框架（ONNX Runtime）。

首先，使用 Syft 扫描项目的 Python 依赖。Syft 是一个开源的 SBOM 生成工具，由 Anchore 公司开发，支持多种输出格式（SPDX、CycloneDX JSON、CycloneDX XML 等）。

安装 Syft 后，你可以使用「syft packages」命令扫描 Python 的 requirements.txt 文件，生成 CycloneDX JSON 格式的 SBOM。这个 SBOM 文件包含了所有 Python 依赖项的详细信息——包名、版本号、许可证、和依赖关系。

对于大型项目，你还可以使用「syft dir」命令扫描整个项目目录。Syft 会自动识别项目中的代码依赖、容器镜像、和系统包，生成一份完整的物料清单。

生成的 SBOM 文件可以与 Grype（也是 Anchore 开发的漏洞扫描工具）配合使用。Grype 会自动对接公共漏洞数据库（如 NVD、GitHub Advisory Database），扫描 SBOM 中的每个依赖项是否存在已知漏洞。

对于预训练模型，你需要手动添加模型信息到 SBOM 中。因为 Syft 目前不支持自动检测 Python 代码中加载的预训练模型。推荐的做法是：使用一个 JSON 文件记录所有模型资产的信息（模型 ID、来源、版本、哈希值、许可证、下载日期），然后将这个文件合并到 CycloneDX SBOM 的 components 数组中。

将模型信息添加到 SBOM 中，确保模型资产的来源、版本、和完整性都可追溯。这是 AI 供应链安全中最容易被忽视但最关键的一环。

# 安装 Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# 扫描 Python 依赖并生成 CycloneDX SBOM
syft packages python:requirements.txt --output cyclonedx-json > sbom-python.json

# 扫描整个项目目录
syft dir:./my-ai-project --output cyclonedx-json > sbom-full.json

# 安装 Grype 并扫描漏洞
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
grype sbom:sbom-full.json

{
  "name": "bert-base-uncased",
  "type": "model",
  "source": "huggingface",
  "version": "1.0.0",
  "hash": "sha256:a1b2c3d4e5f6...",
  "license": "Apache-2.0",
  "downloadUrl": "https://huggingface.co/bert-base-uncased",
  "downloadDate": "2026-05-20"
}

依赖投毒（Dependency Poisoning）是供应链攻击中最常见的形式。攻击者通过篡改开源库或发布恶意包，使得受害者在不知情的情况下引入恶意代码。以下是系统的检测与防御策略。

预防策略一：固定依赖版本（Pinning）。永远不要使用模糊的版本号（如 "requests>=2.0"），而是精确指定版本（如 "requests==2.31.0"）。这样可以避免因为依赖自动升级而引入被投毒的新版本。同时，使用锁定文件（如 requirements.txt、package-lock.json）确保团队所有成员使用完全相同的依赖版本。

预防策略二：使用私有仓库代理（Private Registry Proxy）。在企业环境中，使用私有包仓库（如 Nexus、Artifactory、Verdaccio）作为公共仓库的代理。所有依赖请求先经过私有仓库，私有仓库可以配置安全策略——例如，只允许使用经过审查的包、或自动扫描新包的恶意代码。

预防策略三：包签名验证（Package Signature Verification）。现代包管理器支持包签名验证。pip 从 22.0 版本开始支持 TUF（The Update Framework）——一个用于安全软件更新的框架。npm 也支持包签名（通过 --sign 参数）。启用签名验证后，即使攻击者篡改了包，客户端也会因为签名不匹配而拒绝安装。

检测策略一：自动化安全扫描。使用工具如 Snyk、Trivy、Dependabot 定期扫描项目依赖，检查是否存在已知的安全漏洞。这些工具会对接公共漏洞数据库（如 NVD、GitHub Advisory Database），在发现依赖项中存在已知漏洞时自动告警。

检测策略二：行为分析（Behavioral Analysis）。传统的依赖扫描只能检测已知的漏洞模式，但对于零日投毒攻击无能为力。行为分析通过监控依赖包的运行时行为来检测异常——例如，一个文本处理库在导入时突然尝试读取环境变量、或一个图像处理库在运行时尝试发送网络请求，这些都是异常行为。工具如 PyGuard 和 Socket.dev 提供了运行时行为分析功能。

检测策略三：依赖树审查（Dependency Tree Review）。定期审查项目的完整依赖树，识别不熟悉的或可疑的依赖项。很多恶意包是通过间接依赖引入的——你的直接依赖可能完全可信，但它的某个深层依赖可能已被投毒。使用 npm ls --all 或 pipdeptree 可以查看完整的依赖树。

AI 系统的供应链安全中，模型资产的安全是最独特也最具挑战性的部分。与代码不同，模型是「黑箱」——你很难通过审查模型文件来判断它是否被篡改。以下是模型供应链安全的系统性方法。

模型来源验证：在使用任何预训练模型之前，必须验证其来源。Hugging Face 是目前最大的开源模型库，但并非所有模型都经过严格审查。优先选择以下类型的模型：官方模型（由模型原始发布者上传）、经过 Hugging Face 官方审核的模型（带有 Verified 标记）、以及被广泛使用的热门模型（下载量大、社区活跃）。对于企业内部的模型，使用模型注册表（Model Registry）来管理模型的版本和来源。

模型完整性校验：使用哈希校验（SHA-256）来验证模型文件的完整性。下载模型后，计算其 SHA-256 哈希值，并与官方提供的哈希值进行对比。如果哈希值不匹配，说明模型文件在传输过程中被篡改。对于大型模型（如数十 GB 的权重文件），可以使用分片哈希（Chunked Hashing）——将模型文件分成多个块，分别计算每个块的哈希值。

模型行为验证：哈希校验只能确保模型文件没有被修改，但无法确保模型的行为符合预期。因此，需要对模型进行行为验证——使用一组标准测试用例来验证模型的输出。例如，对于一个文本分类模型，使用一组已知的输入-输出对来验证其分类准确率是否在预期范围内。如果准确率显著下降，可能说明模型被投毒或篡改。

微调权重的安全管理：微调（Fine-tuning）是 AI 项目的常见操作。微调后的权重文件需要像代码一样进行版本管理。使用 DVC（Data Version Control）或 MLflow 来管理模型权重的版本，确保每次微调都有完整的记录——包括训练数据、训练参数、评估指标、以及权重文件的哈希值。

模型后门检测：模型后门是模型供应链中最隐蔽的威胁。近年来，研究者提出了多种后门检测方法：激活聚类（Activation Clustering）——分析模型中间层的激活模式，检测异常激活；神经 Cleanse——通过逆向工程来识别潜在的触发器；STRIP（Strong Intentional Perturbation）——通过在输入中添加随机扰动来检测后门触发器。这些方法各有优缺点，建议组合使用。

数据是 AI 系统的「燃料」，也是供应链中最容易被忽视的安全环节。数据供应链安全关注的是训练数据、评估数据、和推理时使用的数据——确保这些数据的来源可信、内容完整、未被恶意篡改。

数据来源验证：对于训练数据，需要记录每个数据样本的来源——是从公开数据集下载的、从网络爬取的、还是从企业内部数据库导出的。对于公开数据集，优先使用经过社区广泛验证的数据集（如 ImageNet、GLUE、SQuAD）。对于网络爬取的数据，需要建立数据清洗和验证流程——在数据进入训练流程之前，进行内容审查、格式验证、和去重处理。

数据投毒检测：数据投毒是最隐蔽的供应链攻击之一。攻击者通过在训练数据中注入精心设计的样本，使得模型在训练后表现出特定的恶意行为。检测数据投毒的核心方法是统计分析——对训练数据进行分布分析，识别异常样本。例如，如果一个文本分类模型的训练集中，某个类别的样本突然出现了大量包含特定关键词的样本，这可能是投毒的信号。

数据许可协议审查：AI 项目使用的数据必须遵守相应的许可协议。2026 年，越来越多的数据提供商开始对 AI 训练数据的使用施加限制——例如，某些数据集只允许学术研究使用，不允许商业用途。在引入新的数据集之前，必须审查其许可协议，确保使用方式符合许可条款。违反数据许可协议不仅可能导致法律纠纷，还可能迫使企业删除已经训练的模型。

数据版本管理：训练数据需要像代码一样进行版本管理。使用 DVC（Data Version Control）或类似工具，对训练数据进行版本追踪。这样可以在发现问题时回滚到之前的数据版本，也可以确保不同实验之间使用的数据版本一致。

推理时数据安全：AI 系统在推理（Inference）阶段使用的数据也需要安全保障。特别是 RAG（检索增强生成）系统——模型会从外部知识库检索信息来生成回答。如果攻击者能够篡改知识库中的内容，就可以通过间接提示注入（Indirect Prompt Injection）来操控模型的输出。防御这种攻击的核心策略是对检索到的内容进行安全过滤——在将检索结果传递给模型之前，进行内容审查和恶意指令检测。

将上述所有策略整合为一个完整的 AI 供应链安全体系，需要组织、流程和技术三个层面的协同。

组织层面：设立专门的供应链安全团队（或指定安全负责人），负责管理整个 AI 供应链的安全策略。这个团队需要与开发团队、数据科学团队、和运维团队密切协作，确保供应链安全策略被正确执行。

流程层面：建立以下标准流程：（1）依赖引入审批流程——引入新的开源库或预训练模型需要经过安全审查；（2）定期安全审计流程——每季度对所有依赖项进行一次全面的安全审查；（3）安全事件响应流程——当发现供应链安全事件时，能够在最短时间内回滚、修复、和报告。

技术层面：部署以下技术工具：（1）SBOM 生成工具（如 Syft、CycloneDX CLI）——自动生成和维护软件物料清单；（2）依赖扫描工具（如 Snyk、Trivy）——自动扫描依赖项中的已知漏洞；（3）模型验证工具（如 MLflow Model Validation）——验证模型的行为和完整性；（4）数据版本管理工具（如 DVC）——管理训练数据的版本和来源；（5）运行时监控工具（如 OpenTelemetry）——监控 AI 系统的运行时行为，检测异常。

持续改进：供应链安全不是一次性的工作，而是持续改进的过程。建议建立以下机制：（1）安全指标看板——跟踪关键安全指标，如依赖项的漏洞数量、模型验证通过率、数据投毒检测率等；（2）安全培训——定期对团队成员进行供应链安全培训，提高安全意识；（3）红队演练（Red Team Exercise）——定期模拟供应链攻击，检验防御体系的有效性。

AI Master 的总结： AI 供应链安全的核心原则是**「可见性 + 验证 + 响应」**——首先要知道自己依赖了什么（可见性），然后验证这些依赖是否安全（验证），最后在发现安全事件时能够快速响应（响应）。这三个环节缺一不可，共同构成了 AI 供应链安全的防御闭环。

本节推荐学习 AI 供应链安全的核心资源、工具和社区，帮助你深入掌握这一领域的知识。

核心标准与框架：（1）NIST SSDF（Secure Software Development Framework）——NIST 发布的软件安全开发框架，包含 4 个实践领域和 48 个安全实践；（2）SLSA（Supply-chain Levels for Software Artifacts）——Google 提出的供应链安全等级框架，从 L1 到 L4 定义了四个安全等级；（3）CISA 供应链安全指南——美国网络安全与基础设施安全局发布的供应链安全最佳实践。

实用工具清单：（1）Syft——由 Anchore 开发的 SBOM 生成工具，支持多种格式（SPDX、CycloneDX）；（2）Trivy——由 Aqua Security 开发的安全扫描工具，支持容器、代码、和依赖项扫描；（3）Snyk——商业化的依赖安全管理平台，支持自动漏洞检测和修复建议；（4）Dependabot——GitHub 内置的依赖自动更新工具，可以自动检测漏洞并提交 Pull Request；（5）MLflow——由 Databricks 开发的 ML 生命周期管理平台，支持模型注册、版本管理、和实验追踪。

社区与研究：（1）OWASP Top 10 for LLM——OWASP 发布的针对大语言模型的十大安全风险，其中多条涉及供应链安全；（2）AI Security Initiative——一个致力于 AI 安全的行业联盟，成员包括 Microsoft、Google、IBM 等；（3）arXiv AI Security——在 arXiv 上搜索 "AI security" 或 "machine learning security"，可以找到最新的研究论文。

实战练习建议：（1）在你的 AI 项目中生成一份完整的 SBOM，并检查其中的依赖项是否有已知漏洞；（2）选择一个常用的预训练模型，验证其来源和完整性（检查哈希值、查看训练数据来源）；（3）模拟一次依赖投毒攻击——创建一个 typosquatting 包（仅在测试环境中），看看你的安全工具能否检测到它。