“The simplest solution to securing models is: sign the model when you train it and verify it every time you use it.” – Mihai Maruseac, Staff Software Engineer, Google.
Most Australian organisations running AI/ML models in production haven’t implemented this control yet – and there’s no reason not to. Because there’s a free way to do it that’s available today.
Today we’re going to introduce the OpenSSF Model Signing (OMS) specification which was created for this exact reason.
What is OMS?
The OpenSSF Model Signing specification was published by the OpenSSF AI/ML Working Group, with NVIDIA, Google and HiddenLayer, reaching v1.0 in April 2025.
Quoting from the OpenSSF GitHub repository (https://github.com/ossf/model-signing-spec):
“As AI adoption continues to accelerate, so does the need to secure the AI supply chain. Organizations want to be able to verify that the models they build, deploy, or consume are authentic, untampered, and compliant with internal policies and external regulations. From tampered models to poisoned datasets, the risks facing production AI systems are growing — and the industry is responding.
In collaboration with industry partners, the Open Source Security Foundation (OpenSSF)’s AI/ML Working Group has introduced OpenSSF Model Signing (OMS): a flexible and implementation-agnostic standard and tooling for model signing, purpose-built for the unique requirements of AI workflows.
The OMS specification defines a detached signature file that is typically distributed within the model folder. OMS is PKI-agnostic and supports signing with bare keys, PKI certificate chains, or identity-based keyless signing with Sigstore.”
Translating, OMS produces a detached Sigstore Bundle Format signature file. It’s created and kept as a file in the model’s folder, and so the model itself doesn’t need altering in any way.
Here’s a look inside the Sigstore Bundle:
- Content: either a message signature over an artifact hash or a DSSE envelope for attestations
- Verification material: the key material used to verify signatures along with supporting metadata like transparency log entries and timestamps
The OMS specification is agnostic when it comes to key infrastructure. That means you can sign using bare keys, with a certificate chain from your existing PKI, or even do it keyless.
Let’s explore that last one a bit further.
Recommendation for AI/ML teams: signing keyless
Sigstore keyless signing removes the need to have long-lived private-keys and complex secret management that you see in traditional signing approaches.
Instead it uses short-lived X.509 certificates tied to an OpenID Connect (OIDC) identity (such as a GitHub Actions identity or a corporate SSO identity):
- Following authentication, an ephemeral key pair is generated in-memory by your signing tool (e.g. Cosign)
- The ephemeral public key and the OIDC ID token are sent to Sigstore’s certificate authority, Fulcio, which validates the identity and issues a short-lived X.509 certificate (typically valid for only 10 minutes)
- This X.509 certificate is used to sign your artifact
- The signature, certificate and artifact digest are uploaded to the Rekor transparency log with a timestamp for public, tamper-proof auditing
- The ephemeral private key is permanently discarded
Because the signing event is permanently recorded in Rekor with a timestamp, anyone can later verify that the signature was valid at the time it was created. Meaning that verification checks the log rather than a key set you have to maintain.
This fits in nicely with AI/ML model development. Your data scientists have their time freed up because signing will happen at the end of a training run, without the overhead of traditional signing approaches.
This is already being implemented for upstream models
NVIDIA has been signing every NVIDIA-published model in their NGC Catalog with OMS since March 2025. Google has also been implementing OMS in their Kaggle model hub.
Which means that some of the models your teams consume are likely already signed this way.
The question is, are they verifying them yet?
Signing and scanning do different jobs
The two work together but do different jobs.
Scanning verifies if a file contains anything known to be malicious. Signing verifies if a file is actually unchanged and from its publisher.
You need both – a model can be signed and still contain something malicious, while a model that passes a scan may have been tampered with in transit.
Three things to keep in mind
Keep these in mind:
- Signing doesn’t verify mode safety: Iif you have a model that was backdoored, signing tells you the chain is intact, but not that the artifact is a good model.
- Sigstore doesn’t verify the distribution path: if a signed model was uploaded to two difference registries, signing won’t inform you of provenance.
- Performance degrades as you scale your artifact: CPU-based signing degrades linearly with artifact size. There’s active research on GPU-accelerated verification, but more to come. For enterprise-scale fine-tuned models this won’t be an issue but for very large artifacts it will.
What should you do now?
Here’s what I suggest:
- Start verifying signatures on models you consume, where they are available. This is an easy win as a step in your ingestion pipeline.
- Sign your own artifacts at the end of every training run, keyless through your existing SSO identity. Record the signature alongside the model in your artifact register.
- Then enforce verification as a gate at deployment, so an unsigned or unverifiable artifact cannot reach your production environment.
That third step may lead to some contention in your organisation, as it’s a step that can lead to blocked deployments. Which is why you should start building it into your AI/ML platform early, when it’s small.
Sources
- OpenSSF Model Signing (OMS) Specification — https://github.com/ossf/model-signing-spec
- Sigstore, Practical Model Signing with Sigstore — https://blog.sigstore.dev/model-transparency-v1.0/
- NVIDIA, Bringing Verifiable Trust to AI Models: Model Signing in NGC — https://developer.nvidia.com/blog/bringing-verifiable-trust-to-ai-models-model-signing-in-ngc