AIMM：AI/ML 产物的信任与来源成熟度模型

原创

APT-101
APT-101

APT-101

2026年10月13日 19:23
陕西

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

AI安全#供应链安全#模型治理#OASIS#密码学

01 背景

讲 AI 供应链的信任，得先提一份 2026 年的标准文件：OASIS CoSAI（安全 AI 联盟）第一工作组发布的《AIMM: Artifact Integrity Maturity Model for AI/ML Supply Chain Trust and Provenance》，全名很长，意思就一句——AI/ML 供应链信任与来源的产物完整性成熟度模型，2026 年 9 月批准，v1.0。

先看现状。机器学习模型已经进到基础设施里了——自动驾驶、医疗诊断、金融算法都在跑。这些模型很少一次成型：微调、量化、蒸馏、压缩，一路变换，跨团队、跨组织流转。可这条链几乎没设防。大多数模型在供应链上游是无签名、未验证、不可追溯的状态。监管也压过来了，EU AI Act、NIST AI RMF 开始要求组织掌握自己的 AI 依赖、留得住可审计的证据。

02 要解决的问题

AI/ML 供应链的信任缺口可以归成三类，正好对应这份文件的三个级别。

第一类，产物被改、被换，消费者察觉不到。模型在生命周期里流转，训练、上传、部署，任何一步都可能被动手脚；注册表被攻破、发布环节被替换，没有签名机制的话，你根本无从检测。对应的问题：这个产物是不是它声称的那个？

第二类，上游的问题会静默传播。上游一个环节出错或者被做手脚，会顺着整条链传下去，全程无声。基础模型暴出漏洞，没有谱系记录的组织，连\"哪些部署模型继承了这个问题\"都查不出来。还有个更基本的点：来源声明要是不签名，那只是一份可伪造的文档。对应的问题：这个产物从哪来、经历了什么？

第三类，合规没法自动证明。内部有评估门槛、数据许可要求，外部有行业标准和监管义务。过去全靠人工审，真到审计的时候再翻箱倒柜补证据。对应的问题：这个产物满足我们定的政策和标准吗？

图1｜三级递进，每级多答一个信任问题：它是它吗、从哪来的、合不合规

03 三级模型与价值

这套模型分三级，一级压一级：L2 包含 L1 的完整性保证，L3 是完整三件套——完整性、谱系、自定义证明。

L1：先确认\"它是它\"。做法很朴素：全产物算哈希（SHA-256），生产者用私钥签名；消费者下载时重新算一遍，拿公钥验签。任何改动——哪怕一个比特、一个文件——校验立刻断。它给消费者的承诺只有两个：这产物没被人动过，且确实是声称的生产者发出的。模型被篡改、被替换、注册表被攻破、供应链攻击、意外损坏，在验签这一关全都会被拦。集成也刻意做得轻：只在发布边界签名（训练完、打包完，产物不再变的时候），消费端在下载边界验。局限要说清楚：签名是单一时点的快照，变换过程中发生的篡改，它管不了。还有个容易被忽略的大前提：签名能信，靠的是生产者那边的签名环境本身没失陷——密钥没被偷、签名过程受控可监控。前提不成立，验签系统再完整也是白搭。

图2｜L1：哈希+私钥签名，消费端重算+公钥验证——哪怕一个比特，校验即断

L2：追问\"它从哪来\"。除了签产物本身，再签来源声明——输入了什么、经过什么变换、派生自谁，格式可以参照 in-toto attestation。派生产物签名时引用父产物的哈希，父子链接一代代往下传，形成一条可审计的保管链；拓扑从版本链一路做到模型集成那种复杂图。消费端怎么验，这份文件给了一组很具体的动作：验签名和签名者身份、用可信时间戳或短寿命证书防重放、沿谱系逐个验父产物签名、核对声明里记的哈希和实际产物一致、多方签名时交叉核对。这套做下来收益是实在的：上游出问题，几分钟划出受影响的下游名单；监管要来源记录，签过名的声明直接就是审计证据；每一轮变换谁做的，一清二楚，好问责。局限也有：谱系管理是一笔不小的运营账，而且它只记录\"发生了什么变换\"，不判断\"这些变换合不合政策\"。

图3｜L2：派生产物引用父产物哈希，链上每一步都有签字，保管链可审计

L3：最后一道闸，把不合规的挡在生产外面。四类证明：模型证明（评估指标、质量、公平性、安全基准——模型行为没法靠看代码判断，只能记录评估结论，信不信取决于发证的人是谁）、数据证明（来源、收集方法、预处理、PII 扫描、许可——这块在 EU AI Act 语境下监管权重最高）、过程证明（管线、构建环境、配置、输入产物）、基础设施证明（硬件平台、安全控制、TEE 硬件报告，能一路追到硬件根信任）。这些证明由多方 attester 各自签名，一个政策引擎自动评估成 PASS/WARN/FAIL，评估结论本身也签名归档。讲到这一步有个分界值得说透：L3 的证明是符合 predicate schema 的结构化声明，机器能解析、能判定——这是自动化的前提；L2 的证明讲的是关系和派生，光靠来源谱系做不了合规判定。最后过准入门禁：不合格的产物在进生产前被拦下，而不是上线之后被贴标签。门禁没落地之前，证明都是建议性的；门禁一上，才谈得上预防性控制。

图4｜L3：四类证明过政策引擎，门禁给结论——不合规的，进生产前拦下

多方 attester 来自不同部门甚至不同组织，声明撞车是常态。处理机制有三道：角色校验（谁被授权出哪类声明，越权的直接拒）、完整性审查（必需证明缺席就拒，推荐证明缺失给警告）、一致性校验（多方独立算的哈希必须一致，不一致说明产物在两个测量点之间被改过，立即失败）。真要撞车，按预置的裁决策略走：任何冲突即失败、多数表决、更高权威优先或最新声明生效，看环境挑。

三个级别合起来的共同效果，是把信任的依据整个换掉：从\"大家都默认没问题\"，变成\"每一步都有签名声明可以查\"。这里容易被忽略的一点：每一级都是合法的终点，不是非往上爬不可的台阶。级别按用例的风险选，不按组织的体面选——同一个组织，临床诊断模型上 L3，内部实验用 L1，完全可以并存。

04 落地执行

落地顺序值得按流程讲一遍，因为顺序本身就是这道题的一半答案。

第一站一定是 L1，且先从最高风险的模型下手：生产部署的、对外供服务的、被监管盯着的；外部来源的模型排最前——它们的完整性风险最高。当下绝大多数外部模型没有生产者签名，一个务实的做法是\"摄入重签\"：下载下来、做能做的完整性检查、用自己组织的密钥签上、再放进内部注册表。这当然不等于端到端的生产者签名，但从这一刻起，你的信任边界是签过字的。

L2 不用急，等模型出现复杂派生历史再上：微调、蒸馏、多来源，这时候验证来源链带来的安全收益才撑得起投入。就算这时候上，也可以先从最要紧的一条链签起——微调模型对基础模型——数据集和过程的签名以后慢慢补。消费端在摄入时验来源链，用现成验证库拿一个明确的通过与失败。

L3 等两个条件都齐了再动：一是有明确的政策要求（监管或内部），二是证明与基础设施接得住。现在完全自动化还是愿望——能承载合规指标的证明 schema 大多没成熟，也没经过严格的标准化审视。实操从混合模式起步：难自动化的检查先靠人工同行评审，一点一点自动化。

政策引擎到底评估什么？一条最小政策就三条基础规则：完整性（L1）、来源链验证（L2）、证明有效性（L3），再叠上你自己的域规则——评估阈值、公平指标、数据许可、基础设施安全要求。门禁接进生产基础设施那天，别忘了预先定义故障行为：引擎不可用时谁降级放行、怎么升级到人、逃生通道（break-glass）在哪。

在所有这一切之前，先把密钥管好：私钥防未授权访问、信任库有人策展、轮换和撤销流程在需要之前就定义好。签名这件事，密钥是命门，命门失守，后面全是白搭。

落地用什么工具：外面已经有现成的，不用从零造。Sigstore 提供无密钥签名基础设施；model-signing 项目把签名能力扩展到 ML 产物本身；SLSA、Atlas CLI、in-toto 给来源与证明铺垫好了框架；威胁建模可以参考 MITRE ATLAS。

最后必须划清边界：签名保证的是完整性和真实性，不保证产物本身正确、安全、公平、行为良性。运行时行为威胁、签名基础设施失陷、不留下产物痕迹的训练期攻击，签名一概管不了。这一套只是纵深防御里的一层，行为测试、运行时监控、独立审计，该做的照做。

把落地路径归纳成一句话：从眼下风险最高的模型开始签名，把验证养成习惯，供应链信任就有个像样的起点。