AI供应链安全（4）：把要求落到证据——AI供应链合规落地思考

锦岳智慧

2026年10月19日 18:00
北京

去阅读

前三篇回答了三个问题：第一篇把智能体“看见”，回答“有多少个智能体在跑”；第二篇用 AIBOM 说清构成，回答“每个智能体由什么组成”；第三篇把风险测准，回答“智能体是否安全、能否上线”。

但对准备落地的组织来说，还有一道更现实的坎：从哪里开始。如果一上来就要求对齐一套完整框架，最常见的结局是半年过去，AIBOM 清单仍然没有落地。本篇换一个更务实的顺序：先形成证据链，再追求标准版本完整。理由很直接——合规问询、监管检查、事故复盘时，对方要的不是“我们做了多少工作”，而是“这件事能不能拿出证据”。而证据类工作有一个共同特点：事后补不回来。

1为什么先要“最小集”：先有证据链，再谈完整标准

AIBOM最小集不是降低标准，而是排定顺序：在标准、能力、资源都还不完备的阶段，哪些事情必须先做对。判断依据可以收敛成一条——凡是事后补不回来的，先做。哈希、签名、来源、带时间戳的核验记录都属此类：事发之后再补一份哈希，只能说明“现在这份没被改”，说明不了“当时那份是不是原版”。相反，标准版本的完整度、字段的丰富度可以逐步补齐，晚一步不影响其有效性。

三个现实约束决定了这个顺序：

▪ 标准仍在演进。AIBOM 格式与字段尚未统一，算力、平台、服务等资产当前只能以登记与溯源方式纳入。等标准定稿再动手，等于把台账建立无限期推迟。

▪ 扫描能力有边界。并非每个环节都能自动解析出结构化要素，有些环节只能登记。

▪ 资源有限。 七个最小控制同时铺开，通常一条也做不透。

最小集与完整框架不是二选一，而是后者的前置条件：先把证据链打通，之后每补齐一块标准、每接入一类扫描能力，都能直接落到已有的证据结构上，而不是推倒重来。

图 1　最小集的判断依据：凡是事后补不回来的，先做

2最小控制一：按供应链环节建立统一台账

第一个最小控制，是建立覆盖“数据—模型—代码—工具—服务—算力”的统一 AI 资产台账，至少记录名称、版本、用途、责任人、供应商、部署位置、许可证、数据流向、访问权限、哈希、签名状态、漏洞、生命周期与退出方案。

图 2　统一 AI 资产台账：同一资产统一建账，环节只是索引维度

为什么强调“按环节”而非“按系统”建账？因为同一资产会同时出现在多个环节：开源权重既是“模型”环节的对象，也可能作为第三方模型服务构成“服务”环节的基础；知识库既是“数据”，也可能通过检索接口对外提供“服务”。按业务系统或部门建账，同一资产会被登记多次，口径不一致时无从判断哪份为准。所以原则是：同一资产必须统一建账，环节只是索引维度，不是分割依据。

表 1　六类供应链环节的主要风险对象、核心控制与应记录的证据

01数据

主要风险对象

训练语料、标注集、验证集、RAG 知识库、用户反馈

核心控制

来源合法、授权边界、质量、隔离、权限、删除

应记录的证据

合同、授权、权利保证、许可、数据卡、质量报告、抽样、访问日志

02模型

主要风险对象

基础模型、开源权重、微调模型、量化模型、适配器

核心控制

供应商评估、哈希、签名、漏洞、变更、替代

应记录的证据

模型卡、来源、许可、哈希、签名、训练配置、测试、审批、回滚方案

03软件依赖

主要风险对象

框架、库、训练代码、推理容器、MLOps

核心控制

SBOM、漏洞扫描、版本锁定、签名、VEX

应记录的证据

依赖图、CPE/PURL、哈希、CVE、可达性、补丁、签名、构建日志

04工具/插件/MCP

主要风险对象

检索、代码执行、浏览器、支付、数据库、Agent 技能

核心控制

注册、身份认证、最小权限、输入输出验证、审计

应记录的证据

工具清单、描述哈希、地址、证书、权限、调用链、输入输出、撤销机制

05算力/运行环境

主要风险对象

GPU/TPU、云、容器、集群、推理框架

核心控制

资源隔离、配置、镜像、访问控制、连续性

应记录的证据

供应商 SLA、区域、证书、镜像哈希、配置基线、灾备和退出预案

06服务/API

主要风险对象

模型 API、数据 API、Agent 托管、监控、第三方模型

核心控制

协议、数据处理、可用性、安全评估、事件通知

应记录的证据

DPA、SLA、数据处理协议、端点清单、API 版本、限流、密钥轮换、事故响应

3最小控制二：把“合法来源”拆成可核验的准入流程

清单不做来源核验，就只是一份“自述材料”——组件说自己来自哪里，清单就记哪里，攻击者改一处声明即可绕过。要让核验可执行，必须把“合法来源”这个模糊要求拆成可逐条核实的准入流程。

供应商准入至少核验：组织身份、授权链、数据处理说明、许可范围、维护状态、漏洞响应、子处理者、跨境安排、业务连续性与退出方案；数据供应商还需追加来源说明、抽样核验、权利保证与删除机制，模型供应商需追加模型卡、许可、评估结果、限制用途、权重签名与替代方案。

这里有一条最易被忽略的判断：来源核验不能只看声明，应检查合同与权利链是否覆盖实际用途。一个模型许可允许研究使用，不代表允许商用；一个数据集授权了训练，不代表授权了对外提供检索服务。声明与实际用途之间的缺口是最常见的合规风险来源，且无法靠技术手段自动发现——只能逐条比对。

4最小控制三：签名验证与可信发布，而不只是保存哈希

不少企业把哈希值存进一个文件，认为这就是完整性保护。哈希能证明“这份制品没被改”，但证明不了“它是谁发布的”——后者才是供应链攻击真正要伪造的东西。

正确做法是：模型、代码、容器、SBOM 与配置均由受控私钥签名，验证通过后方可进入生产；部署网关阻断无签名或签名失效的制品。签名把“完整性”与“身份”一并解决，这是单纯保存哈希做不到的。验证过程也要留痕：证书链、验证时间、签发者、验证结果与撤销状态——缺任何一项，事后都无法复现当时的验证结论，也就无法回答“它当时为什么被放行”。

还有一条必须同时建立：签名体系须与密钥保护、轮换和灾备结合，否则签名会被过期、吊销或私钥泄露架空。签名失效最常见的情形不是算法被破解，而是密钥管理没跟上。一旦签名可被绕过，“验证通过”就退化成另一种形式的自述材料。

5最小控制四：把训练、构建、部署记录为可验证 provenance

签名回答“是不是他发的”，provenance 回答“它是怎么来的”。两者叠加，制品才有完整的来源链。

训练 provenance 至少包括：代码提交、基础镜像、数据集版本、框架依赖、硬件环境、启动参数、输出权重摘要与验证结果。软件 provenance 至少包括：源码、构建平台、依赖、构建指令与制品签名。SLSA 可用于分级实施，不必一步到位。

没有 provenance 时，企业即使保存了最终模型，也无法回答“哪个数据批次、哪段代码产生了这个权重”。这个问题在模型被通报存在后门、或某个数据集被要求删除的那一刻，会立刻变成必须回答的问题——而那时已无法回溯。这也解释了第二篇“冻结基线”为什么能作为审计证据：基线里记的不只是构成，还有构成是怎么产生的。只有构成没有 provenance 的清单，能说清“里面有什么”，说不清“这些东西是怎么进来的”。

图 3　三类证据回答三个不同的问题

6最小控制五：对插件、MCP 与 Agent 建立运行时供应链控制

前几个控制都作用在“进入生产之前”。但智能体供应链中最易出问题的部分——插件、MCP Server 与 Agent 技能——恰恰在运行时才接入，这正是第一篇讲的第三个失效点：运行时挂载，构成在构建时不可知。

基本要求是：每个工具必须注册、身份认证、采用最小权限，并对输入参数、输出数据与敏感动作执行验证。对高风险动作——删除、付款、权限变更、外发数据——应配置二次确认、人工审批或临时令牌。判断标准不是“这个动作危不危险”，而是它是否不可逆、是否出域、是否涉及资金或权限：三个条件占一个，就应升级管控。

有一条常被漏掉：工具描述本身也应哈希和签名，防止假冒知名工具。攻击者不必替换工具的实现，只要让恶意工具的“名字和描述”像某个知名工具，就可能被模型选中——模型看到的是描述，不是代码。第二篇讲过仿冒来源与抢注包的识别，工具描述的签名正是同一原则在工具层的落地。

对动态发现、远程加载与自动安装，应默认禁止或提高审批等级——默认允许，等于把准入审批这道关口开在流程最窄的一环上。

图 4　进入生产之前与运行时接入的分工

7最小控制六：变更管理与可替换性

第一篇讲过运行期变更的隐蔽性：改提示词、向知识库传文档、运行时挂载新工具、上游供应商静默更新，都不经过发布系统。合规视角下，这对应一个具体风险——“一次备案、永久安全”是假象，备案时的构成与半年后的构成可能已完全不同。因此，数据、模型、依赖、插件、提示词、运行环境与供应商发生实质变化时，应触发影响评估、安全测试、法务核验、变更审批与回滚准备；对处于备案或客户认证范围内的服务，还应先判断是否需要更新材料或通知相关方——这一步最容易被漏掉，而它往往正是合规责任的触发点。

可替换性与变更管理是一体两面。关键供应商至少应有替代方案，关键模型应同时准备可切换接口，关键算力应评估区域与容量替代。没有替代方案，“发现问题”就等于“业务中断”；有了替代方案，风险处置才有执行空间——这也是第二篇把“可替代性标记”列为服务类资产记录内容的原因。

8最小控制七：把清单接入漏洞、许可证与事件响应

第七个最小控制，是把 AIBOM 接入漏洞、许可证与事件响应流程。

三种典型触发情形：

▪ 新漏洞发布时，能在小时级定位受影响的模型、服务、业务与供应商。不是逐个查应用有没有用到某组件，而是按组件反查受影响的智能体。

▪ 许可证冲突时，能识别替代组件或删除路径，而不是等到法务问询才开始翻清单。

▪ 模型投毒时，能依据签名与 provenance 快速隔离、回滚并通知受影响下游。

一条硬要求：AIBOM 必须与 CMDB、模型注册中心、漏洞库、工单和应急通信连接，否则只是一份静态文档。清单建了、漏洞库也接了，但工单仍靠人工派发、通知仍靠群里喊，那么“小时级定位”就只是口号。

9七个最小控制的落地顺序

七个控制不必同时铺开。按“能不能回答、能不能验证、能不能响应”分为三个阶段推进，每一步都能独立产生价值。

表 2　三个阶段的建设内容与完成标志

01阶段一：能回答

建设内容

最小控制一　统一 AI 资产台账；最小控制二　来源核验与供应商准入

完成标志（可验收）

能给出任一资产的构成、来源与责任人；未登记资产无法进入部署流程

02阶段二：能验证

建设内容

最小控制三　签名验证与可信发布；最小控制四　训练与构建 provenance

完成标志（可验收）

生产环境制品均可通过签名验证；任一权重可追溯到数据批次与代码提交

03阶段三：能响应

建设内容

最小控制五　插件/MCP/Agent 运行时控制；最小控制六　变更管理与可替换性；最小控制七　漏洞、许可与事件响应接入

完成标志（可验收）

新漏洞可在小时级给出受影响名单与责任人；高风险动作均有审批；实质变更自动触发评估与复测

三个阶段的顺序不能颠倒：没有台账，签名不知道该签谁；没有签名与 provenance，事件响应只能靠人工排查，小时级定位无从谈起。

还要注意一点：每阶段的完成标志必须是可验收的动作，而不是“完成了建设”这类描述。“能否在规定时间内给出一份名单”“能否追溯到某一批次”——这类问题有明确的是或否，才不会陷入“建了但不知道建没建好”的状态。

图 5　三个阶段的落地顺序：能回答 → 能验证 → 能响应

10小结

第一篇把智能体看见，回答“有多少智能体”；第二篇用 AIBOM 说清构成，回答“智能体由什么组成”；第三篇把风险测准，回答“安不安全、能否上线”；本篇把要求落到证据，回答“出事时拿得出什么”。

实践的基本原则——不追求一次做全：发现求全，但不要求清单同时完整；检测求准，但不要求用例无穷；落地求证据链，但允许标准逐步补齐。求全与求深解耦、判定留未知而非默认安全、先补证据再补标准，是同一条原则在不同环节的表现。

最后一句：标准会变，扫描能力会补上，但“出事时能不能拿出证据”这个要求不会变。先把证据链建起来，之后每补齐一块标准、每接入一类能力，都能直接落在已有的结构上——这是最小集真正的意义。