文章总结： 本文系统阐述AI供应链安全治理框架，覆盖模型、数据、框架与第三方服务。核心是建立AI资产台账、供应商分级、来源证明、签名校验、准入门禁、变更监控与退出闭环。提出AIBOM十二字段、四级风险分级、八道准入门禁及运行时六道限制，并给出90天建立最小治理闭环的可操作路径，强调来源可追溯与持续验证。 综合评分： 88 文章分类： 供应链安全,安全建设,解决方案,数据安全,应用安全

AI 供应链安全：模型、数据集、框架和第三方服务治理

原创

咸鱼翻身日记 咸鱼翻身日记

企业安全指南

2026年9月2日 15:38 浙江

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

先证明每个 AI 资产从哪里来、有没有被替换，再决定能否进入生产

《AI 安全红队与评测实战：攻击样本、测试门禁和持续回归》把攻击样本、自动评测、人工红队和发布门禁连成了持续验证闭环。建立了风险场景、攻击样本、隔离评测、分层裁决和发布门禁；这一篇继续向上追溯被评测的模型、数据、框架和外部服务是否来自可信来源，是否在引入、更新和退出阶段持续受控。

但评测通过仍有一个前提：被测的模型、数据、框架和外部服务必须与最终上线版本完全一致，而且来源可信、过程可追溯、内容没有被替换。现实中，模型权重可能来自个人网盘，数据集可能经过无人记录的清洗，推理镜像可能临时安装新包，外部 API 可能悄悄调整模型、条款和数据留存方式。任何一环变化，都可能让昨天的安全结论失效。

本篇要解决的是：围绕基础模型、微调权重、训练与检索数据、标签、框架 SDK、容器镜像、模型仓库、外部 API 和评测服务，讲清企业如何建立 AI 资产台账、供应商分级、来源证明、签名校验、准入门禁、变更监控、替代方案和退出闭环。

一、AI 供应链比传统软件依赖多了什么

| 对象 | 传统软件常见内容 | AI 系统新增内容 | 主要风险 | | — | — | — | — | | 数据 | 配置、测试数据 | 训练、微调、评测、RAG、反馈和标签 | 投毒、偏差、侵权、敏感数据和来源不明 | | 模型 | 编译制品 | 基础模型、微调权重、LoRA、量化版本 | 权重替换、后门、能力漂移和许可证限制 | | 代码 | 源码、依赖包 | 训练框架、推理引擎、自定义模型代码 | 漏洞、恶意反序列化和远程代码执行 | | 平台 | 构建与运行环境 | 模型仓库、训练平台、GPU 镜像和评测服务 | 账号接管、制品篡改和构建过程不可追溯 | | 服务 | SaaS 与 API | 托管模型、向量服务、标注和护栏 API | 数据外发、版本暗改、停服和责任边界不清 |

传统 SBOM 仍然必要，但不够。企业还需要记录模型、权重、数据、Prompt、评测集和外部服务的版本及来源，把它们组合成面向 AI 系统的资产清单和来源证明。

二、先把八类关键资产纳入同一张供应链地图

| 资产类别 | 典型对象 | 必须明确的责任人 | | — | — | — | | 基础模型 | 开源权重、商用模型、内部预训练模型 | 模型 Owner | | 派生权重 | 微调模型、LoRA、Adapter、量化与蒸馏版本 | 算法与发布 Owner | | 数据资产 | 训练、微调、标签、评测、RAG 和反馈数据 | 数据 Owner | | 框架依赖 | PyTorch、Transformers、推理引擎和 SDK | 研发与平台 Owner | | 构建制品 | 训练脚本、容器镜像、模型包和配置 | DevSecOps Owner | | 模型仓库 | 公共 Hub、企业 Registry、对象存储 | 仓库 Owner | | 外部服务 | 模型 API、向量库、标注、护栏和评测服务 | 服务 Owner | | 证据资产 | 模型卡、数据卡、评测报告、签名和审批记录 | 风险与审计 Owner |

如果同一个模型同时存在“原始权重、微调权重、量化权重、推理镜像、托管 API”五种形态，就必须作为五个可关联但可独立变更的资产管理，不能只登记一个模型名称。

三、AI BOM 至少保留十二个字段

| 字段 | 记录内容 | | — | — | | 资产 ID | 企业内部唯一编号和资产类别 | | 名称与版本 | 模型、数据集、包、镜像或服务的准确版本 | | 摘要与签名 | SHA-256、签名、证明文件和验证结果 | | 来源位置 | 官方仓库、镜像仓库、供应商端点或内部路径 | | 生产者 | 发布组织、维护团队、构建者和联系渠道 | | 许可证条款 | 商用范围、再分发、数据使用和地域限制 | | 数据来源 | 采集、清洗、标签、授权、敏感等级和保留期限 | | 构建过程 | 训练代码、框架、参数、基础模型和构建环境 | | 依赖关系 | 上游模型、数据、软件包、镜像和外部 API | | 安全验证 | 漏洞、恶意代码、投毒、红队和业务评测结果 | | 责任与期限 | Owner、批准人、复核周期和支持终止时间 | | 替代与回滚 | 已验证替代项、切换条件和最后可信版本 |

版本不能只写 latest，模型不能只写展示名称，外部 API 不能只写供应商品牌。真正可追溯的记录必须能定位到不可变摘要、明确端点或合同版本。

四、按业务影响把供应链资产分成四级

| 等级 | 判断条件 | 准入要求 | 复核频率 | | — | — | — | — | | S1 低影响 | 内部试验，不接敏感数据和真实动作 | 来源登记、许可证确认、基础扫描 | 版本变化时 | | S2 一般业务 | 服务内部用户，输出可人工复核 | 完整台账、漏洞扫描、评测和 Owner | 每季度 | | S3 重要业务 | 接企业数据、客户流程或受控工具 | 签名校验、隔离验证、合同控制和替代方案 | 每月或重大变化时 | | S4 核心高影响 | 涉及资金、关键生产、核心数据或自动决策 | 双人批准、严格来源证明、全量评测、回滚和应急演练 | 持续监控 |

分级对象应是“资产与用途组合”。同一个开源模型用于公开文案生成可能是 S1，用于读取客户数据并触发退款则可能是 S4。

五、供应商准入先问八个问题

| 问题 | 需要的证据 | | — | — | | 谁生产并维护 | 法定主体、维护团队、漏洞联系渠道和支持期限 | | 数据从哪里来 | 数据来源、授权、清洗、标签和敏感数据处理说明 | | 模型如何构建 | 基础模型、训练框架、关键参数和构建环境说明 | | 制品如何保护 | 仓库权限、签名、摘要、发布审批和篡改检测 | | 漏洞如何处理 | 报告渠道、修复时限、通知机制和历史响应记录 | | 版本如何变化 | 固定版本能力、变更日志、弃用周期和兼容承诺 | | 数据如何使用 | 输入输出留存、训练使用、区域、分包商和删除机制 | | 终止后怎么办 | 数据返还删除、模型迁移、证据导出和替代方案 |

无法回答不等于一定不能用，但意味着企业需要降低用途等级、增加隔离和补偿控制，而不是默认接受未知风险。

六、模型与权重进入企业仓库前过八道门

| 准入门 | 检查动作 | 失败处理 | | — | — | — | | 来源门 | 只从批准的官方仓库或供应商端点获取 | 来源不明直接拒绝 | | 身份门 | 核对发布组织、维护者和仓库所有权 | 仿冒或转手仓库隔离调查 | | 完整性门 | 校验摘要、签名和来源证明 | 摘要不符停止导入 | | 格式门 | 优先使用安全权重格式，限制 Pickle 与远程代码 | 高风险格式进入沙箱转换 | | 内容门 | 扫描恶意文件、异常代码、敏感信息和可疑结构 | 命中后隔离并人工分析 | | 许可证门 | 核对商用、再分发、衍生模型和数据限制 | 条款不清不得生产使用 | | 能力门 | 在目标用例上做质量、安全、后门和滥用评测 | 高危失败不准发布 | | 发布门 | 固定摘要、镜像、配置、审批和回滚版本 | 未形成完整组合不得上线 |

权重文件不是“纯数据”的同义词。某些序列化格式或模型仓库可能包含可执行代码，加载动作本身就可能改变运行环境，因此必须在隔离环境中完成扫描、转换和验证。

七、数据集与标签准入关注八项边界

| 检查项 | 最低要求 | | — | — | | 来源合法性 | 来源、采集方式、许可、用途和地域边界明确 | | 内容完整性 | 文件数、记录数、摘要、Schema 和版本可验证 | | 敏感数据 | 识别个人信息、商业秘密、凭据和受限内容 | | 标签质量 | 标签规则、人员或供应商、抽检和争议处理可追溯 | | 投毒检测 | 异常分布、重复样本、触发词、后门与来源集中度检查 | | 权限隔离 | 原始、清洗、训练、评测和生产反馈分区授权 | | 变换记录 | 清洗、过滤、去重、增强和合成步骤可复现 | | 反馈回流 | 用户反馈、对话和人工修正重新验证后才能进入训练 |

数据不是导入一次就永久可信。每次加入新批次、重新标注、合成增强或生产反馈，都应重新执行验证，并产生新的版本和证据。

八、框架、SDK 和构建环境按七项控制

| 控制点 | 关键动作 | | — | — | | 锁定来源 | 使用企业代理仓库，禁止生产构建直接拉取未知源 | | 固定版本 | 依赖、镜像和运行时使用不可变版本与摘要 | | 漏洞扫描 | 对代码包、系统包、镜像和 GPU 运行时持续扫描 | | 恶意行为 | 检查安装脚本、远程代码、反序列化和异常网络连接 | | 构建隔离 | 临时环境、最小权限、无长期密钥并限制外网 | | 来源证明 | 记录源码、构建者、参数、依赖和输出摘要 | | 发布验证 | 准入时核对签名、来源证明和预期构建参数 |

SLSA 的价值不是生成一份附件，而是让消费方在使用制品前核对构建者身份、签名、源码位置、构建类型和外部参数是否符合企业预期。

九、第三方 AI 服务需要八类合同与技术控制

| 控制域 | 必须写清的内容 | | — | — | | 服务身份 | 企业账号、项目、端点、区域和允许模型清单 | | 数据使用 | 输入输出是否留存、是否用于训练、删除和导出方式 | | 子处理方 | 云平台、标注、日志、审核和其他分包商范围 | | 版本承诺 | 模型别名是否漂移、固定版本、变更通知和弃用周期 | | 安全能力 | 加密、隔离、日志、漏洞响应和事件通报时限 | | 访问控制 | API Key、短期 Token、网络限制和管理员权限 | | 可用性退出 | SLA、限流、停服、数据迁移和替代端点 | | 审计证据 | 调用日志、配置版本、评测结果和删除证明 |

最危险的不是第三方服务本身，而是企业用一个长期高权 API Key 调用不断变化的“latest”模型，同时没有请求日志、数据边界和替代方案。

十、来源验证链按六步执行

| 步骤 | 动作 | 输出 | | — | — | — | | 1. 识别对象 | 确认模型、数据、代码、镜像和服务准确身份 | 资产 ID | | 2. 获取可信来源 | 从批准仓库、端点或供应商渠道下载 | 来源记录 | | 3. 校验完整性 | 核对摘要、签名、证明和证书链 | 验证结果 | | 4. 检查内容 | 扫描恶意代码、漏洞、敏感信息和异常结构 | 风险报告 | | 5. 验证用途 | 在目标数据、权限和业务链上完成安全评测 | 用例结论 | | 6. 固化发布 | 将摘要、配置、审批、评测和回滚项绑定 | 发布清单 |

签名只能证明“某个身份签过这个对象”，不能自动证明对象安全。企业还必须判断是否信任签名者、签名内容是否匹配目标版本，以及该对象是否适合当前业务用途。

十一、准入结果形成五档决策

| 结论 | 适用情况 | 动作 | | — | — | — | | 可信准入 | 来源、完整性、条款、评测和退出方案均达标 | 固定版本后灰度使用 | | 条件准入 | 存在可补偿的中低风险和明确期限 | 限制数据、权限、用户与流量 | | 隔离试验 | 来源基本可信但格式、能力或条款尚未完成验证 | 仅沙箱与测试数据 | | 暂停更新 | 新版本变化不清或回归失败 | 保持最后可信版本 | | 拒绝或退出 | 来源不明、篡改、高危代码、严重条款或不可控变化 | 禁止使用并启动替换 |

准入结论绑定的是完整组合，而不是品牌。模型权重、推理镜像、SDK、系统 Prompt、外部 API 任一变化，都可能形成新的供应链版本。

十二、八类变化触发重新验证

| 变化 | 触发动作 | | — | — | | 模型或权重更新 | 重验摘要、签名、许可证和目标用例评测 | | 数据新增或重标 | 重验来源、敏感性、投毒和标签质量 | | 框架与 SDK 更新 | 重跑漏洞、恶意代码、兼容和安全回归 | | 构建环境变化 | 核对构建者、参数、依赖和来源证明 | | 服务端点或区域变化 | 复核数据流、网络、合规与身份控制 | | 条款与子处理方变化 | 法务、安全、隐私和业务 Owner 重新批准 | | 维护状态变化 | 评估停更、接管、所有权转移和漏洞响应能力 | | 生产事件或情报 | 隔离受影响版本，核对范围并启动替代或回滚 |

变更通知不能只依赖供应商邮件。企业还应监控仓库所有权、版本摘要、依赖、许可证、模型卡、端点响应和合同状态的差异。

十三、运行时再加六道限制

| 限制 | 目的 | | — | — | | 企业仓库中转 | 生产不直接从公共 Hub 下载模型和包 | | 只读不可变制品 | 防止运行节点临时替换权重或依赖 | | 禁止默认远程代码 | 降低加载模型时执行未知代码的风险 | | 网络与凭据隔离 | 控制模型、框架和外部服务可访问范围 | | 全链版本日志 | 每次请求关联模型、镜像、Prompt、数据和服务版本 | | 异常停止与回滚 | 摘要变化、服务漂移或高危事件立即切换可信版本 |

供应链控制不能止于采购和上线审批。运行时必须能够证明实际加载的对象就是批准对象，并在对象变化时自动阻断或降级。

十四、替代与退出至少准备六件事

1. 为 S3/S4 用例保留已经验证的备用模型、服务端点或本地降级方案。
2. 关键数据、Prompt、配置、评测集和日志能够使用开放格式导出。
3. 写清停服、重大漏洞、条款变化、所有权转移和连续回归失败的退出条件。
4. 定期验证切换后身份、数据、工具和业务流程仍然有效。
5. 合同终止后获取数据删除、账号关闭和凭据撤销证据。
6. 保留最后可信版本，但同步记录漏洞、支持期限和允许使用范围。

没有替代方案的准入，本质上是把风险决定权交给供应商。越是核心业务，越要在正常时期验证迁移和降级路径。

十五、运营看八项证据与指标

| 指标 | 回答的问题 | | — | — | | 关键资产登记率 | S3/S4 模型、数据和服务是否全部可见 | | 不可变版本覆盖率 | 生产是否仍使用 latest 或浮动依赖 | | 来源证明覆盖率 | 多少关键制品具备可验证来源和构建记录 | | 签名校验成功率 | 发布对象是否与批准摘要一致 | | 高风险格式存量 | Pickle、远程代码和未知脚本是否持续收敛 | | 变更复核及时率 | 新模型、数据、框架和条款是否按期重验 | | 供应商问题关闭率 | 漏洞、条款和证据缺口是否真正关闭 | | 替代恢复成功率 | 关键用例能否切换到最后可信或备用方案 |

指标必须按业务等级和资产类别拆分。大量低影响试验资产不能掩盖一个核心模型没有来源证明或一个关键 API 无法退出。

十六、90 天建立最小治理闭环

| 阶段 | 工作重点 | 交付物 | | — | — | — | | 0—30 天 | 选择 2—3 个高风险 AI 用例，盘点八类资产和供应商 | AI BOM、责任人和风险分级 | | 31—60 天 | 建立模型、数据、框架和服务四类准入规则 | 企业仓库、扫描、证明和审批模板 | | 61—90 天 | 接入发布门禁、差异监控、回滚和退出演练 | 五档决策、变更触发与替代证据 | | 持续运营 | 扩展覆盖、复核供应商、跟踪漏洞条款与版本 | 指标看板、问题队列和季度复盘 |

十七、十二项上线验收

| 验收项 | 是否通过 | | — | — | | 八类 AI 供应链资产都有唯一 ID、版本和 Owner | □ | | S3/S4 资产具备不可变摘要、来源位置和批准记录 | □ | | 模型与权重通过来源、格式、恶意代码和用例评测 | □ | | 数据来源、许可、敏感性、标签和变换过程可追溯 | □ | | 框架、SDK、镜像和构建环境固定版本并持续扫描 | □ | | 外部服务的数据使用、版本、子处理方和退出条款明确 | □ | | 关键制品的签名和来源证明在发布时自动校验 | □ | | 五档准入结论能够阻断高危对象进入生产 | □ | | 八类变化能触发对应资产和目标用例重新验证 | □ | | 生产运行日志能关联实际模型、数据、Prompt 和服务版本 | □ | | S3/S4 用例具备最后可信版本、备用方案和切换证据 | □ | | 漏洞、事件、条款变化和退出过程形成完整审计证据 | □ |

十八、管理者最后问五个问题

1. 当前核心 AI 用例实际依赖哪些模型、数据、框架、镜像和外部服务？
2. 如果某个权重或数据集被替换，我们多久能发现并停止发布？
3. 企业验证的是供应商品牌，还是不可变版本、来源证明和目标用途？
4. 外部模型 API 更新或改变数据条款后，谁负责重新评测和批准？
5. 关键供应商今天停服或出现重大漏洞，业务能否切到已验证替代方案？

AI 供应链安全的核心不是拒绝开源或第三方，而是让每个外部对象都有来源、版本、责任、验证和退出条件。先建立完整 AI BOM，再把分级准入、签名证明、持续监控和替代演练接入发布流程，企业才能在快速采用 AI 的同时保留风险决定权。

十九、下一篇预告

本篇建立了 AI 资产台账、可信准入、来源验证、变更监控和替代退出闭环。下一篇进入生产运营：AI 安全运营与事件响应：异常监控、快速止损和证据闭环，重点讲 AI 异常信号、影响确认、模型与工具止损、证据固化、恢复和事件样本回流。

参考来源

1. NIST SP 800-218A Secure Software Development Practices for Generative AI
2. OWASP LLM03:2025 Supply Chain
3. NCSC Guidelines for Secure AI System Development – Secure Development
4. NSA AI Data Security Best Practices
5. SLSA Specification v1.2
6. OpenSSF Model Signing v1.0

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：企业安全指南 咸鱼翻身日记 咸鱼翻身日记《AI 供应链安全：模型、数据集、框架和第三方服务治理》