AI供应链安全：从模型来源到集群准入

穆梓兰煊
4 阅读10分钟

一个 AI 服务的攻击面，通常不只在推理接口，而在模型、数据集、依赖包、镜像和构建流水线。

只扫描容器镜像并不能证明模型安全：模型文件可能来自未验证的下载地址，数据集可能被投毒，生成式编码工具还可能把恶意依赖带进构建过程。

本文以 Kubernetes 上部署 AI 推理服务为例，说明如何用来源证明、软件物料清单和 Operator 准入策略，把“相信供应商”变成可以验证的工程流程。

一、真实场景：模型也是供应链制品

典型的 AI 服务交付链路如下：

数据集
  ↓
训练任务 / 微调任务
  ↓
模型权重与配置
  ↓
推理镜像
  ↓
镜像仓库
  ↓
Kubernetes 集群
  ↓
在线 API

每个环节都可能引入风险：

  • 训练数据被加入后门样本，导致特定输入触发异常输出；
  • 模型权重被替换，但文件名和版本标签保持不变；
  • Python 或 Go 依赖包被投毒；
  • 构建脚本下载未锁定版本的工具；
  • AI 编程工具生成了未经审查的依赖、Shell 命令或 CI 配置；
  • 推理镜像使用 latest 标签，部署时无法确认实际运行的内容。

这里的重点是：AI 供应链安全保护的不是单一模型，而是从来源、构建到部署的完整证据链。

当团队出现以下需求时，就应该引入供应链控制：

  1. 多个团队从不同来源下载基础模型；
  2. 模型需要经过安全评测、偏见检测或后门扫描后才能上线；
  3. 生产集群要求所有制品可追溯、可回滚；
  4. 需要证明某个模型由哪次训练任务、使用哪些数据和依赖生成。

二、四个核心概念：不要把“扫描”当成“可信”

1. 软件物料清单：回答“里面有什么”

软件物料清单（Software Bill of Materials，SBOM）记录制品包含的组件、版本和依赖关系。常见格式包括 SPDX 和 CycloneDX，SPDX 2.3 是可验证的标准版本之一。

对于 AI 服务，SBOM 不应只描述容器中的操作系统包，还应覆盖：

  • Python、Go、CUDA 相关依赖；
  • 推理服务器及其插件；
  • 模型文件的 SHA-256 摘要；
  • tokenizer、配置文件和启动脚本；
  • 数据集标识、处理代码和训练参数。

结论：SBOM 解决“内容可见性”，不直接解决“内容可信性”。

机制是构建阶段生成 SBOM，并把它作为 OCI 附件或构建产物保存。部署时通过摘要关联它，而不是依赖浮动标签。

例如，一个模型镜像不能只写：

image: registry.example.com/llm-server:v3

更可靠的引用方式是：

image: registry.example.com/llm-server@sha256:ab12...

例证是模型权重即使没有可执行权限，也可能影响推理结果；因此只扫描 ELF 文件和系统包，会漏掉模型本身的完整性问题。

2. 来源证明：回答“谁、用什么、如何构建”

来源证明（Provenance）描述制品的构建过程，包括源码、构建器、参数、输入材料和输出摘要。

SLSA（Supply-chain Levels for Software Artifacts）v1.0 定义了供应链完整性的一套通用模型。它不等同于“模型安全认证”，但可以证明某个制品是否由声明的流程构建。

结论：来源证明解决“制品从哪里来”，但不能证明训练数据没有毒。

机制通常是：

源代码提交
  ↓
不可变构建任务
  ↓
生成镜像 / 模型
  ↓
生成 Provenance
  ↓
签名并上传仓库

例证：如果生产环境发现模型输出异常，可以根据 Provenance 反查：

  • 使用了哪个 Git 提交；
  • 哪个构建任务生成；
  • 使用了哪一个基础镜像；
  • 模型权重和配置的摘要是什么；
  • 构建过程中是否下载了额外文件。

3. 签名与验证：回答“部署的是否就是它”

Sigstore 提供了面向软件制品的签名生态，Cosign 可对 OCI 镜像及其关联制品进行签名和验证。其关键价值不是“加密很复杂”，而是让部署系统能够验证制品身份和完整性。

结论：签名必须靠近部署准入检查，否则只是仓库里的装饰性元数据。

机制包括：

  1. 构建系统为镜像和模型附件生成摘要；
  2. 使用工作负载身份或密钥完成签名；
  3. 签名记录进入透明日志；
  4. Kubernetes 准入组件校验签名、来源和策略；
  5. 不符合策略的工作负载直接拒绝。

例证：攻击者把 model:v3 指向新的恶意权重时，标签可能仍然正确，但摘要会改变；准入阶段校验签名，就能阻止未授权替换。

4. AI 安全评测：回答“它是否适合这个用途”

供应链安全不能只验证“文件没被改”，还需要验证模型行为是否满足用途。

评测范围可以包括：

  • 后门触发测试；
  • 越权指令和提示注入测试；
  • 敏感信息记忆测试；
  • 训练数据许可证检查；
  • 输出拒答和安全边界测试；
  • 模型与 tokenizer、配置是否匹配。

结论：完整性验证和行为安全验证是两个不同层次，不能互相替代。

例如，签名可以证明某个模型确实来自内部训练流水线，但如果训练数据本身被污染，签名不会自动发现问题。工程上应把评测报告也作为带摘要的制品，与模型绑定。

三、关键机制：用 Operator 把策略变成集群行为

仅靠文档约束开发者，通常会在紧急发布时失效。更稳定的做法是使用 Kubernetes Operator 管理 AI 制品的生命周期。

可以定义一个简化的自定义资源：

apiVersion: ai.example.com/v1alpha1
kind: VerifiedModel
metadata:
  name: fraud-classifier
spec:
  artifact: oci://registry.example.com/models/fraud-classifier
  digest: sha256:ab12...
  signer: workload-identity://ml-build/prod
  provenance:
    builder: https://ci.example.com/builders/ai
    slsaLevel: 3
  evaluation:
    report: oci://registry.example.com/reports/fraud-classifier
    maxRiskScore: 0.20

Operator 的控制逻辑可以拆成四层：

  1. 解析层：读取模型摘要、镜像摘要和评测报告；
  2. 验证层：验证 Cosign 签名、签名身份和 Provenance；
  3. 策略层：检查评测分数、允许的构建器和来源仓库；
  4. 执行层：生成 Deployment、Service 和 NetworkPolicy。

Go 1.24 中实现控制器时，重点不是写更多业务逻辑，而是保持验证过程幂等。下面是一个简化的策略检查函数：

package policy

import (
	"errors"
	"fmt"
)

type Artifact struct {
	Digest     string
	Signer     string
	Builder    string
	SLSALevel  int
	RiskScore  float64
}

type Rule struct {
	AllowedSigner string
	AllowedBuilder string
	MinSLSALevel int
	MaxRiskScore float64
}

func Validate(a Artifact, r Rule) error {
	// 禁止使用 tag 作为身份；生产策略必须要求不可变摘要。
	if len(a.Digest) < len("sha256:") || a.Digest[:len("sha256:")] != "sha256:" {
		return errors.New("artifact must use sha256 digest")
	}

	if a.Signer != r.AllowedSigner {
		return fmt.Errorf("unexpected signer: %s", a.Signer)
	}

	if a.Builder != r.AllowedBuilder {
		return fmt.Errorf("unexpected builder: %s", a.Builder)
	}

	if a.SLSALevel < r.MinSLSALevel {
		return fmt.Errorf("insufficient provenance level: %d", a.SLSALevel)
	}

	if a.RiskScore > r.MaxRiskScore {
		return fmt.Errorf("evaluation risk score %.2f exceeds limit", a.RiskScore)
	}

	return nil
}

实际系统中，Validate 前面还应调用签名验证工具，并校验签名声明中的摘要是否与部署对象一致。Operator 负责持续对账：如果已部署模型的签名、来源或评测报告失效，应更新状态并阻止后续滚动发布，而不是静默修复。

四、工程选型：控制点应放在哪里

控制方式主要解决的问题优点不适用条件
镜像扫描OS 包、依赖漏洞接入简单，适合基础门禁无法证明模型来源和行为
SBOM制品内容可见便于审计和漏洞追踪不包含完整的可信来源结论
Sigstore/Cosign摘要完整性和签名身份可接入 OCI 与准入流程密钥或身份管理薄弱时价值下降
SLSA Provenance构建过程可追溯便于定位构建和发布问题不能替代数据质量与模型评测
Kubernetes Operator持续执行领域策略适合多团队、多模型平台单一服务或临时实验可能过重
AI 行为评测后门、越权、输出风险覆盖模型特有风险评测集不足时容易产生假阴性

明确的落地结论是：

  • 单团队、模型数量少：先做摘要固定、签名验证和基础 SBOM；
  • 多团队共享模型平台：增加 Provenance、评测报告和 Operator；
  • 高风险业务：把数据集版本、训练任务和行为评测纳入发布审批；
  • 研究实验环境：可以放宽准入，但必须标记为非生产制品，不能混入生产仓库。

五、常见坑：签名正确，模型仍可能不安全

一个真实可行的错误流程是：

  1. CI 对镜像签名；
  2. 镜像中通过启动脚本下载模型；
  3. 模型下载地址使用固定域名而非摘要；
  4. 部署准入只验证镜像签名；
  5. 攻击者替换远程模型文件。

此时镜像本身没有改变，签名也有效，但运行时加载的模型已经不是构建时验证过的模型。

规避方式是：

  • 模型作为镜像层或 OCI artifact 管理；
  • 对模型文件固定 SHA-256 摘要；
  • 禁止启动脚本从任意公网地址下载制品；
  • Operator 验证镜像、模型和评测报告三者摘要；
  • 运行时使用只读文件系统，并限制出站网络；
  • 对模型仓库启用审计日志和不可变版本。

另一个 AI 特有的坑是过度依赖 AI 工具生成安全策略。AI 可以快速生成 Kubernetes YAML、OPA 规则或依赖升级建议，但它并不了解组织中的签名身份、信任边界和例外流程。AI 适合辅助发现和生成，不应成为最终的信任根。

六、学习与落地路径

建议按以下顺序建立能力：

第一阶段：理解制品与部署边界

先掌握 OCI 镜像摘要、Kubernetes Deployment、Admission Webhook、RBAC 和 NetworkPolicy。动手把一个模型镜像从 tag 改为 digest，并记录模型权重摘要。

第二阶段：建立可追溯链路

学习 SPDX 2.3、SLSA v1.0、Sigstore 和 Cosign。为构建流程生成 SBOM 与 Provenance，并在测试集群中验证签名。

第三阶段：编写领域策略

使用 Go 1.24 编写 Operator，定义模型来源、签名身份、评测报告和风险阈值。先实现“拒绝未签名制品”，再增加构建器、数据集和模型版本约束。

第四阶段：引入 AI 安全评测

建立与业务相关的测试集，而不是只运行通用基准。重点覆盖后门触发、提示注入、敏感数据泄露和工具调用越权，并把评测结果作为可验证制品保存。

第五阶段：用 AI 加速而不是替代判断

AI 工具可以帮助分析 SBOM、归并漏洞、生成策略草稿、解释 Provenance 和编写测试用例。但生产发布仍应由确定性的验证器、准入策略和人工审批共同完成。

AI 供应链安全的核心不是增加一个扫描器，而是建立“制品可见、来源可证、行为可评、部署可拒”的闭环。模型、数据集和推理镜像都应被当作可验证制品管理。

当团队开始部署多个模型或允许 AI 工具参与研发时，Operator 准入和来源证明会比单纯的镜像漏洞扫描更有价值。

你所在的团队会优先把模型评测报告纳入发布门禁，还是先从签名与 SBOM 开始？

avatar
文章
阅读
粉丝