Supply-chain security for ML — SLSA, signing, and admission verification, end to end

The container-image supply chain has a mature toolchain: build provenance, cryptographic signatures, Software Bills of Materials, and admission-time verification are well-understood disciplines with production-grade tooling. Model artefacts are the unsolved half of the same problem. A trained model — a SafeTensors shard, an ONNX graph, a quantised checkpoint — flows from a training job through a model registry into an inference server that handles production traffic. Every link in that chain is a potential entry point for a tampered or unverified artefact.

This article closes that gap end to end. It maps the SLSA framework to the model lifecycle, shows what each tool in the signing and verification chain enforces, presents a concrete admission policy, and names the open problem of data-side provenance that the toolchain does not yet solve. It is a companion to article 30 (model-registry governance and lineage) in this series.

SLSA levels mapped to the model lifecycle

SLSA (Supply-chain Levels for Software Artefacts) is an OpenSSF framework that defines a graded set of provenance guarantees, from L1 (provenance exists) to L3 (hardened, tamper-resistant build platform). The full specification is published at slsa.dev/spec/v1.0/levels. The framework was designed for software build pipelines; the mapping to a model lifecycle is direct once you treat the training run as the build and the trained artefact as the package.

The table below applies each SLSA Build Level to the model-production chain:

L1 — Provenance exists. The training job records the dataset version, code commit, hyperparameters, and output artefact digest, typically as metadata in a model registry (e.g. MLflow). No signing required; the record can be tampered.

L2 — Signed provenance from a hosted build service. The provenance attestation is generated by the training platform (not the engineer) and cryptographically signed. Registry promotion is gated on a valid signature, so a verifier can establish what produced the artefact without trusting the person who pushed it. This is the practical target for most teams today.

L3 — Hardened, non-falsifiable build. Training runs in an isolated, tamper-resistant environment with a non-forgeable workload identity; provenance cannot be back-dated or forged by a malicious insider. Achievable but operationally heavier; worthwhile for foundation models that underpin many downstream services.

The SLSA L2 requirements specification (slsa.dev/spec/v1.0/requirements) requires that provenance be generated by the build platform itself, not by a build step the author controls, and that it be signed with an identity the verifier can check. These two constraints together are what lift L2 above L1: the signature makes the provenance non-repudiable, and the platform-generated constraint means it cannot be omitted by a developer who forgot to add the emit step.

in-toto attestations: the envelope that carries provenance

SLSA provenance predicates are carried inside in-toto attestations. The in-toto Attestation Framework specification (in-toto/attestation on GitHub) defines a four-layer structure: an outer Envelope (DSSE-signed), a Statement (subject + predicateType + predicate), and the Predicate payload itself. For SLSA provenance the predicate describes the builder identity, the build inputs (source digest, parameters), and the output subjects (the artefact digests).

Why this matters for model artefacts: the in-toto attestation is the artifact-agnostic wrapper that lets you attach the same provenance envelope whether the subject is a container image digest or a SafeTensors shard digest. The signing tool (Cosign) and the verification engine (the admission controller policy) operate on the envelope, not on the model format, which is why the same toolchain works across image and model surfaces.

The toolchain: what each component enforces

Four tools cover the chain end to end, and none meaningfully overlaps the others. Each owns one verification surface.

Signing and attestation: Cosign (Sigstore)

Cosign, a Sigstore project, signs artefacts and stores signatures and attestations alongside them in an OCI registry. The official documentation is at docs.sigstore.dev/cosign/signing/overview. Keyless signing issues a short-lived X.509 certificate against an OIDC identity (the workload's service account or CI identity), binds the public key to a Rekor transparency log entry, and then discards the key. The trust anchor is the workload identity, not a long-lived key stored in a secrets manager.

For model artefacts, two objects get signed: the serving image (standard container signing) and the model artefact digest together with its SLSA provenance attestation. If the training job also generates a Software Bill of Materials, that too is attached as a second attestation on the same OCI reference. Because Cosign operates on OCI registry APIs, it is runtime-agnostic — the same signing step applies whether the artefact later lands in a self-managed cluster or a managed cloud Kubernetes service.

SBOM generation: Syft or equivalent

Executive Order 14028 and its downstream NIST Special Publication 800-218 (the Secure Software Development Framework, SSDF v1.1) formalised SBOM requirements for software consumed by US federal agencies and, by adoption, for many regulated industries. The SSDF specification is at csrc.nist.gov/pubs/sp/800/218/final. For ML workloads, the meaningful SBOM covers the serving image (ML framework version, CUDA/cuDNN libraries, Python dependency tree) and, where tooling supports it, the declared dependencies of the model artefact itself.

Tools such as Syft (Anchore) produce SPDX or CycloneDX SBOMs from container images or filesystems. The SBOM is then signed and attached as a Cosign attestation, so it travels with the artefact and is verifiable at the admission gate. This is build-host tooling and is environment-agnostic.

Admission verification: Kyverno verifyImages

Kyverno's verifyImages rule is the policy engine that turns the signing chain into an enforced gate rather than an advisory one. The CNCF-graduated project documentation (main.kyverno.io — Sigstore verify images) shows keyless attestation verification with both ClusterImagePolicy and ClusterPolicy resources. At admission, the policy checks: (1) the serving image carries a valid Cosign signature from an expected OIDC identity; (2) a SLSA provenance attestation is present and its subject digest matches the image being admitted; (3) optionally, an SBOM attestation exists. A workload that fails any check is rejected before the pod is ever scheduled.

Alternatives to Kyverno for the admission step include the Sigstore policy-controller (a purpose-built admission webhook) and Gatekeeper (OPA-based). The Sigstore policy-controller documentation describes an opt-in, per-namespace model using ClusterImagePolicy resources; AND logic applies across policies, OR logic within authorities. The choice between these engines is operational — the SLSA enforcement contract is equivalent. Teams that want a single policy language across image and non-image resources often favour Kyverno; teams already invested in OPA for other policies often favour Gatekeeper.

The chain of custody, step by step

The following sequence represents an L2-conformant model promotion:

1. Training job (e.g. Argo Workflows or a comparable CI/CD engine)
   └─ emits SLSA provenance predicate: dataset hash, git SHA,
      hyperparameters, output artefact digest

2. Cosign signs the artefact digest + attaches provenance attestation
   └─ keyless OIDC identity = the training workload service account
   └─ Syft generates serving-image SBOM; signed + attached as attestation

3. Model registry (e.g. MLflow) — version registered
   └─ promotion to 'Production' stage gated on:
      valid Cosign signature + provenance attestation present

4. Registry-to-GitOps automation renders InferenceService manifest
   └─ manifest pinned to the signed digest; PR opened for human review

5. On merge, GitOps operator syncs manifest to cluster
   └─ Kyverno (or equivalent) verifies signature + provenance BEFORE pod admission
   └─ mismatch → admission rejected; model never serves

6. Signatures, SBOMs, attestations ingested into provenance graph
   └─ enables estate-wide queries: "which deployed models depend on package X?"

Steps 2 and 5 are the two enforcement points that make this L2 rather than L1: the signing step makes provenance non-repudiable, and the admission gate means the cluster refuses any artefact whose provenance does not verify. Everything between them is metadata plumbing.

Admission policy example: Kyverno verifyImages for a model-serving workload

The following ClusterPolicy admits an inference-serving Pod only if its image carries a valid Cosign signature and a SLSA v1 provenance attestation from the expected training-platform identity. Image registry path, issuer, and subject are placeholders — tune to your environment.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-model-serving-image
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: check-cosign-signature-and-provenance
      match:
        any:
          - resources:
              kinds:
                - Pod
              selector:
                # Match Pods managed by an InferenceService.
                # Use matchExpressions with Exists to avoid a value wildcard.
                matchExpressions:
                  - key: serving.kserve.io/inferenceservice
                    operator: Exists
      verifyImages:
        - imageReferences:
            - "registry.internal/models/*"
          attestors:
            - entries:
                - keyless:
                    issuer: "https://token.actions.internal/oidc"
                    subject: "training-platform@models.internal"
                    rekor:
                      url: "https://rekor.internal"
          attestations:
            - type: "https://slsa.dev/provenance/v1"
              attestors:
                - entries:
                    - keyless:
                        issuer: "https://token.actions.internal/oidc"
                        subject: "training-platform@models.internal"

A critical implementation note: the gate is only as strong as the identity it pins. A policy with a wildcard subject, or one that accepts any issuer, verifies that a signature exists but not whose — which defeats the L2 non-repudiation guarantee. Pin both the issuer (your OIDC provider endpoint) and the subject (the training workload identity) explicitly.

The same policy applies to a self-managed Kubernetes distribution and a managed cloud Kubernetes service without modification: Kyverno operates as a standard admission webhook, and that webhook contract is stable across Kubernetes distributions.

Threat model: what this chain defeats and what it does not

MITRE ATLAS catalogs AI Supply Chain Compromise as an explicit attack technique against ML systems (atlas.mitre.org). OWASP LLM Top 10 2025 positions supply chain as LLM03, explicitly calling out model provenance, dependency integrity, LoRA adapter attacks, and pre-trained model tampering (genai.owasp.org LLM03:2025). The chain described above directly addresses these: an unsigned or tampered model artefact is blocked at admission; a model whose provenance attestation does not match the registered training run is rejected at registry promotion.

The chain defeats the following classes of threat:

• Post-training tampering: an artefact modified after signing fails signature verification at the admission gate.
• Provenance spoofing: because SLSA L2 requires the platform to generate provenance (not the engineer), a developer cannot fabricate a clean-looking attestation for a model trained from a poisoned dataset — the workload identity is pinned.
• Rogue promotion: a model that bypasses the evaluation gate cannot reach Production in the registry without a valid, platform-issued provenance signature.
• Dependency-level vulnerabilities: the SBOM attestation, combined with a vulnerability scanner consuming SPDX or CycloneDX, surfaces CVEs in serving-image dependencies before or after deploy.

The open problem: data-side provenance

The toolchain above establishes artefact integrity (was this blob modified after signing?) and build provenance (which training run produced this artefact?). It does not establish dataset provenance: what data was the model actually trained on, and can that claim be independently verified?

NIST AI 600-1 (the NIST Generative AI Profile, July 2024) identifies the absence of provenance records for third-party training data as a material gap, calling for traceability of data used in training (airc.nist.gov/Docs/1). OWASP LLM03:2025 similarly identifies lack of dataset provenance verification as a top supply-chain risk (genai.owasp.org LLM03:2025). As of 2025, no production-grade standardised mechanism exists for third-party verifiers to independently confirm dataset provenance for published model weights. The SLSA and in-toto specifications do not yet cover this surface; it remains an open research and standards problem.

The practical implication: for models sourced from external repositories (public model hubs), signing and provenance verification establish only that the artefact has not been modified since it was published, not that the original training process was trustworthy. Platform teams should pair external models with evaluation gates that test for known backdoor patterns and licence compliance, but they should not treat a valid Cosign signature as a data-safety guarantee.

SBOM scope for ML: what to include and what tooling cannot yet reach

An SBOM for an ML serving workload has two layers. The first is well-supported by existing tools: the container image SBOM captures the operating system packages, ML framework (PyTorch, TensorFlow, JAX), CUDA runtime, and Python dependency tree in a machine-readable format (SPDX 2.3 or CycloneDX 1.5). This layer integrates directly with vulnerability scanners and licence-compliance tools.

The second layer — a bill of materials for the model weights themselves (training data sources, upstream foundation models, fine-tuning datasets, adapter layers) — has no broadly-adopted standard format. Model cards in the Mitchell et al. tradition capture this information in human-readable form, but they are not machine-verifiable in the way an SPDX document is. Some teams are experimenting with CycloneDX ML extensions and with custom in-toto predicates to express model-specific provenance claims, but neither has reached the maturity of the image-SBOM toolchain.

The actionable guidance for platform teams today: mandate image-layer SBOMs (tooling is mature, gate-able at admission) and enforce model-card presence with a minimum required field set (intended use, training data provenance claims, evaluation scores, known limitations, licence). The model-card check is a registry-gate concern, not an admission-controller concern — it belongs in the registry promotion workflow described in the companion article on model-registry governance.

Licence compliance as a supply-chain concern

Licence compliance is the supply-chain concern that most platform teams handle last and regret earliest. Most public model weights carry licences that restrict commercial use, derivative works, or specific deployment patterns. A model published under a non-commercial research licence that makes it into a production inference service without licence review is a legal supply-chain failure, not just a governance failure.

Integrate licence scanning as a gate in the model curation flow, upstream of the registry-promotion signing step. The check is simple: the model card's declared licence must appear on an approved-licence allowlist maintained by your legal and security teams. A model with an unknown or unapproved licence must not be promotable to Production regardless of its evaluation scores. The SBOM toolchain can surface dependency licences for the serving image; the model-card licence field handles the weight-layer licence claim.

Common pitfalls

• Signing but not verifying at admission. Teams that add Cosign signing to their CI pipeline but do not install an admission controller with a verifyImages policy have a paper supply chain: artefacts are signed, but nothing enforces the signature at deploy time.
• Wildcard identity policies. A verifyImages rule that accepts any OIDC issuer or any subject verifies existence of a signature, not its provenance — any actor who can push to the registry can sign. Always pin issuer and subject to the training workload identity.
• Conflating signing with safety. A cryptographic signature establishes integrity and provenance; it does not establish that the model is free of backdoors, biases, or a poisoned training set. The evaluation gate in the model registry is a separate control that must sit alongside the signing gate, not be replaced by it.
• Skipping LoRA and adapter artefacts. OWASP LLM03:2025 explicitly calls out adapter attacks — a malicious LoRA adapter applied to a clean base model is a supply-chain attack. Adapters pushed to a model registry must be subject to the same signing and provenance requirements as base models.
• Audit log gaps. Signatures and SBOMs stored only in the OCI registry are lost if the registry is rebuilt. Push signatures and attestations to a separate transparency log (Rekor, or a self-hosted equivalent) and retain them independently of the registry lifecycle.

References

1. SLSA Specification v1.0 — Security Levels. OpenSSF / SLSA community, 2023. slsa.dev/spec/v1.0/levels
2. SLSA Specification v1.0 — Build Requirements. OpenSSF / SLSA community, 2023. slsa.dev/spec/v1.0/requirements
3. in-toto Attestation Framework Specification. in-toto project (Linux Foundation / CNCF). github.com/in-toto/attestation
4. Sigstore Cosign — Signing Overview. Sigstore project (OpenSSF). docs.sigstore.dev/cosign/signing/overview
5. Sigstore Policy Controller — Overview. Sigstore project (OpenSSF). docs.sigstore.dev/policy-controller/overview
6. Kyverno — Verify Images (Sigstore/Cosign). Kyverno project (CNCF). main.kyverno.io — verify-images/sigstore
7. NIST SP 800-218 — Secure Software Development Framework (SSDF) v1.1. NIST CSRC, February 2022. csrc.nist.gov/pubs/sp/800/218/final
8. MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems. The MITRE Corporation. atlas.mitre.org
9. OWASP LLM03:2025 — Supply Chain. OWASP Gen AI Security Project, 2025. genai.owasp.org/llmrisk/llm032025-supply-chain
10. NIST AI 600-1 — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST, July 2024. (The GenAI-specific companion profile to the base AI RMF, NIST AI 100-1 (2023). The two documents are distinct: AI 100-1 is the base framework; AI 600-1 is the generative AI profile.) airc.nist.gov/Docs/1