执行摘要

随着生成式 AI 与智能体（Agent）技术进入企业生产系统，AI 应用的“供应链”已从传统代码依赖扩展为涵盖数据、模型、代码、工具链、智能体插件及云服务的多层异构生态。开发设计阶段是这些外部依赖被首次引入的关键窗口：一旦在需求分析、架构设计、模型选型、数据准备、训练/微调或智能体编排阶段埋下不可信的“上游”，其风险将贯穿训练、部署、运行全生命周期，并因 AI 系统的非确定性、高自动化和强数据依赖而被放大。

本报告从甲方（企业用户/最终部署方）视角出发，系统梳理 AI 应用开发设计阶段被引入的六类供应链，提出基于 STRIDE、OWASP LLM05、NIST SSDF / SP 800-218A、NIST AI RMF、ISO/IEC 42001 与 EU AI Act 的评估框架，并给出可落地的组织能力、技术控制与度量指标。核心目标是为安全、算法、工程、采购及合规团队提供一套统一语言，使“供应链可信”从口号转化为可审计、可度量、可运营的治理实践。

关键建议

·将 AI 供应链评估纳入项目立项与架构评审的强制关口，形成“无清单不上线、无评估不投产”的制度。

·建立覆盖数据、模型、代码、工具链、智能体插件与基础设施的 AI-SBOM，并与 CI/CD、MLOps、SOC 打通。

·采用“AI 安全网关”作为统一技术控制面，实现 AI-SCAN、安全围栏、AI-DLP、智能体工具治理（ATG）、AI-AFW/CONT 与审计回源的协同。

·在采购合同中明确供应商安全责任、漏洞披露、模型训练数据来源、审计权与违约责任，推动供应商分级管理。

·将 STRIDE 威胁建模与 MITRE ATLAS 技术映射常态化，定期开展针对数据投毒、后门模型、依赖混淆与 MCP 工具投毒的红蓝对抗。

第 1 章 研究背景与评估必要性

1.1 从传统软件供应链到 AI 供应链的范式跃迁

传统软件供应链安全的焦点是源代码、第三方库、构建工具与分发渠道。SolarWinds（2020）、Codecov（2021）、xz-utils 后门（CVE-2024-3094，2024）等事件表明，一个被攻陷的上游组件即可在下游数万组织形成“级联式”破坏。AI 应用在继承上述风险的同时，引入了新的、更加不可见的依赖：预训练模型的权重文件、来自公开网络的训练/微调数据集、由第三方托管的模型仓库（如 Hugging Face）、基于 Model Context Protocol（MCP）的智能体工具、以及 MLaaS 提供的推理服务。

这些新型依赖具有三个共性特征：第一，它们是“数据+代码”的混合体，模型权重本身难以像源代码那样被人工审计；第二，它们具有高度的非确定性与涌现能力，同一模型在不同提示词或工具组合下可能产生迥异行为；第三，它们的更新频率极高，模型、数据集、插件与 MCP Server 的版本迭代周期以天甚至小时计，传统的发布前“一次性审查”难以跟上节奏。

因此，AI 供应链安全不是传统 SCA（Software Composition Analysis）的简单延伸，而是需要在“成分识别”之外，增加对数据来源、模型来源、工具行为与运行上下文的持续可信验证。

1.2 监管与合规驱动

全球主要监管与标准机构已将 AI 供应链安全纳入合规议程，形成了从“软件开发”到“AI 治理”的多层约束：

·NIST SP 800-218A《Secure Software Development Practices for Generative AI and Dual-Use Foundation Models》（2024 年 7 月）：在 SSDF 基础上增加了面向生成式 AI 与双用途基础模型的安全开发实践，强调数据/模型/依赖的可追溯、完整性与第三方风险管理。

·NIST AI RMF 1.0（2023 年 1 月）：提出 Govern-Map-Measure-Manage 四象限，Map 函数明确要求识别 AI 系统的上下游上下文与供应链关系。

·ISO/IEC 42001:2023：作为 AI 管理体系（AIMS）标准，要求组织在 AI 系统生命周期中对第三方、数据与模型风险进行系统性管理，并保留可追溯记录。

·EU AI Act（Regulation (EU) 2024/1689，2024 年 8 月生效）：明确 AI 系统价值链中“提供者”“部署者”“进口商”“分销商”的义务，高风险 AI 需进行合格评定，通用 AI 模型需披露训练数据摘要，全链条责任可追溯。

·CISA + G7《Software Bill of Materials for AI – Minimum Elements》（2026 年 5 月）：将传统 SBOM 扩展至 AI 系统，建议对模型、数据、依赖与训练/推理环境进行透明度披露。

·OWASP GenAI LLM Top 10 2026：将“Supply Chain Vulnerabilities”列为关键风险类别，涵盖被入侵的组件、服务与数据集对系统完整性的破坏。

1.3 真实威胁：供应链攻击向 AI 领域迁移

近两年，针对 AI 供应链的攻击案例快速增长。PyTorch 生态在 2022 年底至 2023 年初遭遇 “torchtriton” 依赖混淆攻击，攻击者在 PyPI 发布同名恶意包，窃取开发者 SSH 密钥、主机名与环境变量；2024 年 3 月，xz-utils（liblzma）被植入针对 sshd 的后门（CVE-2024-3094），攻击者通过长达数年的社会工程获取提交权限，凸显了开源维护者信任链的脆弱；2024 至 2025 年，安全研究人员在 Hugging Face 等模型托管平台发现百余个使用不安全 Pickle 反序列化的恶意模型，可在加载时执行任意代码。

这些事件共同说明：AI 供应链攻击不再停留在理论层面，而是已经成为可被利用、可规模化、可造成级联影响的现实威胁。对于甲方而言，攻击面既可能来自上游开源社区，也可能来自商业供应商、外包标注团队、云服务商以及日益增多的智能体插件市场。

1.4 为什么聚焦开发设计阶段

软件开发的研究反复证明：缺陷越早引入，后期修复成本越高。对于 AI 系统，这一规律被进一步放大。开发设计阶段决定了以下关键要素：

·模型选型：是否使用开源基座模型、闭源 API、微调模型或 LoRA 适配器，直接关系到后续的可审计性与可控性。

·数据来源：训练/微调/评测数据来自何处、如何标注、是否包含敏感信息，将在源头决定隐私、偏见与投毒风险。

·依赖锁定：框架、库、工具版本与包名在 requirements.txt、package.json 或 Dockerfile 中被固定，一旦被污染，将在所有环境中复现。

·智能体能力边界：Agent 可调用的 MCP Server、插件与外部 API 列表在架构阶段即被设计，权限过大或来源不明将造成“过度代理”（Excessive Agency）与越权。

·安全控制架构：是否在网关层、模型层、数据层、应用层设置安全围栏、DLP、审计与 SIEM 联动，需要在设计阶段统一规划。

1.5 甲方视角的治理空白

从甲方视角看，当前 AI 供应链治理存在四类典型空白：一是“资产不清”，多数企业尚未建立模型、数据集、Agent、MCP Server 与外部 API 的统一台账；二是“责任不明”，采购合同往往沿用传统软件许可条款，未覆盖模型训练数据来源、漏洞披露、后门责任与安全审计权；三是“工具不足”，传统 SCA 与漏洞扫描工具难以识别 Pickle 模型、数据血缘与提示词供应链风险；四是“运营不闭环”，安全事件无法在训练、构建、运行阶段形成统一审计与回源。本报告后续章节将围绕如何填补这些空白展开。

第 2 章 AI 供应链的定义、范畴与分类

2.1 传统软件供应链与 AI 供应链的差异

传统软件供应链可概括为“源代码 → 第三方库 → 构建工具 → 分发渠道 → 运行环境”。其安全控制重点在于代码完整性、依赖漏洞、构建可信与更新机制。AI 供应链在此基础上增加了以下异构要素：

上表仅列出最显著的差异。需要强调的是，AI 供应链并不是替代传统供应链，而是在其上叠加了一层“模型与数据”的依赖，二者必须统一治理。

2.2 六类开发设计阶段供应链

本章将 AI 应用在开发设计阶段引入的供应链划分为六类。该分类遵循“能被甲方识别、能被安全团队评估、能被技术工具检测”的实操原则，避免过度学术化。

S1 数据供应链

覆盖训练数据、微调数据、评测数据、提示词模板与数据标注服务。来源包括公开数据集、网络爬取、商业采购、众包标注、合成数据及企业自有数据。关键风险是数据投毒（Poisoning）、版权/隐私违规、标注偏差与来源不可追溯。

S2 模型供应链

覆盖基座模型、预训练权重、微调模型、LoRA/适配器、Tokenizer、配置与模型压缩产物。来源包括开源模型仓库、商业模型 API、合作伙伴模型及内部训练。关键风险是后门模型、权重窃取、许可证违规、版本漂移与模型来源伪造。

S3 代码与依赖供应链

覆盖 AI 应用所依赖的第三方库、框架（PyTorch、TensorFlow、LangChain、LlamaIndex 等）、MCP/Agent SDK、运行时、编译器及包管理器。关键风险是依赖混淆、typosquatting、已知 CVE、恶意包、被篡改的源码与“幽灵依赖”。

S4 工具链供应链

覆盖训练/推理平台、MLOps 工具、CI/CD 流水线、Notebook 环境、容器基础镜像、注册表与构建农场。关键风险是构建环境被污染、镜像包含恶意层、CI/CD 凭证泄露与供应链级横向移动。

S5 智能体与工具治理供应链

覆盖 MCP Server、Agent 插件、Skills、外部 API、函数调用声明与工具市场。这是 AI 2.0/Agentic AI 阶段新增的关键供应链。关键风险是工具投毒、能力边界失控、越权调用、MCP Server 仿冒与“Confused Deputy”问题。

S6 服务与基础设施供应链

覆盖 MLaaS、公有云/私有云算力、GPU 集群、数据标注外包、第三方模型评测与托管服务。关键风险是供应商锁定、侧信道泄露、训练数据被服务方访问、合规主权及 SLA 安全项缺失。

2.3 供应链全景视图

下图将六类供应链围绕“AI 应用/智能体”进行可视化，强调它们在开发设计阶段同时被引入并形成统一的外部信任边界。任何一类的失守都可能通过模型、数据或 Agent 行为向下游传导。

图 2-1：AI 应用开发设计阶段供应链全景视图

第 3 章 威胁建模与风险深度剖析

3.1 基于 STRIDE 的 AI 供应链威胁建模

STRIDE 是微软提出的经典威胁分类框架，将威胁划分为欺骗（Spoofing）、篡改（Tampering）、否认（Repudiation）、信息泄露（Information Disclosure）、拒绝服务（Denial of Service）和提权（Elevation of Privilege）六类。将其应用于 AI 供应链，可以帮助团队系统性地识别每一类上游依赖可能引入的风险。

与传统应用不同，AI 供应链中的“篡改”不仅指二进制被修改，还包括训练数据分布被污染、模型权重被植入后门、工具描述（Tool Description）被注入诱导性指令；“欺骗”不仅指身份伪造，还包括模型仓库中的仿冒模型、Typosquatting 包与虚假的数据集来源声明；“提权”则体现在 Agent 通过被投毒的 MCP Server 获取越权能力。

图 3-1：基于 STRIDE 的 AI 供应链威胁建模映射

3.2 关键攻击向量详解

数据投毒（Data Poisoning）

攻击者在训练/微调数据集中注入带有触发器的样本，使模型在特定输入下产生预期错误输出。针对大语言模型，投毒可表现为在预训练语料中注入偏见、后门指令或特定知识；针对 CV 模型，可表现为标签翻转或后门图案。危害包括输出不可信、价值观偏移、对抗样本易感性提升。

后门模型与恶意权重（Backdoored Models）

攻击者上传带有后门的预训练模型到公开仓库，或在模型微调服务中植入后门。正常输入下模型表现正常，一旦触发特定 token、图像模式或提示词前缀，即输出有害结果或泄露训练数据。2024 至 2025 年，Hugging Face 上已发现多起利用不安全 Pickle 反序列化执行任意代码的恶意模型事件。

依赖混淆与 Typosquatting

攻击者在公共包仓库注册与内部包或热门包名称相似的包名（如 torchtriton、colourama 等），诱导构建系统拉取恶意包。AI 生态因其包依赖复杂、版本迭代快，成为 typosquatting 的高价值目标。

MCP 工具投毒与能力边界失控

在 MCP/Agent 架构中，LLM 根据工具描述（Tool Description）决定调用哪个工具。攻击者通过篡改 MCP Server 的描述、返回内容或能力声明，诱导 Agent 执行越权操作（如读取敏感数据库、调用付费 API、横向移动）。此类攻击属于新兴的“智能体供应链”风险，也是本报告重点关注方向。

MLaaS 与第三方服务滥用

企业将训练数据或提示词提交给第三方 MLaaS 时，可能面临数据被留存、模型被“记忆”后通过其他客户侧信道恢复、服务方被入侵导致模型被替换等风险。此外，恶意 MLaaS 提供方可植入后门或利用模型作为“前端层”（Presentation Layer）绕过访问控制。

CI/CD 与容器镜像污染

AI 训练与部署高度依赖 CI/CD 与容器化。一旦构建脚本、Dockerfile、基础镜像或 MLOps 工作流被攻陷，恶意代码可被注入到每一次模型训练、微调或推理发布中，形成“每次构建都带毒”的持续性风险。

模型窃取与知识提取

通过大量查询 API 提取模型行为，攻击者可以蒸馏出近似模型，进而发现训练数据中的敏感信息或绕过原模型的安全限制。虽然模型窃取本身不直接破坏供应链，但它削弱了甲方对模型资产的掌控，并可能暴露训练数据中的隐私。

3.3 风险暴露矩阵

下图以“供应链类型 × 威胁类型”的矩阵形式，给出各类供应链在不同攻击向量下的暴露强度示例评级。该评级并非绝对值，甲方应结合自身业务场景、数据敏感性、面客/内部属性进行重新校准。

图 3-2：AI 供应链风险暴露矩阵（示例评级）

3.4 与 OWASP LLM05 及 MITRE ATLAS 的映射

OWASP GenAI LLM Top 10 将“Supply Chain Vulnerabilities”列为关键风险，指出“依赖被攻陷的组件、服务或数据集将破坏系统完整性，导致数据泄露与系统故障”。MITRE ATLAS 则将相关技术映射到“ML Supply Chain Compromise”“Acquire Public ML Model”“ML Model Inference API Access”等技术点。

第 4 章 评估框架与方法论

4.1 评估原则

·Security First：在 AI 项目立项阶段即将供应链安全作为非功能性需求（NFR）纳入架构评审。

·Zero Trust：对任何外部数据、模型、包、工具、服务与 MCP Server 默认不信任，持续验证其来源、完整性与行为。

·Privacy by Design：在数据供应链设计阶段即识别个人信息、商业秘密与跨境合规要求，避免事后补救。

·Defense in Depth：在数据层、模型层、代码层、网关层、运行层与审计层设置多重控制，避免单点失效。

·Vendor Neutral & Evidence-Based：评估框架与厂商无关，所有控制建议均基于公开标准与可验证事件。

·Measurable：将成熟度、风险暴露、响应时效等指标化，支撑管理层决策与持续改进。

4.2 六维评估模型

本报告提出面向 AI 供应链的六维评估模型：透明性/可追溯、完整性/防篡改、来源可信、依赖漏洞管控、合规与隐私、可观测响应。六个维度相互关联：透明性是基础，完整性是核心，来源可信与漏洞管控是抓手，合规与隐私是底线，可观测响应是闭环保障。

图 4-1：AI 供应链六维评估模型——现状与目标对比

4.3 成熟度分级模型

参考 CMMI、NIST CSF 与 SSDF 的分级思想，本报告将 AI 供应链安全成熟度划分为 L0–L4 五级。甲方在进行评估时，应首先测定当前成熟度，再设定 1–3 年目标水位，并制定维度级改进计划。

图 4-2：AI 供应链安全成熟度分级（L0–L4）

4.4 评估流程

AI 供应链评估不是一次性的合规检查，而是贯穿 AI 系统生命周期的持续活动。下图给出五阶段闭环流程：准备与立项、供应链识别与测绘、风险评估与分析、处置与整改、持续监测与左移。

图 4-3：AI 供应链评估落地流程（闭环）

4.5 标准与框架映射

下表将本报告的评估维度与关键控制点映射到主流 AI 安全与软件供应链标准，便于甲方在合规审计中直接使用。

4.6 评估指标与打分方法

建议甲方采用“维度评分 + 风险加权”的双层方法。每个维度按 1–5 分打分，结合该维度对业务的影响权重计算加权总分。同时，对每一项高危及以上的供应链依赖，单独建立风险档案（Risk Register），记录来源、版本、SHA256、CVE、责任人与处置状态。

·维度分 = Σ（控制点得分）/ 控制点数量，1–5 分。

·综合成熟度分 = Σ（维度分 × 维度权重），便于横向比较不同 AI 项目。

·风险档案必须包含：依赖名称、版本、引入阶段、责任人、验证方式、已知风险、处置动作、复核日期。

第 5 章 评估落地方案

5.1 组织与治理

AI 供应链评估的落地首先需要组织保障。建议甲方建立“AI 安全治理委员会”或将其纳入现有的网络安全与数据治理架构中，并明确以下角色：

5.2 评估工具链

有效的评估落地需要工具支撑。下表列出关键工具类别及其在 AI 供应链治理中的定位。需要强调的是，甲方应优先选择能够与现有 DevSecOps、MLOps、SIEM 集成的工具，避免形成新的孤岛。

5.3 分阶段实施路线

建议甲方按照“先 visibility、再 control、后 intelligence”的节奏推进，通常可分为 12–18 个月的三阶段路线图：

第一阶段：可见与基线（0–6 个月）

·建立 AI 资产台账：盘点所有在研/在运 AI 项目、使用的模型、数据集、外部 API、MCP Server 与插件。

·引入 AI-SBOM：为每个项目生成最小可行 AI-SBOM，至少包含模型名称/版本/来源、关键依赖、数据来源、训练/推理环境。

·制定供应链安全策略：明确禁止/限制引入的依赖类型、供应商准入要求、数据使用规范。

·采购合同修订：在新签/续签 AI 相关合同时加入数据来源、漏洞披露、审计权与违约责任条款。

第二阶段：控制与集成（6–12 个月）

·在 CI/CD 与 MLOps 流水线中集成 SCA、模型扫描、镜像扫描与签名验证，实现构建时阻断。

·部署 AI 安全网关，覆盖 AI-SCAN、安全围栏、AI-DLP、AI-AFW/CONT 与审计回源。

·对高风险 AI 项目实施 STRIDE 威胁建模与红蓝对抗，重点演练数据投毒、后门模型与 MCP 工具投毒。

·建立供应商分级管理机制，对关键供应商开展现场或远程安全审计。

第三阶段：智能与优化（12–18 个月）

·引入威胁情报与自动化，实现对新发布 CVE、恶意模型、恶意包、异常 MCP Server 的自动告警与处置。

·将 AI 供应链指标纳入企业级安全 KPI，定期向管理层报告成熟度与风险趋势。

·推动行业协作，参与或主导 AI-SBOM、模型签名、MCP 安全等标准的落地实践。

·形成持续改进闭环：每次安全事件与审计结果回流至策略与基线更新。

5.4 评估检查清单

下表按六类供应链给出甲方在评估时应重点核查的条目。该清单可用于项目自查、供应商审计与第三方评估。

5.5 持续监测与左移

供应链安全的本质是持续信任验证。甲方应在以下三个层面实现“左移”与“右移”结合：一是构建时，在代码提交、依赖安装、模型下载、镜像构建阶段实施自动校验与阻断；二是运行时，通过 AI 安全网关监测模型行为、数据访问、Agent 工具调用与异常输出；三是事件响应时，将所有相关日志回传 SIEM，实现从告警到根因的快速溯源。

第 6 章 甲方建设要点

6.1 顶层治理与制度

甲方应将 AI 供应链安全纳入整体网络安全治理框架，而非作为独立项目运作。关键制度包括：《AI 系统供应链安全管理规范》《外部模型/数据引入审批办法》《AI 供应商安全评估指南》《AI 安全事件应急响应预案》。制度应明确：谁有权引入外部依赖、引入前需完成哪些评估、上线后如何监测、发生事件如何定责与处置。

6.2 供应商与采购管控

采购合同是甲方对供应商施加安全要求的最直接杠杆。建议在 AI 相关合同中至少包含以下条款：

·数据来源声明条款：供应商须声明训练/微调数据不包含未授权个人信息、受版权保护内容或已知投毒数据，并承担相应违约责任。

·漏洞披露与响应条款：供应商应在约定期限内披露影响甲方的高危漏洞，并提供修复方案或缓解措施。

·模型完整性条款：交付的模型应附带哈希/签名与模型卡片，甲方可独立验证来源与完整性。

·审计权条款：甲方有权对供应商的供应链安全控制进行审计或要求其提供第三方审计报告。

·退出与数据删除条款：合作终止后，供应商应在约定期限内删除甲方数据，并提供删除证明。

6.3 技术控制面：AI 安全网关 A–F 能力域

为将供应链可信要求转化为可运营的技术能力，建议甲方构建以“AI 安全网关”为核心的统一控制面。该控制面并非特定厂商产品，而是一组厂商中立的安全能力域参考架构，可由甲方自研、采购或组合实现。

图 6-1：甲方 AI 供应链技术控制面（AI 安全网关 A–F 能力域）

控制面将运行时发现的问题与构建时资产台账打通：当运行时检测到某 MCP Server 行为异常，可快速定位其引入项目、审批人、版本与依赖关系，实现“审计回源”。

6.4 数据供应链建设要点

·建立数据分级分类制度，明确哪些数据可用于训练、微调与评测，哪些数据禁止出境或共享。

·对公开数据集与网络爬取数据进行来源登记、质量检测与投毒扫描，避免“黑盒数据”直接进入训练。

·与标注服务商签署 DPA，实施标注人员背景审查与输出抽检，防止标注偏差与恶意注入。

·对合成数据保持警惕：合成数据可能放大源模型的偏见或被用于隐式投毒。

6.5 模型供应链建设要点

·建立“模型仓库白名单”机制，限制仅从经过审计的模型源（如内部 Artifactory、可信公开仓库镜像）下载。

·对下载的模型进行哈希/签名校验、Pickle 反序列化检测、后门扫描与许可证合规检查。

·对 LoRA/适配器实施与基座模型同等的审查，避免“小文件、大风险”。

·建立模型版本与回滚策略，确保在发现模型异常时可快速切换至可信版本。

6.6 代码、依赖与工具链建设要点

·使用私有 PyPI/npm/Container Registry 镜像，并开启包名保护，防止 typosquatting 与依赖混淆。

·对 requirements.txt、package.json、Dockerfile 实施锁定（lockfile）与哈希校验，构建时拒绝浮动版本。

·将 SCA、容器镜像扫描、密钥扫描集成到 CI/CD，阻断含高危 CVE 或泄露凭据的构建。

·对训练/推理环境实施基础设施即代码（IaC）与不可变构建，确保环境可复现、可审计。

6.7 智能体（D 域 ATG）建设要点

智能体与工具治理（Agent & Tool Governance, ATG）是 AI 供应链的新前沿。随着 MCP 等协议普及，Agent 的能力边界不再由代码静态决定，而由外部工具市场的动态组合决定。甲方必须将 MCP Server、插件与 Skills 作为关键供应链进行治理。

·MCP 管控：建立 MCP Server 准入清单，要求所有 Server 经过安全评审、具备身份鉴权与最小权限，禁止未经审批的 Server 接入生产环境。

·Skills 生命周期：对 Skills 实行注册、审批、版本、退役全生命周期管理，记录每个 Skill 的开发者、能力声明、调用范围与变更历史。

·工具投毒防护：校验工具描述（Tool Description）与示例，防止攻击者通过描述注入诱导 Agent 执行非预期操作；对工具返回结果进行输入/输出校验。

·能力边界：为每个 Agent 定义明确的动作沙箱与权限集合，禁止跨系统越权调用；对高敏感操作实施人机确认（Human-in-the-Loop）。

6.8 度量指标与 KPI

甲方应建立可量化的 KPI，将供应链安全从“活动”转化为“绩效”。建议指标包括：

第 7 章 案例与实证分析

本章选取五个具有代表性的供应链安全事件进行复盘。它们并非全部发生在纯 AI 场景中，但其攻击机理、影响路径与治理启示对 AI 供应链评估具有直接参考价值。

7.1 事件映射到供应链环节

将上述事件映射到第 2 章的六类供应链，可以发现：工具链与代码依赖是当前最成熟的攻击入口，而模型供应链与智能体工具治理正在成为新的高危入口。甲方在资源有限时，应优先保障“高影响、高可控”的环节：代码依赖、工具链与模型来源；同时密切跟踪 Agent/MCP 生态的发展，提前布局。

7.2 对甲方的启示

·供应链攻击的成功往往依赖于“信任滥用”：攻击者冒充维护者、包名或模型来源。因此，身份验证与来源验证是防御的第一性原则。

·单一控制措施无法抵御高级供应链攻击，必须组合使用 SBOM、签名、扫描、网络分段、最小权限与审计回源。

·开源与商业供应商都需要审计，且审计权应写入合同，不能停留在口头承诺。

·事件响应必须预设“上游被攻陷”场景，具备快速隔离、回滚与溯源能力。

第 8 章 总结与展望

8.1 关键结论

·AI 供应链已从“代码+库”扩展为“数据+模型+代码+工具链+智能体插件+服务”的复杂生态，传统 SCA/SBOM 需要升级为 AI-SBOM。

·开发设计阶段是控制风险的关键窗口，左移治理的成本远低于运行时补救。

·STRIDE、OWASP LLM05、NIST SP 800-218A、ISO/IEC 42001 与 EU AI Act 为甲方提供了成熟的评估语言与合规映射。

·甲方建设应围绕“看得见、管得住、可追溯、能响应”四个目标展开，形成组织、制度、技术与运营四位一体的治理体系。

·AI 安全网关可作为统一技术控制面，将供应链可信要求从构建时延伸至运行时，并实现与 SIEM/SOC 的联动。

8.2 建设路线图建议

对于刚刚开始建设的甲方，建议按照“资产台账 → AI-SBOM → 供应商治理 → CI/CD 集成 → AI 安全网关 → 持续监测”的顺序推进；对于已有 DevSecOps 基础的甲方，可在 3–6 个月内完成代码与模型供应链的基线建设，并在 12 个月内覆盖 Agent/MCP 等新兴场景。

8.3 趋势展望

·AI 生成供应链攻击：攻击者将利用生成式 AI 自动生成 typosquatting 包、虚假模型卡片与诱导性工具描述，降低攻击成本。

·AI-SBOM 标准化加速：CISA、G7 与 OWASP AIBOM 等倡议将推动 AI-SBOM 从建议走向强制，甲方应提前储备生成与治理能力。

·MCP 与 Agent 市场成为新战场：随着 MCP Server 与 Skills 市场爆发，工具投毒、能力边界与供应链滥用将成为攻防焦点。

·监管落地与跨境合规：EU AI Act 等法规将进入执法期，供应链透明度、数据治理与审计保存将成为合规审计重点。

·红蓝对抗常态化：针对 AI 供应链的专项红队（数据投毒、后门模型、MCP 工具投毒）将成为头部甲方安全运营的标配。

附录 A：评估检查清单速查表

附录 B：标准与框架对照索引

附录 C：参考文献

1.OWASP Foundation. OWASP Top 10 for Large Language Model Applications / OWASP GenAI LLM Top 10 2026. https://genai.owasp.org/

2.NIST. SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models. July 2024. https://csrc.nist.gov/pubs/sp/800/218/a/final

3.NIST. AI Risk Management Framework (AI RMF 1.0). January 2023. https://www.nist.gov/itl/ai-risk-management-framework

4.NIST. Secure Software Development Framework (SSDF) Version 1.1. SP 800-218. https://csrc.nist.gov/Projects/ssdf

5.ISO/IEC. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system.

6.European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act).

7.CISA. Software Bill of Materials for AI – Minimum Elements. May 2026. https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements

8.MITRE. ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems). https://atlas.mitre.org/

9.Microsoft Learn. Threat Modeling AI/ML Systems and Dependencies. https://learn.microsoft.com/en-us/security/engineering/threat-modeling-aiml

10.CISA. Alert AA24-087A: Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library (CVE-2024-3094). https://www.cisa.gov/news-events/alerts/2024/03/29/...

11.PyTorch. Compromised PyTorch-nightly dependency chain between December 2022 and December 30, 2022. https://pytorch.org/blog/compromised-nightly-dependency/

12.The Hacker News. Malicious ML Models Found on Hugging Face Leverage Broken Pickle. February 2025. https://thehackernews.com/2025/02/malicious-ml-models-found-on-hugging.html

13.OpenSSF. SLSA (Supply-chain Levels for Software Artifacts). https://slsa.dev/