模型安全扫描结果该如何绑定制品？签名证明方案探讨

一个被忽视的ML供应链安全缺口

当你对一个模型或 Agent 捆绑包进行安全扫描——检查 pickle 反序列化漏洞、许可证合规问题或数据泄露风险时，一个关键问题随之而来：扫描结果最终去了哪里？

在多数团队的实际工作流中，这些扫描结果往往躺在 CI 日志或某个 Dashboard 里，而真正被部署的制品（artifact）与这些结果之间却没有任何可验证的链接。换句话说，你扫描过的那个模型，和你部署上线的那个模型，在系统层面无法证明是"同一个经过验证的对象"。这正是 KitOps 维护者、Jozu 联合创始人在 Reddit 上抛出的一个值得深思的工程问题。

这个缺口在传统软件供应链里已有成熟的应对思路，但在机器学习制品这个相对年轻的领域，实践路径仍不清晰。模型文件体积大、格式特殊（如 pickle、safetensors）、依赖关系复杂，使得安全证明的绑定与传递比普通二进制包更棘手。

把扫描结果变成随制品流动的签名证明

帖主提出的做法颇具代表性：将每一次扫描结果作为 cosign attestation（签名证明）附加到 OCI 制品上，然后由集群在启动阶段执行策略校验——任何缺少策略所要求证明的制品，一律拒绝启动。

这套机制的核心逻辑是把"安全证据"从外部系统（CI 日志、Dashboard）转移到制品本身。证明通过密码学签名绑定到特定的制品摘要（digest）上，任何人都可以在部署前验证：这个模型是否经过了 pickle 漏洞扫描？许可证检查是否通过？签名是否可信？

这种"证据与制品同行"的思路，本质上是把安全从一次性的流程动作，变成了制品不可分割的属性。相比把扫描结果留在流水线里，它解决了审计断链、环境漂移和部署信任缺失的问题。帖主坦言这套方案"确实能跑通"，但也引出了几个他自己也没有理想答案的难题。

cosign 是 Sigstore 项目下的开源工具，专为 OCI 容器镜像和制品的签名、验证与证明（attestation）而设计。其核心思路是将签名信息存储在与制品同一个 OCI 仓库中，通过制品的内容摘要（SHA256 digest）进行密码学绑定——只要制品内容发生任何变化，摘要随之改变，原有签名自动失效。Attestation 是 cosign 提供的进阶能力：它允许将任意结构化元数据（如扫描报告、SBOM、构建日志）以签名的形式附加到制品上，格式遵循 in-toto Attestation Framework，可被 Kubernetes 策略引擎（如 Kyverno、OPA Gatekeeper）在部署时自动拦截验证。OCI（Open Container Initiative）则是容器镜像与制品分发的通用标准，目前已不限于容器，模型文件、Helm Chart 等均可打包为 OCI 制品存入标准仓库，这也是将 ML 模型纳入供应链安全体系的基础设施前提。

三个尚无定论的工程难题

扫描器升级后如何处理重扫？

安全扫描器本身会持续更新规则库和检测能力。一个今天通过扫描的模型，可能在扫描器升级后暴露出新的风险。那么问题来了：重扫之后应该生成一条新的 attestation，还是重新签名覆盖原有结果？

这涉及证明的版本管理与时效性。保留历史证明有利于审计追溯，但也会让制品携带的元数据不断膨胀；覆盖式更新更简洁，却丢失了"某个时间点基于某版本扫描器的判断"这一重要上下文。合理的做法通常是追加而非覆盖，并在证明中记录扫描器版本与时间戳。

谁应该签名——生产方还是消费方？

另一个治理层面的分歧是：签名的责任主体应该是制品的生产方（producer），还是消费它的平台团队（platform team）？

生产方签名意味着"我对我产出的模型做过这些检查"，天然贴近源头责任；平台团队签名则代表"我们在接入前独立验证过"，更符合零信任原则。现实中这往往不是二选一，而是两者各签各的证明，形成多方背书的信任链。不同角色的签名回答的是不同问题，混为一谈反而会削弱证明的语义清晰度。

SLSA 与 in-toto 能否用于 ML 制品？

帖主特别发问：是否有团队专门针对 ML 制品使用 SLSA 或 in-toto 格式？这两套规范在传统软件供应链安全中已被广泛采用，用于描述构建来源（provenance）与证明链。

将它们迁移到机器学习场景，理论上可行且方向正确——in-toto 的 attestation 框架本就设计为可扩展的。但模型训练的不可复现性、数据集的难以哈希化、以及 pickle 这类格式特有的风险，都是现成规范尚未充分覆盖的空白地带。

SLSA（Supply chain Levels for Software Artifacts，读作"salsa"）是由 Google 主导、OpenSSF 维护的供应链安全框架，定义了从 L1 到 L4 四个递进等级，核心要求包括：构建过程可审计、来源（provenance）可验证、构建环境不可篡改等。in-toto 则是一套更底层的证明框架，允许为软件生命周期中的每个步骤（代码提交、构建、测试、打包）定义"布局"（layout）并收集对应的"链接元数据"（link metadata），最终形成完整的证明链。两者并非互斥：SLSA 的 Provenance 格式实际上基于 in-toto Attestation 规范构建。将这套体系用于 ML 制品的主要挑战在于，模型训练本质上是非确定性的——相同代码、相同数据运行两次可能产生不同权重，这使得"构建可复现"这一 SLSA 高等级核心要求在 ML 场景下难以满足；数据集通常体积过大且动态变化，也难以像代码那样做精确的哈希锚定。

为什么这个问题值得整个行业关注

随着模型和 Agent 捆绑包越来越多地进入生产环境，"你部署的到底是什么、它是否安全"这个问题的严肃性正在上升。pickle 反序列化漏洞可以直接导致远程代码执行，许可证违规可能带来法律风险，而训练数据泄露则触及合规红线。

把扫描结果绑定为签名证明、并由集群强制校验，是把这些抽象风险转化为可执行、可审计控制点的务实路径。它借鉴了成熟的软件供应链安全经验（cosign、OCI、策略引擎），同时暴露出 ML 领域特有的空白。

需要说明的是，上述方案与观点来自单一 Reddit 讨论，且发帖者本人身为相关工具的维护者，坦承存在立场偏向，读者应结合自身场景独立评估。但无论最终采用哪种格式与签名策略，"安全证据应当与制品同行、而非散落在流水线各处"这一核心主张，确实指向了当前 ML 工程实践中一个真实且被低估的缺口。

pickle 反序列化漏洞值得单独说明其严重性：Python 的 pickle 格式在反序列化时会执行任意 Python 代码，攻击者只需在模型文件中嵌入恶意 payload，即可在加载模型的机器上实现远程代码执行（RCE），无需任何额外漏洞配合。Hugging Face 平台已记录多起通过恶意模型文件传播的真实攻击案例。safetensors 格式正是为解决这一问题而设计的替代方案——它只存储张量数据，不支持任意代码执行。然而大量现存模型仍以 pickle 格式（.pkl、.pt、.bin）分发，这使得入库前的静态扫描（如 picklescan 工具）成为必要的防线，而将扫描结果以 attestation 形式绑定到制品，则可确保未经扫描的 pickle 模型无法悄无声息地进入生产集群。