ARTICLE · 1175778
AI 供应链安全:从「装了什么」到「怎么造的」
一、引言
一个模型服务上线前做过完整评估：权重来源可查，依赖库无已知漏洞，输出符合预期。三个月后，它开始出现异常——部分原本被拦截的请求被放行。
排查结果是：代码一行没改，模型版本号也没变。变化发生在别处——上游供应商更新了小版本，RAG 知识库被写入了几篇新文档，一个新挂载的插件拿到了写权限。
这不是特例，而是 AI 供应链与传统软件供应链最本质的区别：传统软件交付后即定型，AI 应用在交付之后仍会持续变化。因此治理要回答的问题，已经从「装了什么」变成「怎么造的、从哪来、谁改过、现在靠什么在跑」。
二、按供应链环节索引：同一资产必须统一建账
AI 安全控制措施不能按部门各自为政，而应沿供应链环节逐项落实。原因在于，AI 资产的边界与组织架构并不重合：同一个数据集，既可能在训练环节作为语料入库，又可能在运行环节进入 RAG 知识库；同一组模型权重，可能同时出现在推理容器、微调适配器和第三方 API 背后。
按部门切分，同一资产要么被重复建账、要么两边都不认领，最终形成台账缺口。更关键的是，AI 供应链的风险是沿链路传导的。上游一个数据集被替换、一个依赖库爆出漏洞、一个插件被投毒，影响范围不会止于引入它的那个部门，而会扩散到所有复用该资产的下游服务。只有按环节统一建账、为每项资产确立唯一标识与唯一责任人，才能在事件发生时回答那个最要紧的问题：受影响的到底有哪些模型、哪些服务、哪些业务。
下表给出六类环节的风险对象、核心控制与应留存证据，可作为统一建账的索引框架。
供应链环节 | 主要风险对象 | 核心控制 | 应记录的证据 |
数据 | 训练语料、标注集、验证集、RAG 知识库、用户反馈 | 来源合法、授权边界、质量、隔离、权限、删除 | 合同、授权、权利保证、许可、数据卡、质量报告、抽样记录、访问日志 |
模型 | 基础模型、开源权重、微调模型、量化模型、适配器 | 供应商评估、哈希、签名、漏洞、变更、替代 | 模型卡、来源、许可、哈希、签名、训练配置、测试报告、审批记录、回滚方案 |
软件依赖 | 框架、库、训练代码、推理容器、MLOps 平台 | SBOM、漏洞扫描、版本锁定、签名、VEX | 依赖图、CPE/PURL、哈希、CVE、可达性分析、补丁记录、签名、构建日志 |
工具 / 插件 / MCP | 检索、代码执行、浏览器、支付、数据库、Agent 技能 | 注册、身份认证、最小权限、输入输出验证、审计 | 工具清单、描述哈希、地址、证书、权限、调用链、输入输出、撤销机制 |
算力 / 运行环境 | GPU/TPU、云、容器、集群、推理框架 | 资源隔离、配置、镜像、访问控制、连续性 | 供应商 SLA、区域、证书、镜像哈希、配置基线、灾备与退出预案 |
服务 / API | 模型 API、数据 API、Agent 托管、监控、第三方模型 | 协议、数据处理、可用性、安全评估、事件通知 | DPA、SLA、数据处理协议、端点清单、API 版本、限流、密钥轮换、事故响应 |
注：
· AIBOM ＝ AI 物料清单（记录 AI 系统的模型、数据、代码依赖、提示词、工具与运行时构成的清单）；
· RAG＝ 检索增强生成；
· MCP ＝ 模型上下文协议；
· SBOM ＝ 软件物料清单；
· VEX ＝ 漏洞可利用性交换；
· CPE/PURL＝ 组件标识规范；
· DPA ＝ 数据处理协议；
· SLA ＝ 服务等级协议；
· CMDB ＝ 配置管理数据库。
三、落地实践：先形成证据链，再追求标准版本完整
AIBOM 标准规范体系仍在演进，企业不必等标准完备再动手。原因在于，风险不会因为标准未定而暂停：一个未登记的数据集、一个未签名的权重、一个未受控的插件，今天就已经在生产环境里运行。
落地的优先顺序可参考：先形成可追溯的证据链，再逐步提高标准版本的完整度。
1
统一建账——覆盖六类资产的 AI 资产台账
台账应覆盖「数据—模型—软件依赖—工具/插件—算力—服务」六类资产，至少记录以下字段：
传统 SBOM 只解决软件包问题；AIBOM 至少应扩展到数据集、模型、提示词模板、检索索引、插件与 MCP。所有关键制品在生产准入前必须携带清单与哈希，未登记资产不得部署。
2
拆解「合法来源」——建立可核验的供应商准入流程
供应商准入应至少核验以下材料：
· 通用项：组织身份、授权链、数据处理说明、许可范围、维护状态、漏洞响应机制、子处理者清单、跨境安排、业务连续性与退出方案
· 数据供应商另需：来源说明、抽样核验、权利保证、删除机制
· 模型供应商另需：模型卡、许可、评估结果、限制用途、权重签名、替代方案
关键在于：来源核验不能只看对方的自我声明，应检查合同与权利链是否覆盖了实际用途。
3
实现签名验证与可信发布，而非只保存哈希文件
模型、代码、容器、SBOM 与配置，都应由受控私钥签名，验证通过后方可进入生产；部署网关可阻断无签名或签名失效的制品。企业需记录证书链、验证时间、签发者、验证结果与撤销状态。
签名体系必须与密钥保护、轮换和灾备结合——否则签名会被过期、吊销或私钥泄露所架空。
4
把训练、构建与部署过程记录为可验证的 provenance（来源溯源）
provenance 记录的是「这个制品是怎么变成现在这样的」，而不只是「它是什么版本」
· 训练 provenance 至少包括：代码提交、基础镜像、数据集版本、框架依赖、硬件环境、启动参数、输出权重摘要、验证结果
· 软件 provenance 至少包括：源码、构建平台、依赖、构建指令、制品签名
可借助 SLSA（供应链安全成熟度分级框架）分级实施。没有 provenance，企业即使保存了最终模型，也无法回答「哪个数据批次、哪段代码产生了这组权重」。
5
对插件、MCP 与 Agent 建立运行时供应链控制
每个工具必须注册、完成身份认证、采用最小权限，并对输入参数、输出数据与敏感动作进行验证。高风险动作——删除、付款、权限变更、数据外发——应配置二次确认、人工审批或临时令牌。
工具描述本身也应哈希与签名，防止假冒知名工具；对动态发现、远程加载与自动安装，应默认禁止或提高审批等级。
6
建立变更管理与可替换性，避免「一次备案、永久安全」
当数据、模型、依赖、插件、提示词、运行环境或供应商发生实质变化时，应触发影响评估、安全测试、法务核验、变更审批与回滚准备。
对处于备案或客户认证范围内的服务，应先判断是否需要更新材料或通知相关方。
同时准备替代方案：关键供应商至少有一个替代方，关键模型同时准备可切换接口，关键算力评估区域与容量替代。
7
把 AIBOM 接入漏洞、许可证与事件响应
· 新漏洞发布时：能在小时级定位受影响的模型、服务、业务与供应商
· 许可证冲突时：能识别替代组件或删除路径
· 模型投毒时：能依据签名与 provenance 快速隔离、回滚并通知受影响的下游
AIBOM 必须与 CMDB、模型注册中心、漏洞库、工单系统与应急通信打通，否则它只是一份静态文档。
四、总结
AI 供应链安全要回答的，已经不只是「装了什么」，而是「怎么造的、从哪来、谁改过、现在靠什么在跑」。标准体系仍在演进，真正决定风险水位的，是台账是否统一、来源是否可核验、制品是否可签名验证、过程是否留有 provenance、变更是否受控。这七项控制不必等待标准完备，今天就能开工；而等到事件发生时才追问「受影响的是谁」，答案往往已经无从追溯。
这七项控制里，最容易被推迟的往往是第（4）项 provenance 与第（6）项变更管理——因为它们不解决「当下有没有漏洞」，而是解决「出事时能不能说清楚」。但恰恰是这两项，决定了从「疑似」到「可验证」之间的距离。
