Model signing records a digest for each file in a model folder, signs that list, and ships the signature next to the model. A consumer re-computes the digests and checks the signature against an expected identity. A pass means the files match what that identity signed. It does not mean the model is safe.
The flow in the Sigstore model signing project
The sigstore model-transparency repository describes a project aimed at strengthening the machine learning supply chain in the same way as the traditional software supply chain. Its model signing tooling produces a Sigstore bundle, a JSON file. The bundle holds verification material and a DSSE envelope, which contains an in-toto statement and a signature over it.
The statement lists subjects, each a file path with a digest. So the thing being signed is a manifest of file hashes for the model folder.
Signing
- The tool hashes each file in the model directory.
- It builds the statement listing those paths and digests.
- It signs the statement. The default method uses an OIDC login to get a short-lived certificate. Private keys, certificates and PKCS #11 devices are also supported.
- With the Sigstore method, the signing event is recorded in Sigstore's append-only transparency log.
- The bundle is saved, typically alongside the model.
Verifying
- Read the bundle and check the signature is valid.
- Re-compute the hashes of the model files you actually have.
- Compare them to the signed digests. Any mismatch means a file changed, or one is missing or added.
- For Sigstore signatures, supply the identity and OIDC provider you expect. They must match what was used when signing.
- Optionally check a proof of inclusion in the transparency log.
Step 4 is the one people skip. A valid signature from an unknown identity proves little. The project page states you must still check that the signature comes from a known or trusted identity.
What each check gives you
- Valid signature: the manifest was signed by the holder of that identity or key.
- Matching hashes: the files you hold are the ones that were signed.
- Expected identity: the signer is who you decided to trust, such as your own CI or a publisher you rely on.
Where it fits in your pipeline
Sign at the end of your training or conversion job, in CI, with an identity you control. Verify at deploy time and again in any environment that pulls the model from a registry. Record the signer identity in your inventory.
For limits, see what a model signature does not tell you. For the general idea, see what Sigstore signing is.
Quick check
What gets signed, the model or a list?
A statement listing each file path and its digest. Verification re-hashes your files and compares them to that list.
Is a valid signature enough?
Only if the identity is one you expected. Always supply the expected identity and provider when you verify.
Sources
Last reviewed: 19 October 2026.
