AI Supply Chain Security: Scanning ML Models and Dependencies in CI/CD

Poisoned models and hijacked packages are the new attack surface in your pipeline. Here is how to secure the AI supply chain end to end.

In March 2026, attackers slipped a malicious LiteLLM release onto PyPI, and that one poisoned dependency put an estimated 500,000 credentials at risk, among them provider keys for Meta, OpenAI, and Anthropic. AI supply chain security barely exists at most companies, and the most valuable secrets in modern engineering now flow through a pipeline secured the way it was in 2018. Meta reportedly froze part of its AI data work while it contained the fallout. The attacker did not breach a data center or crack encryption. They published a package, waited for automated dependency resolution to do the rest, and let normal pipelines pull the payload in.

That is the shape of every AI supply chain security failure in 2026. The pipeline is the weapon, and the ammunition is a model, a dataset, or an ML package that looks exactly like the thousands of legitimate artifacts your builds already trust. This guide is your reference for CI/CD security for AI: what the AI supply chain is, how it gets attacked, and the concrete controls, from AI dependency scanning to model signing, that turn a leaky build into a secure MLOps pipeline.

What AI supply chain security actually means

AI supply chain security is the practice of verifying the integrity and provenance of every external component that flows into an AI system, meaning the models, the training and fine tuning datasets, the ML frameworks, and the tools and agent skills the system depends on. It extends classic software supply chain security, which already covers your code dependencies, into AI software supply chain security, adding machine learning model security and the artifacts unique to ML that carry risks ordinary code scanners were never built to catch.

The distinction matters because a model file is not passive data. In the most common serialization format, loading a model executes code, which means "downloading a model" and "running an untrusted program" are the same action. Your existing dependency scanner reads a manifest and checks versions against a vulnerability database. It has no opinion about what happens when your training job deserializes a 4 gigabyte weight file, and that is exactly where the attacker lives.

Why the AI supply chain is a bigger blast radius

Three things make AI artifacts more dangerous than a typical package, and each one raises the stakes for a platform team.

The first is execution at load time. Python's pickle format, still the default storage mechanism for a large share of public models, allows arbitrary code execution the moment a file is deserialized, before a single inference runs. ReversingLabs, Rapid7, and others have documented backdoored PyTorch files on Hugging Face that download and run shell scripts or remote access trojans on load. Nearly half of widely used public models still rely on pickle, so the exposure is not an edge case.

A second factor is implicit trust at scale. Hugging Face hosts more than a million models under an open publishing model, with automated but admittedly incomplete vetting. Practitioners pull from it the way they pull from a package registry, and a name that looks official is usually trusted on sight. In May 2026 a repository called Open-OSS/privacy-filter reached the top trending spot with more than 244,000 downloads in 18 hours before anyone pulled it.

Speed is the third factor. The compromises of 2026 were not slow, persistent campaigns. The PyTorch Lightning package was malicious for 42 minutes. A hijacked Bitwarden CLI package on npm stayed live for 90 minutes, carrying a payload written to steal credentials from developer AI tools such as Claude Code, Cursor, Codex CLI, and Aider. A developer or a runner that pulls a dependency during that window gets the payload, the window closes, and the evidence is gone. Automated dependency resolution, the thing that makes pipelines fast, is also what makes these short windows so effective.

The five ways model repositories get weaponized

Researchers converge on five recurring attack patterns. Recognizing them is the first defensive step, because each one has a specific control.

The trust_remote_code pattern deserves a specific callout, because it needs no clever exploit at all. CVE-2026-6859 showed that InstructLab, a widely used training framework, hardcoded trust_remote_code=True in a training script. Any crafted model uploaded to Hugging Face could then achieve remote code execution on any affected installation that loaded it, with no pickle trick required. Treat trust_remote_code=True with the same severity as running an arbitrary binary from the internet, because that is precisely what it is.

The 2026 incidents that made this concrete

None of this is theoretical, and a short roll call makes the point. The LiteLLM PyPI compromise exposed an estimated half million credentials across major AI providers. The European Commission fell to attackers who poisoned Trivy, a widely used open source scanner, a reminder that even the tools meant to catch supply chain attacks can become the vector. In February 2026 the Koi Security team traced 341 malicious agent skills to the ClawHub registry, each carrying a stealer aimed at cryptocurrency tooling. The United States Department of Defense issued formal guidance on AI and machine learning supply chain risk in March 2026, the institutional signal that this has moved from research curiosity to national security concern.

The common thread across all of them is simple. Trust combined with automation creates attack surface, and AI pipelines run on both.

Want to practice securing an AI pipeline, not just read about it?

Wiring an ingestion gate, generating provenance you can actually verify, and breaking your own pipeline on purpose are skills you build by doing, not by reading a checklist. The DevSecOps learning path on KodeKloud walks through pipeline security, secrets handling, and supply chain controls in hands on labs, and the KodeKloud playgrounds give you throwaway Kubernetes and cloud environments where you can deploy a scanner, sign an artifact, and watch a gate reject an unsigned one, without touching anything in production.

Building an ingestion gate for models

The single highest value control is a gate between the outside world and your registry. No external model, dataset, or skill enters your trusted store until it passes. Nothing in your training or serving pipeline is allowed to pull directly from a public hub. The gate runs four checks in sequence, and a failure at any stage rejects the artifact.

1. Format policy. Prefer safetensors, which stores tensors as plain data with no code execution path. Where only a pickle version exists, it goes through scanning and manual review, or it does not enter at all.
2. Scanning. Run layered scanners rather than trusting one. This is AI model vulnerability scanning in practice: tools like modelscan and picklescan detect known malicious opcodes, but treat them as one signal, since picklescan itself has shipped bypass vulnerabilities and attackers actively compress payloads to evade it. Pair it with AI dependency scanning on the packages the model pulls in, because the weights and the requirements file are two separate attack surfaces.
3. Provenance verification. Confirm the artifact came from where it claims and has not been altered, by verifying a signature against a known key before you trust it.
4. Pinning. Record the exact revision hash, not a moving tag, so the version you reviewed is the version you load forever after.

A minimal gate step in a pipeline looks like this. It fetches by immutable revision, refuses pickle, scans, and only then promotes the artifact into the trusted registry.

#!/usr/bin/env bash
set -euo pipefail

MODEL_REPO="org/model-name"
REVISION="a1b2c3d4e5f6..."        # immutable commit hash, never a moving tag
WORKDIR="$(mktemp -d)"

# 1. Fetch the exact revision, disable any remote code execution.
export HF_HUB_DISABLE_TELEMETRY=1
python - <<PY
from huggingface_hub import snapshot_download
snapshot_download("$MODEL_REPO", revision="$REVISION",
                  local_dir="$WORKDIR", allow_patterns=["*.safetensors","*.json"])
PY

# 2. Reject pickle formats outright.
if find "$WORKDIR" -name '*.bin' -o -name '*.pt' -o -name '*.pkl' | grep -q .; then
  echo "REJECTED: pickle-format weights present"; exit 1
fi

# 3. Scan what remains.
modelscan -p "$WORKDIR" || { echo "REJECTED: scanner flagged the artifact"; exit 1; }

# 4. Verify the maintainer signature before trusting anything (see next section).
cosign verify-blob --key maintainer.pub \
  --signature "$WORKDIR/model.sig" "$WORKDIR/model.safetensors" \
  || { echo "REJECTED: signature verification failed"; exit 1; }

echo "PASSED: promoting $MODEL_REPO@$REVISION to the internal registry"

In your framework code, the corresponding setting is not optional.

from transformers import AutoModel

# trust_remote_code stays false. An allowlist is the only exception, and it is
# a list of specific reviewed repositories, never a blanket True.
model = AutoModel.from_pretrained(
    "org/model-name",
    revision="a1b2c3d4e5f6...",   # pin the hash you reviewed
    trust_remote_code=False,
)

Signing and provenance for the whole pipeline

Scanning tells you an artifact looks clean today. Signing and provenance handle AI model integrity verification: they tell you it is the artifact you approved and that it came from the build you expected. The two together are what turn "we hope this is safe" into "we can prove what shipped."

Three practices carry most of the weight, and none of them require a large security budget.

Generate a bill of materials at build time. An SBOM lists every component and version that actually resolved into your build, so when the next LiteLLM style disclosure lands you can answer "are we affected" in seconds rather than hours. Generate it from the resolved dependency tree at the moment of build, not from a manifest that lists version ranges, because the transitive tree is exactly where supply chain risk hides. CycloneDX handles security metadata and AI component attribution well, and it now describes machine learning components, so extend the same practice to your models and datasets rather than stopping at code.

Sign artifacts without managing keys. Signing is the core of AI artifact security: Sigstore and its cosign CLI let a build sign artifacts using its own workflow identity through OIDC, with the signature recorded in a public transparency log, so there are no long lived signing keys to steal. The Linux Foundation's model signing project applies the same approach to model files specifically.

# Sign a model artifact keylessly using the pipeline's OIDC identity.
cosign sign-blob --yes model.safetensors --output-signature model.sig

# Attach the SBOM to the artifact digest so the two cannot be separated.
cosign attest --predicate sbom.cdx.json --type cyclonedx "$IMAGE@$DIGEST"

Generate provenance and gate on it. SLSA, pronounced "salsa," defines graduated levels of build integrity, from provenance simply existing at Level 1 to tamper resistant provenance from a hardened build platform at Level 3. Most teams should target Level 2 or 3. Provenance is only useful if something checks it, so add a verification step to your deploy job or an admission controller that refuses to promote an artifact whose signature or provenance does not verify. Pin your GitHub Actions to commit SHAs rather than tags while you are here, because a compromised action is how attackers reach thousands of pipelines at once.

AI supply chain controls at a glance

Where to start

You do not need to build all of this at once, and trying to will stall the whole effort. These AI DevOps best practices stack, so move up one rung at a time.

1. Ban direct pulls from public hubs in training and serving code, and route everything through one internal registry.
2. Set trust_remote_code=False everywhere, then grep your codebase for any place it is true and justify or remove each one.
3. Add a scanning and safetensors check to the ingestion path, even if it starts as a manual step.
4. Pin every external model and package to an immutable revision or hash, not a moving tag.
5. Generate an SBOM at build time and store it keyed by artifact digest, so you can answer the next disclosure quickly.
6. Add signing with cosign, then add a verification gate to your deploy job so unsigned artifacts cannot promote. That final gate is what makes a secure AI deployment pipeline, where nothing ships unverified.

Conclusion

The AI supply chain has become the most direct way to attack an AI system, because it exploits the one thing every pipeline is built to do at speed: pull trusted components and run them. A model file that executes code on load, a package that is malicious for 42 minutes, a fake repository trending at number one, these are not exotic threats anymore, they are the documented baseline of 2026. The good news is that the defenses are mature and mostly free. Route external artifacts through a gate, prefer safetensors, pin by hash, keep trust_remote_code off, generate an SBOM, sign what you ship, and verify before you promote.

Start this week by finding every place your pipeline pulls a model or package directly from the internet, and put a gate in front of the first one. That single control, an artifact that must be scanned, pinned, and verified before it enters your registry, is what turns your pipeline from the attacker's delivery mechanism back into your own.

Ready to Secure the AI Supply Chain for Real?

Reading about pickle exploits is one thing. Standing up an ingestion gate, signing a model with Sigstore, generating provenance a deploy job will actually check, and watching that gate reject an unsigned artifact are different skills, and they are the ones that matter when a real disclosure lands. The DevSecOps learning path and the Certified Kubernetes Security Specialist (CKS) course on KodeKloud build exactly this muscle, with hands on labs in disposable environments where breaking your own pipeline costs nothing. Spin one up and gate your first model today.

FAQs