借助模型签名，你可以在任何代码加载权重之前，核查磁盘上的文件是否正是某个已知发布者签署的文件。[1]这项检查的可靠程度取决于你拿来比对的签名者身份，而且它只覆盖已签名的文件。因此，下面每一步都给出一条命令，并说明它支持什么决定。本指南使用的工具是 model_signing，它是 model-signing 软件包的命令行工具，这个软件包来自 Sigstore 的 model-transparency 项目。[1, 2]截至 2026 年 10 月 20 日，Python 软件包索引（PyPI）上的当前版本是 1.1.1 版。[2]我们关于 1.0 版发布的简报介绍了背景。

何时使用本指南

当你收到一个已签名的模型，准备用它提供服务、对它做微调，或把它交给另一个系统时，就可以使用本指南。开源安全基金会（OpenSSF）的 AI/ML 工作组曾在 2025 年 4 月宣布 1.0 版发布。该工作组表示，每次使用模型时都应检查签名，包括选定模型用于部署时，以及模型成为另一个模型的输入时。[8]

开始前需要准备什么

  • 模型目录，与你将要加载的目录完全一致，并且由普通文件组成。除非你允许符号链接，否则工具遇到符号链接会报错并停止。[5]
  • 签名包（bundle），随模型一同分发，工具默认将其命名为 model.sig。[1, 3]
  • 预期的签名者，从你已经信任的渠道获取，例如发布者的文档。切勿从签名包中复制：签名包记录的是实际签名的一方，而这一方未必是发布者。
    • Sigstore 签名：签名者的 OpenID Connect（OIDC）身份及其签发方（issuer），即身份提供方。身份可以是电子邮件地址；自动签名时，则是工作负载身份，例如某个持续集成（CI）工作流。签发方包括 https://accounts.google.com，以及 GitHub Actions 使用的 https://token.actions.githubusercontent.com。[1, 3]
    • 密钥签名：发布者的公钥。
    • 证书签名：发布者的证书链。
  • Python 3.9 或更高版本，这是 1.1.1 版的运行要求。[2]

第 1 步：安装固定版本

安装一个确切的版本，然后查看工具报告的版本号。

pip install model-signing==1.1.1
model_signing --version

1.1.1 版有几个选项用下划线拼写，例如 --identity_provider。[3]一项尚未发布的改动把这些选项改为连字符写法，同时继续接受下划线写法。[7]因此，为后续版本编写的命令在 1.1.1 版上可能会失败。请以你所用版本对应标签下的 README 为准。[1]

第 2 步：对照预期的签名者验证

使用 Sigstore 时，签名者用一张短期证书签名，这张证书对应签名者的 OIDC 身份。签名事件会记录在一份公开、只追加的透明日志中。[1, 9]身份和签发方是必填参数，如果二者与签名不符，验证就会失败。[3]

model_signing verify path/to/model \
  --signature model.sig \
  --identity "$EXPECTED_IDENTITY" \
  --identity_provider "$EXPECTED_ISSUER"

使用密钥签名时，请传入发布者的公钥；能把签名与发布者联系起来的只有这把公钥。[3]

model_signing verify key path/to/model \
  --signature model.sig \
  --public_key publisher.pub

使用证书签名时，你必须自己确认签名者，因为命令会检查证书链，但没有参数可以指定预期的签名者名称。[3]如果不提供 --certificate_chain，命令会改用一组默认的根证书。[4]有些证书的扩展密钥用法字段不允许代码签名，1.1.1 版却会接受其中一部分，例如为 Web 服务器签发的证书。相应的修复尚未发布。[7]请传入发布者自己的证书链，并向发布者核实签名证书的 SHA-256 指纹，以此确认签名者；--log_fingerprints 会把这个指纹写入日志。[3]

model_signing verify certificate path/to/model \
  --signature model.sig \
  --certificate_chain publisher-chain.pem \
  --log_fingerprints

第 3 步：读懂结果覆盖了什么

先看输出：命令成功时输出 Verification succeeded，失败时输出 Verification failed with error: 及失败原因，并以状态码 1 退出。[3]它会对目录计算哈希。如果某个已签名的文件发生改动或缺失，或者目录中多出了文件，验证就会失败，错误信息会指出是哪些文件。[4]

对于跳过的路径，验证通过说明不了任何情况；默认跳过的路径包括与 Git 有关的文件。[1]从 1.1.0 版起，签名还会记录发布者在签名时排除的路径，验证时会自动跳过这些路径。[7]另有两个选项会在此基础上扩大跳过的范围：--ignore-paths 跳过你指定的路径，--ignore_unsigned_files 则让多余的文件也能通过。[3, 7]只有对你的加载器从不读取的文件，才可以使用这两个选项。

不要开启 --allow_symlinks。开启后，如果某个符号链接指向目录，1.1.1 版会悄无声息地让这个符号链接之下的所有文件既不签名、也不检查。据变更日志，这一缺陷只在尚未发布的代码中得到修复。[7]

要查看签名覆盖了哪些内容，可以用 jq 工具解码其中经过签名的声明：[9]

jq -r .dsseEnvelope.payload model.sig | base64 -d | jq .

在输出中，predicate.resources 列出签名覆盖的每个文件，以及它的哈希算法和摘要（即哈希值）。predicate.serialization 字段记录哈希设置，包括签名时排除的路径。[6]如果 predicateType 为 https://model_signing/Digests/v0.1，说明这是 1.0 版之前的签名。工具可以验证这类签名，但不能创建；用变更日志的话说，它把 0.2 版的实验性行为“连 bug 一起”照搬了过来。[6, 7]

第 4 步：检查透明日志条目

这一步只适用于 Sigstore 签名。这类签名记录在 Rekor 中，Rekor 是 Sigstore 的只追加透明日志。[1, 11]签名包中有一份收录证明，表明该条目在日志中；verify 命令已经检查过这份收录证明。[1, 9]签名包还包含该条目的日志索引和收录时间（integrated time），即该条目写入日志的时间。签名包中另有一个经过签名的时间戳，表明签名发生在短期证书的有效期内。因此，证书过期后，验证仍能成功。[9]

jq '.verificationMaterial.tlogEntries[] | {logIndex, integratedTime}' model.sig
rekor-cli get --rekor_server https://rekor.sigstore.dev --log-index <log-index>

第二条命令用 Rekor 命令行客户端获取该条目。[10]它查询的服务器托管着 Rekor 的原始日志，这仍是 Sigstore 公共实例的默认日志。各生态系统可以选择改用第 2 版日志，这些日志位于其他地址。[11, 12]

第 5 步：记录结果

保留足够的信息，让审计人员能够重复这项检查。

把摘要写入 AI 物料清单

2026 年 5 月，七国集团（G7）成员国的网络安全机构发布了面向 AI 的软件物料清单（SBOM）最低要素。它们把这种清单描述为 AI 系统组件的结构化记录。对于每个模型，清单应给出权重或模型文件的哈希值以及所用的哈希算法，以便验证该组件的完整性。SBOM 本身应带有可归属于其作者的数字签名。[13]

经过验证的模型签名能提供这样的哈希值，而且它们出自已知的签名者。predicate.resources 中的每个条目都给出一个文件的算法和摘要。声明的主体（subject）则带有一个 SHA-256 摘要，它根据所有这些摘要计算得出。按照该项目的设计，其他元数据文档可以用这个摘要指代该模型。[6]请把这些值复制到该模型的 SBOM 条目中。如果你收到的 SBOM 对同一文件、同一算法给出了不同的摘要，它描述的就不是发布者签署的那个文件。模型签名把文件与发布者联系起来，SBOM 的签名则把组件清单与其作者联系起来。我们关于最低要素的简报列出了全部要素。

示例

来源

  1. Model Transparency README at the v1.1.1 tagGitHub, sigstore/model-transparency · 2025年10月10日
  2. model-signing release metadata (JSON API)Python Package Index (PyPI) · 访问于 2026年10月20日
  3. Command-line interface source (_cli.py) at the v1.1.1 tagGitHub, sigstore/model-transparency · 2025年10月10日
  4. Verification API source (verifying.py) at the v1.1.1 tagGitHub, sigstore/model-transparency · 2025年10月10日
  5. Hashing API source (hashing.py) at the v1.1.1 tagGitHub, sigstore/model-transparency · 2025年10月10日
  6. Signature payload source (signing.py) at the v1.1.1 tagGitHub, sigstore/model-transparency · 2025年10月10日
  7. Changelog on the main branch at commit 087c3f5GitHub, sigstore/model-transparency · 访问于 2026年10月20日
  8. Launch of Model Signing v1.0: OpenSSF AI/ML Working Group Secures the Machine Learning Supply ChainOpen Source Security Foundation · 2025年4月4日
  9. Sigstore Bundle FormatSigstore documentation · 2025年1月14日
  10. CLI (Rekor transparency log)Sigstore documentation · 访问于 2026年10月20日
  11. sigstore.dev and Rekor evolutionSigstore Blog · 2026年6月28日
  12. Rekor v2 GA - Cheaper to run, simpler to maintainSigstore Blog · 2025年10月10日
  13. Software Bill of Materials for AI: Minimum ElementsG7 Cybersecurity Working Group, via BSI · 2026年5月12日
  14. Planting Undetectable Backdoors in Machine Learning ModelsarXiv (Goldwasser, Kim, Vaikuntanathan and Zamir) · 2022年4月14日
  15. Sleeper Agents: Training Deceptive LLMs that Persist Through Safety TrainingarXiv (Hubinger et al.) · 2024年1月10日

核查或更正本页

更正
提交更正请求 · 在 GitHub 编辑源文件 · 更正政策
验证记录

下方摘要可以说明你读到的文字是否与公开的源文件一致，但不能说明报道内容本身正确。这一摘要在构建时根据本页的 Markdown 源文件计算，并列入站点清单。

ff98047aba8beee4bef2c07e976b63c27f0286e4cd38b0d0ecf60d41853f1cd8

查看源文件 · 清单