Supply Chain Integrity for AI Model Artifacts With SLSA

The AI supply chain is training datasets, pre-trained weights, fine-tuning corpora, evaluation benchmarks, intermediate checkpoints, and the deployment infrastructure that serves the final model. Each of those is its own artifact class with its own way of breaking. That matters because most organizations still treat "the model" as a single object to secure, when in practice it is a chain of distinct, independently-compromisable stages. This piece maps SLSA, the supply chain security framework built for code, onto that chain, and shows where the mapping holds and where it needs real adaptation.

The numbers underneath this problem are not small. Black Kite's 2026 Supply Chain Vulnerability Report found AI-related CVEs hit 2,130 in 2025, a jump of 34.6% over the year before and more than 200% since 2023 Black Kite 2026 Supply Chain Vulnerability Report. Glacis puts the share of AI projects carrying at least one vulnerable dependency at 97%, with supply chain attacks tripling year over year and more than 10,000 malicious packages now sitting on PyPI specifically to target ML developers GLACIS AI Supply Chain Security Guide IOActive Security Challenges in AI Adoption 2026. A 2025 IOActive survey found 97% of organizations reported at least one supply chain breach that year, a 20% rise from 2024 GLACIS AI Supply Chain Security Guide IOActive Security Challenges in AI Adoption 2026. OWASP took notice too: its LLM Top 10 for 2025 moved supply chain vulnerabilities from fifth place up to the third slot (LLM03), which is the security community's way of saying this is no longer a secondary concern.

Why does AI break the old assumptions so badly? Traditional software supply chain security assumes a build either works or it doesn't, and a compromise usually announces itself as a crash or an error. AI systems don't cooperate that way. They carry undeclared behavioral couplings between components, they degrade quietly instead of failing loudly, and their lineage is multi-parent, non-deterministic, and often stitched together across organizations that never coordinate with each other. So the question is not whether AI supply chains need the kind of discipline SLSA brought to software builds. The question is whether SLSA, as written, can hold that weight. The reference AI stack measurement finds that 48 production-grade open-source projects declare 4,664 direct dependencies, resolve to 11,508 transitive packages, and total roughly 392M lines of code, the scale practitioners are actually managing, per the KTH paper "The Grand Software Supply Chain of AI Systems".

AI Supply Chain Attacks: Four Concrete Incident Patterns

Frameworks are easier to take seriously once the failure mode is concrete. Four incident patterns from the last two years show what's happening in production https://openssf.org/press-release/2023/04/19/openssf-announces-slsa-version-1-0-release/.

The first is serialization abuse. In February 2025, researchers found malicious ML models sitting on Hugging Face, which by April 2026 was hosting 2.7 million models, exploiting deliberately "broken" pickle files to slip past Picklescan detection ArXiv Model Transparency Paper. The trick was compressing the payload with 7z instead of PyTorch's default ZIP format, which let reverse shells connect out to hard-coded IP addresses undetected ArXiv Model Transparency Paper. Researchers named the campaign "nullifAI," a clean example of a file format doing what it was designed to do while still carrying a backdoor.

The second pattern appeared in Rapid7's July 2025 investigation into weaponized .pth files sitting on trusted model-hosting platforms. These files embedded backdoors that triggered on load, pulling down remote access trojans. One case used a Go-based ELF binary that reached out to a command-and-control server hidden behind a Cloudflare Tunnel, a level of infrastructure discipline that suggests this wasn't a hobbyist operation.

Third: Lambda layer injection. Lambda layers that lean on Python's marshal module for serialization sit exposed to the same deserialization execution path that makes Pickle dangerous, and this vector is easy to miss precisely because it lives inside user-defined model layer code rather than somewhere a security scanner would automatically look.

Fourth, and maybe the most instructive: compromised toolchains poisoning things downstream. The TeamPCP campaign broke into the Trivy scanner, then used that foothold to publish malicious versions of the LiteLLM AI gateway on PyPI, with potential exposure mapped to more than 2,100 organizations Reflectiz AI Supply Chain Blog. Around the same period, the Keyv npm worm (August 2026) poisoned at least 868 packages and planted persistence hooks aimed specifically at AI coding agents Reflectiz AI Supply Chain Blog. Both passed standard provenance and signature checks before anyone caught them, according to Reflectiz Reflectiz AI Supply Chain Blog. Training data attacks round this out: 2025 research found organizations already victimized by data poisoning, alongside model inversion, membership inference, and training data extraction attacks, all of which can leak sensitive information without ever tripping a runtime error.

What ties these four together? None of them are catchable at the moment of use without provenance established beforehand. The artifact looks fine because there's no signed record of what it was supposed to be built from, so there's nothing to check it against. IBM's 2025 data puts the average breach identification window at 276 days, and that window only widens when what's compromised is a model quietly behaving worse rather than a service visibly crashing Reflectiz AI Supply Chain Blog. The gap here is provenance, and SLSA is the framework the software world already built to close it for code. Whether it transfers cleanly to models is the real question.

What SLSA specifies and its levels in practice

SLSA, Supply-chain Levels for Software Artifacts, pronounced "salsa," is an OpenSSF project that's been vendor-neutral since Google contributed it in 2021. It didn't start as an open standard, though: it's based on Google's internal Binary Authorization for Borg system, which had been mandatory across all of Google's production workloads for more than eight years before the framework went public. That pedigree matters, since this isn't a theoretical model but a distillation of something that ran at enormous scale before anyone outside Google ever saw it.

The current version is v1.2, approved in November 2025, and it replaced the original v0.1 back in April 2023 with v1.0. The headline change in v1.2 is that the Source track, previously experimental, is now fully approved. The newly-approved Source track adds its own Level 3, which covers branch protection, mandatory code review, and safeguards against anyone tampering with source history after the fact.

SLSA's scope isn't limited to the build step itself. The project defines five stages across the software development lifecycle, Source, Build, Verification, Publication, and Use, and a real implementation is expected to address all five, including the ones that don't produce a binary. What provenance actually records, at its core, is who built something, what inputs went into it, and what process produced it, and the entire integrity check comes down to comparing that expected record against what actually happened. On the tooling side, this is already fairly mature for code: slsa-github-generator produces and manages provenance through GitHub Actions, slsa-verifier checks it, GitHub Artifact Attestations give you SLSA v1.0 Build L2 without extra setup, and npm's trusted publishing auto-generates its own provenance attestations.

None of this exists in a regulatory vacuum, either. The EU's Cyber Resilience Act starts imposing reporting obligations in September 2026, NIS2 has already raised the floor for supply chain oversight across critical infrastructure since October 2024, and DORA has applied to the financial sector since January 17, 2025. None of these explicitly name SLSA. Checkmarx's analysis found that organizations that already have strong provenance and build integrity in place are simply better positioned when the audits and procurement questions arrive. And the underlying problem SLSA addresses isn't manufactured urgency: Sonatype research found software supply chain attacks rose 742% between 2019 and 2022, and SolarWinds remains the reference case, a single tampered build compromising more than 18,000 organizations Practical DevSecOps SLSA Framework Guide. SLSA was built to answer exactly that kind of failure. Whether its assumptions hold for a trained model instead of a compiled binary is a separate question, and not a simple one. At L2, provenance is signed by a hosted build platform, so forging it requires an explicit attack rather than a mere configuration error. At L3, the build platform has strong tamper-resistance, builds are isolated from one another, and signing keys are inaccessible to user-defined build steps.

SLSA's broken assumptions for model weights, datasets, and checkpoints

SLSA leans hardest on the assumption that builds are reproducible, so a hash tells you something true. Re-run the same build from the same source, get the same bytes, and a mismatch means tampering. Trained AI artifacts don't work this way, which is a crack in the floor of the whole verification model.

A KTH paper formalizes this into four distinct structural gaps. Versioning is the first: behavioral couplings, an adapter tied to a specific base model, a retrieval index tied to a specific embedding model, a prompt template tied to a specific output format, mostly go undeclared, with no resolver anywhere tracking which version depends on which. An API provider can rewrite the model actually being served behind an endpoint with no version selector telling anyone it happened. Observability is the second gap: AI systems tend to degrade quietly rather than announce failure, and telemetry built around latency and error rates has no mechanism for tracing a behavioral shift back to a supply chain cause. Traceability is the third: lineage in AI systems is multi-parent, non-deterministic, and frequently cross-organizational, and neither SLSA nor in-toto, its close cousin, has a data model that can represent a graph shaped like that.

Dataset provenance compounds the problem rather than sitting neatly beside it. A single fine-tuning dataset might trace back through a base corpus, a filtering pipeline, a deduplication pass, and a round of human annotation, and each of those is its own artifact with its own provenance chain, which SLSA's single-artifact model was never built to compose. Add in the fact that intermediate checkpoints are both outputs of one training stage and inputs to the next, and the chain isn't linear anymore, it's recursive. The S3C2 Summit dug into this exact territory in September 2025, where participants flagged the need to record training data provenance, maintain consistent hashes, and capture inference-time provenance, none of which current SLSA tooling handles out of the box.

There's also an identity problem baked into Level 3 specifically. SLSA L3 requires signing keys to stay out of reach of user-defined build steps, but training pipelines routinely blur that boundary, since user-controlled training scripts often look indistinguishable from the infrastructure layer itself. Enforcing that isolation in a research training environment, where data scientists are running custom scripts against shared infrastructure, is a genuinely harder problem than enforcing it in a CI/CD pipeline compiling code. None of this disqualifies SLSA from being useful here. It does mean applying it to models requires deliberate adaptation rather than a straight copy-paste, and that adaptation is already underway. The KTH paper describes the core assumption mismatch: SLSA's hash-verification model presupposes reproducible builds, yet trained artifacts cannot be reproduced bit-for-bit due to hardware non-determinism, so a hash mismatch reveals nothing about whether a checkpoint was produced by the procedure its attestation describes. These gaps are real but not disqualifying, and the sigstore/model-transparency project and OpenSSF Model Signing work show a practical path for adapting SLSA's provenance mechanisms to model artifacts.

How the sigstore/model-transparency project adapts SLSA provenance for ML

The sigstore/model-transparency project sets out to prove something specific: that the same protections built for signing and verifying code can be extended to ML models, so that anyone downloading a model can check its provenance, and any serving pipeline can validate that provenance before putting the model into production. It's framed as a proof of concept, not a finished product, which is an honest way to describe where model-signing infrastructure currently stands.

The effort behind it is a genuine coalition: Google's Open Source Security Team, OpenSSF, NVIDIA, and HiddenLayer spent roughly a year bringing Sigstore's signing model over to ML, and the output is the OpenSSF Model Signing (OMS) specification, now positioned as an industry standard for signing AI models. It's already landed in places that matter.

The mechanics map fairly directly onto familiar SLSA concepts. During training, the workflow connects to the Sigstore Certificate Authority and gets back a short-lived certificate tied to an OpenID Connect token, which in turn identifies the specific workload or developer behind the run. That certificate is only valid long enough to sign one model, which narrows the window for anyone trying to abuse it. The signature and certificate then get written into a Sigstore transparency log, which closes off a specific insider threat: nobody can quietly release a model dressed up as company-signed work, because the log would show it. When the model finally gets uploaded to storage, the certificate and its proof of inclusion in that log travel with it.

Verification isn't a one-time check either. The specification calls for validation at three separate points: when the model lands on a model hub, when it's selected for deployment (whether embedded locally or served through a remote API), and when it's reused as an intermediary in another training run. That third checkpoint is easy to overlook but arguably the most important, since it's exactly where a compromised checkpoint would otherwise propagate silently into a whole new generation of models. There's a practical payoff beyond pure integrity, too: with provenance in hand, users can quickly figure out whether a model needs retraining because it was built against a vulnerable version of some dependency, without having to guess. GUAC integration is on the roadmap next, aimed at generating AI-BOMs and supporting supply chain inspection during incident response.

Translated into SLSA's own vocabulary, this signing workflow is roughly at the boundary between Level 2 and Level 3 https://openssf.org/press-release/2023/04/19/openssf-announces-slsa-version-1-0-release/. Signing the weights is a real and necessary step, but not the whole picture, because a signature only tells you the artifact wasn't tampered with after signing; it says nothing about what's actually inside it. OMS is integrated into major model hubs, including NVIDIA's NGC and Google's Kaggle, per the OpenSSF blog. In SLSA terms, the signing workflow with a hosted CA and transparency log corresponds to the L2→L3 boundary (provenance is signed by an external authority, and the certificate's short lifetime approximates the key isolation L3 requires), though full L3 certification depends on platform isolation guarantees that training infrastructure must separately provide.

AIBOM as the inventory layer that provenance attestations require

Existing SBOM standards, SPDX and CycloneDX chief among them, were built for traditional software, and they simply don't have a way to represent AI-specific artifacts. Datasets, trained models, fine-tuned checkpoints, and data pipelines don't fit into their schemas, which is not a minor omission. That means an organization can have a fully signed, fully attested model artifact and still have no structured record of what actually went into it.

AIBOM is the answer being built to that gap: an extension to the SPDX 3.0 standard, submitted formally as ISO/IEC DIS 5962 to replace the older ISO/IEC 5962:2021, developed through a genuinely global, multi-stakeholder process involving 90 contributors working through structured action-research cycles and validated against both the EU AI Act and the IEEE 7000 series Building an Open AIBOM Standard in the Wild. The extension itself adds 36 new fields, and what those fields do, collectively, is treat datasets and models and their provenance chains as first-class citizens of the supply chain record, rather than as afterthoughts bolted onto a software bill of materials that was never designed for them Building an Open AIBOM Standard in the Wild.

Why does this matter specifically for SLSA? Because SLSA provenance answers one question: was this artifact built the way its attestation says it was built, and from the inputs it claims. It says nothing about what the artifact is actually made of. AIBOM gives a provenance consumer the inventory they need to understand what, exactly, got signed. It captures things that have no real equivalent in a traditional SBOM: training dataset lineage, the identity of a specific fine-tuning checkpoint, references back to a model card, versions of the data pipeline that produced a given input. Each of those is a distinct attack surface, and none of them show up if all you're checking is a signature.

The regulatory alignment isn't incidental, either. AIBOM was validated against the EU AI Act and IEEE 7000 series from the outset, the same regulatory pressure already pushing SLSA adoption in traditional software. Put simply, SLSA provenance answers "was this built as claimed," and AIBOM answers "what is this actually made of," and together they give a downstream consumer what they need to make a real trust decision at each of SLSA's five lifecycle stages, Source, Build, Verification, Publication, and Use. Neither one substitutes for the other. It's tempting to treat signing as the finish line. It isn't: a cleanly signed model built from a poisoned dataset is still a poisoned model, just one with a valid signature attached to it. With the framework components identified, the question practitioners actually face is sequencing, namely which SLSA levels to target first, what to instrument now, and what to defer.

A practical mapping of SLSA levels onto AI artifact pipeline stages

It's a question of sequencing: what to build first, what to defer, and which level of assurance actually matches the risk at each stage of the pipeline.

SLSA was designed from the start for incremental adoption. The Level progression carries over to AI artifacts, with adjustments at each stage rather than a one-to-one copy.

Take training data as the first stage. It won't stop a determined adversary, but it will catch accidental substitution, which covers more incidents than people tend to assume. Extending signing to the datasets that produced models, following the OpenSSF Model Signing (OMS) specification developed by GOSST, OpenSSF, NVIDIA, and HiddenLayer, is probably the highest-leverage step available to a team that hasn't started any of this yet. It reuses infrastructure that already exists rather than requiring something built from nothing, and it closes the gap between "the model is signed" and "the data behind the model is accounted for," which, as the incident patterns above show, is exactly where several real-world compromises have gotten through undetected.

Reaching for it prematurely, before the manifest and signing groundwork exists, tends to produce compliance theater rather than real assurance. The frameworks are still being written in public: at the S3C2 Summit in September 2025, participants discussed the need to record the source of training data, maintain hashes, and capture inference-time provenance, none of which existing SLSA tooling addresses out of the box, and that's not a reason to wait. It's a reason to start with what already works (manifests, hashes, signed provenance on weights) and build toward the harder isolation guarantees once that foundation is actually load-bearing. SLSA is designed to be adopted incrementally, with L1 achievable through minimal tooling investment and L3 requiring platform-level guarantees, and the same progression applies to AI artifacts, with some stage-specific adaptations. Stage 1 covers training data, addressing what SLSA maps to and what must be adapted. At the L2 equivalent, the dataset manifest is signed using a hosted identity (Sig.