Cryptographic Signing for AI Models: A Missing Layer in MLSecOps

AI supply chain vulnerabilities has now landed a solid No 3 on the 2025 OWASP Top 10 for LLMs.

As AI adoption grows, development teams are increasingly pulling in third-party models from public repositories like HuggingFace and integrating them into their MLOps or application development pipelines. However, this convenience opens the door to critical supply chain vulnerabilities:

• Malicious executables embedded in model binaries

• Architectural backdoors designed to bypass validation and stay dormant, until a trigger input comes in.

• Poisoned models, retrained with adversarial data and repackaged as seemingly legitimate artifacts

These threats highlight the need for a defense-in-depth approach — one that goes beyond just runtime anomaly detection or static scans.

Picture from OpenSSF showing supply chain compromises

🔐 Enter Model Signing

While companies like Protect AI and HiddenLayer are introducing model scanning tools to MLSecOps toolchains, another important defense in depth security measure is cryptographic signing of models and datasets. This ensures the integrity and provenance of artifacts before they’re introduced into sensitive workloads.

Unfortunately, most open-source model platforms — HuggingFace included — currently lack signature requirements. Likewise, Model Cards (the documentation format for models) do not mandate cryptographic signature fields, leaving a critical gap in trust and verification.

🧰 The OpenSSF Response: A Model-Signing Project

The OpenSSF AI/ML Working Group has launched v1.0 of its model-signing project, aiming to fill this gap. Their goals include releasing:

• A standard signing and verification library

• A CLI tool for developers and MLOps engineers

• An extensible model card metadata format

This mirrors how traditional firmware and software are signed, where cryptographic metadata is tightly bound to the payload and used for secure validation downstream.

🧰 Traditional code signing approach

In traditional embedded FW/ SW code signing, it is important to include the proper metadata to the main to-be-signed payloads (traditionally code, and here model artifacts), so the verifying platform is able to check the meta data for attributes such as software version, the target platform, and so on. 

More sophisticated system where there are multiple players in the product life cycle (say a chip vendor producing a network card that goes inside a server) might add their own signatures along the way to provide assertion on their ownship on stage the product is in its lifecycle. 

🧱 Building Verifiable AI Supply Chains

The OpenSSF project adopts the concept of a verifiable chain of custody for model artifacts. It also expands the Model Card MetaData format to include both required and optional metadata fields, such as:

🔹 Mandatory high-level info:

• Name, developer, version, publisher, and description

🔹 Optional contextual info:

• Intended/unintended use, input/output types, supported languages

🔹 Technical model info:

• File format, architecture, model parameters, license

🔹 Training metadata:

• Training methodology, datasets, performance metrics
  (Surprisingly, only the training data license is optional)

🔹 Transparency & Security:

• Certificate info, encryption techniques, and model signatures — currently marked as optional

• Sensitive data handling practices and security considerations — mandatory

It’s encouraging to see that many fields are required, but it raises a question:

Why are fields like certificate data and cryptographic signatures still optional?

🧠 Challenges Unique to AI Model Signing

The OpenSSF group highlights several challenges when adapting traditional software signing practices to large-scale AI artifacts:

1. Size and computational cost
   Signing a large model (hundreds of GBs) is far more expensive than signing a firmware binary (~10s of MB). Verification is equally taxing.

2. Lack of delta update support
   Unlike embedded systems that support incremental signing (e.g., via dm-verity or Android Verified Boot), a initial model signing might still rely on whole-artifact signing — inefficient for frequent updates.

3. Download and memory constraints
   Current approaches require downloading and verifying the entire model, even if only a specific layer or module is needed for inference.

4. Distributed development
   Large models are often composed by multiple teams working on different components. This makes single-blob signing logistically complex.
   However, the alternative — per-component signing — introduces verification complexity, especially for constrained devices.
   Verifiers must:

• Process multiple cryptographic operations

• Maintain inter-component compatibility and integrity

• Handle component dependency graphs to preserve inference validity

  The author experience with traditional code signing is that, this is also a common theme that if not managed carefully a platform may have to verify multiple signatures on multiple components. In a constrained environment that have a hard time dealing with expensive cryptographic signature operations can cause performance delays due to having to handle multiple expensive signature as part of a single software load and boot process.  

5. The working group rightly is looking at component signing but notes the risk:
   “Component-level signing may jeopardize compatibility and context between model parts after verification.”
   
   

🧩 What Comes Next?

This first release of the OpenSSF model-signing standard is a major step forward. But we need to keep pushing:

• Model hubs must enforce signature verification at ingestion and download

• Model cards should require cryptographic metadata fields

• The ecosystem needs incremental verification approaches that scale with model complexity

Model signing is not just a best practice — it’s quickly becoming a non-negotiable control in AI supply chains.

If you're building MLSecOps pipelines or responsible for AI platform security, now’s the time to start experimenting with these new tools and standards.