Many believe you can secure AI models just like software artifacts. Sign them with the same tools, scan them with the same scanners, and apply the same supply chain controls you use for container images or npm packages.
This approach seems logical. It's not.
Why Container Security Patterns Don't Transfer
AI models aren't simply larger binaries. A PyTorch model file can contain arbitrary Python code that executes during deserialization. You can't search for malicious patterns like you would in a Dockerfile. Static analysis tools that work on source code struggle with 500MB of serialized tensor weights.
Mihai Maruseac, who leads the AI/ML Working Group under OpenSSF, states you can't reliably inspect a model for malicious content after the fact. The attack surface is too broad, the formats too complex, and the execution paths too dynamic.
This presents a different security challenge. With a container image, you can scan layers, check for known CVEs, and verify the base image's origin. With an ML model, you're trusting 500 million parameters you can't effectively audit. If someone poisoned the training data or injected a backdoor during fine-tuning, a scanner won't catch it.
The solution isn't better scanning. It's verifying integrity before the model ever reaches your infrastructure.
The Evidence: Why Model Signing Matters Now
OpenSSF released version 1.1 of their model signing specification around October of last year. NVIDIA's model hub adopted model signing solutions in April. These aren't theoretical exercises. Organizations are implementing model signing because the risk profile is real and growing.
Consider what happens without signing:
- You download a model from a public hub. How do you know it wasn't modified after the researcher uploaded it?
- Your data science team fine-tunes a model on internal data. How do you prove that version is the one deployed to production six months later?
- A compromised CI/CD pipeline pushes a model update. How does your runtime environment distinguish it from a legitimate release?
Container signing solved these problems for images. Model signing solves them for ML artifacts. The difference is that with models, the "artifact" might contain executable code that runs with the privileges of your inference service, accessing customer data or internal systems.
PCI DSS v4.0.1 Requirement 6.3.2 requires you to maintain an inventory of bespoke and custom software. If your model contains custom code or was trained on proprietary data, it's software. You need to track its provenance and verify its integrity. Model signing gives you a cryptographic audit trail from training to deployment.
What to Do Instead: Practical Model Signing
Start with Sigstore for keyless signing. This removes the operational burden of key management while giving you verifiable signatures. Your ML engineers don't need to manage GPG keys or certificate authorities.
Here's what implementation looks like:
In your training pipeline: Sign the model immediately after training completes, before it's pushed to your model registry. Capture the commit hash, training dataset version, and hyperparameters in the signature metadata. This creates a tamper-evident record of the model's origin.
In your model registry: Only accept signed models. Reject unsigned artifacts at ingestion, not at deployment. This prevents unsigned models from entering your supply chain in the first place.
In your deployment pipeline: Verify signatures before loading models into memory. This check should happen in your inference service's startup routine, not in a separate validation step you might skip under time pressure.
The OpenSSF specification supports this workflow. It defines how to sign models, what metadata to include, and how to verify signatures across different ML frameworks (PyTorch, TensorFlow, ONNX). You're not inventing a custom solution.
When Container Patterns DO Apply
The conventional wisdom isn't entirely wrong. Some software supply chain practices transfer directly to ML:
Version control works the same way. Your models belong in Git LFS or DVC, with the same branch protection and review requirements you apply to application code.
Access controls are identical. Role-based access to your model registry should mirror your container registry permissions. Data scientists need read access; only CI/CD pipelines should have write access.
Dependency scanning still matters. Your inference service runs on a base image with system libraries. Scan that image. The model itself might be opaque, but its runtime environment isn't.
These practices are necessary but not sufficient. A signed container image with a clean vulnerability scan is trustworthy. A signed ML model with a clean base image is trustworthy if you verify the signature. Skip that verification, and you're back to trusting an artifact you can't inspect.
The Real Question
You're already signing container images and verifying software provenance. Your SBOM generation is automated. Your artifact registry requires signatures.
Why are your ML models the exception?
The tooling exists. The specification is stable. Organizations are implementing this now, not planning pilots for next quarter. If you're deploying models to production without cryptographic verification of their integrity, you're accepting a risk you eliminated everywhere else in your software supply chain.
Model signing isn't a new security paradigm. It's applying the same integrity guarantees you already require, to artifacts that pose the same (or greater) supply chain risk as any other code you deploy.
