OpenSSF Model Signing (OMS): Sigstore-based signing for ML models, explained

An ML model file — weights, a tokenizer config, whatever else ships in the model folder — moves through the same kind of multi-hop supply chain as a software binary: trained somewhere, uploaded to a hub, downloaded by a user or a device build pipeline, sometimes re-hosted by a third party along the way. At any of those hops it can be swapped or altered without the eventual user having any way to tell. OpenSSF's own framing ties this directly to prior supply-chain work: OMS aims to strengthen the ML supply chain "the same way" earlier OpenSSF projects — Sigstore itself, and SLSA — already did for traditional software, rather than inventing a parallel ML-specific trust model from scratch.

The reference implementation, hosted at github.com/sigstore/model-transparency and built on sigstore-python, hashes a model's files and produces a detached signature file distributed alongside the model, formatted as a Sigstore bundle for compatibility with the existing Sigstore ecosystem. OMS is deliberately PKI-agnostic — it supports bare keys and PKI certificate chains — but its headline mode is Sigstore's keyless signing: a signer authenticates via an OpenID Connect identity (for example, a model hub's own login), receives a short-lived certificate, signs the model, and the signing event is recorded in Sigstore's public, append-only transparency log. A verifier checks the signature and can additionally confirm a proof of inclusion in that log — meaning a signer who monitors the log can also detect unexpected signing events under their own identity, the same transparency property Sigstore gives conventional code signing.

The OpenSSF AI/ML Working Group formed its Model Signing Special Interest Group after a 2024 working-group presentation involving Google, NVIDIA and HiddenLayer, voting unanimously to pursue the technology. The v1.0 announcement credits co-leads from Google's Open Source Security Team (which also leads the broader AI/ML Working Group), two co-leads from NVIDIA, and one from HiddenLayer. Adoption followed quickly: per OpenSSF's own July 2025 case study, NVIDIA now signs all NVIDIA-published models in its NGC Catalog, and Google has piloted automatic Sigstore signing on upload for the Kaggle Model Hub — in both cases, the signing happens behind the scenes during a normal upload flow, with verification available to any downstream user via CLI or a hosted notebook.

They're complementary, not competing, pieces of the same OpenSSF supply-chain-security lineage. SLSA defines graduated levels of build-provenance assurance for a software artifact in general; in-toto defines a general attestation format for making verifiable claims about any step in a supply chain. OMS specializes that same transparency-and-attestation approach for the one artifact type neither was originally built around: a trained model file, which doesn't look like a conventional source-to-binary build and needs its own hashing and signature conventions — while still producing a Sigstore bundle any existing Sigstore-aware verifier can check.

No — a signature and an AI-BOM answer different questions about the same model. A model signature is a tamper-evidence and identity check on one specific file: is this the exact artifact a known signer produced, unmodified since. An AI-BOM is an inventory: what model is this, what did it depend on, where did its training data and base weights come from. A device vendor embedding a third-party model benefits from both — an AI-BOM to know what's actually running, and a verified signature to know the file hasn't been swapped for something else between the vendor's hub and the device's firmware image.

OMS was built with model hubs (Kaggle, NGC) as the first adopters, but the same verification step fits naturally into a device build pipeline that pulls in a third-party model: verify the model's OMS/Sigstore signature at ingest, the same way a mature build pipeline already verifies signed packages before they go into a firmware image. That closes a gap conventional firmware supply-chain controls don't cover on their own, since most existing firmware-build attestation tooling has no concept of a model file as a distinct artifact type to check.

SoftWSP matches a firmware image's declared build and component provenance against what's actually inside it as part of a firmware security assessment, including checking for embedded models and whether their provenance can be verified: see device & firmware security services.

This guide is based on OpenSSF's own v1.0 launch announcement, Sigstore's companion blog post, the ossf/model-signing-spec and sigstore/model-transparency GitHub repositories, OpenSSF's AI/ML Working Group spotlight post, and OpenSSF's July 2025 Google/Kaggle case study — all fetched directly. It is not a substitute for the primary OMS specification and does not constitute security or compliance advice.