AI supply chain security, the 2026 working playbook.

What is AI supply chain security?

AI supply chain security extends traditional software supply chain security to encompass AI-specific components: training datasets, pre-trained models, fine-tuning data, evaluation benchmarks, and model deployment infrastructure. While traditional supply chains track code dependencies, AI supply chains must also track data lineage, model provenance, and computational resources.

The AI attack surface

AI systems introduce attack surfaces that don’t exist in traditional software:

• Data poisoning: Attackers inject malicious examples into training data, causing models to learn backdoors or biases
• Model poisoning: Pre-trained models from repositories like Hugging Face contain embedded backdoors
• Dependency confusion: ML-specific packages on PyPI, conda, npm targeted with typosquatting and malicious uploads
• Provenance attacks: Models and datasets with falsified origins or licensing claims

The complexity stems from AI’s multi-layered supply chain. A single deployed model might depend on a base model from Hugging Face, fine-tuning data scraped from the web, Python packages from PyPI, CUDA libraries from NVIDIA, and cloud infrastructure from AWS. Each of those is a potential compromise point.

The AI supply chain

Understanding the AI supply chain requires mapping dependencies across five distinct layers:

Each layer creates dependencies that must be tracked, verified, and monitored. Treat the deployed graph as the unit of review rather than a repository-wide average, and record both affected components and compensating controls.

Attack vectors in AI supply chains

AI supply chain attacks exploit trust relationships and opacity in the ML development process. Here are the primary attack vectors documented in the wild:

1. Model Poisoning

Attackers distribute pre-trained models containing backdoors that activate on specific triggers. These attacks are particularly insidious because:

• Models are large binary files that can’t be easily code-reviewed
• Backdoors can be embedded in ways that don’t affect normal performance
• Detection requires specialized testing on trigger patterns
• Organizations rarely verify model provenance beyond “it’s from Hugging Face”

2. Dependency Confusion & Typosquatting

ML developers rely heavily on package managers like PyPI and conda. Attackers exploit this through:

• Typosquatting: Registering packages with names similar to popular libraries (e.g., ”torch” vs “pytorch-torch”)
• Dependency confusion: Uploading malicious packages with identical names to internal packages
• Malicious updates: Compromising legitimate package maintainer accounts

Public package repositories have repeatedly been used for typosquatting, dependency-confusion, and malicious-update campaigns. AI teams should treat package names and popularity as discovery signals, not proof of provenance or safety.

3. Data Poisoning

Training data poisoning targets the datasets used to train or fine-tune models. Attack methods include:

• Injecting mislabeled examples that degrade model performance on specific inputs
• Contributing poisoned samples to open datasets (Common Crawl, LAION-5B)
• Manipulating web content that gets scraped into training corpora
• Exploiting user-generated content in fine-tuning pipelines

Data poisoning is particularly effective because organizations rarely verify provenance of training data, and detecting poisoned samples requires knowing what to look for.

4. Model Repository Compromise

Platforms like Hugging Face host hundreds of thousands of models. Security risks include:

• Malicious pickle files in model checkpoints (pickle deserialization = arbitrary code execution)
• Models claiming to be one architecture while actually being another
• Falsified model cards and evaluation metrics
• License washing (commercial models redistributed as open source)

Model repositories can expose security metadata and scanning signals, but those signals do not replace the deployer’s own provenance checks, safe-loading controls, dependency review, and acceptance criteria.

Data supply chain risks

Training data represents a critical attack surface because it directly shapes model behavior. Key risks:

Data provenance challenges

Most AI teams cannot answer basic provenance questions about their training data:

• Where did each training example originate?
• Who labeled or annotated the data?
• What transformations or filtering were applied?
• What is the licensing status of source material?
• When was the data collected and is it still valid?

For covered high-risk systems, EU AI Act Article 10 requires data-governance and management practices that address, where appropriate, data origin and collection processes. Data-lineage capabilities may support that work, but no single lineage tool or artifact establishes compliance.^[8]

Third-party dataset risks

Popular datasets like ImageNet, Common Crawl, and LAION face ongoing security and compliance concerns:

• Data poisoning: Malicious actors contributing samples to open datasets
• Copyright infringement: Datasets containing copyrighted material without license
• Privacy violations: Personal data scraped without consent (LAION-5B removed after privacy complaints)
• Bias and representation: Systematic over/under-representation of demographic groups

Web scraping provenance

Many foundation models train on web-scraped data (Common Crawl, C4, The Pile). This creates provenance challenges:

• No ability to verify individual web pages weren’t tampered with
• Scraped content may contain adversarially-placed poisoning examples
• Legal status unclear (ongoing litigation against OpenAI, Meta, Stability AI)
• No mechanism to remove or update training data post-scraping

Model supply chain risks

Pre-trained models have become infrastructure for modern AI. Public model hubs hold large, fast-changing catalogs, so one compromised or misrepresented artefact can be reused across many downstream systems. Catalogue size and download counts change continuously; the durable control is provenance for the exact artefact deployed.

Pre-trained model risks

Hugging Face security features

Hugging Face has implemented several security controls, but adoption is inconsistent:

• Pickle scanning: Automated scanning for malicious pickle files (but can be bypassed)
• Malware scanning: ClamAV scanning of uploaded files
• Model signing: Optional GPG signatures for model verification (low adoption)
• Security reporting: Vulnerability disclosure program

Despite these features, model signature verification remains rare on public repositories, with most downloads occurring without cryptographic verification. Few organizations perform local security scanning before deployment.^[9]

Fine-tuning attack vectors

Even when starting with a trusted base model, fine-tuning introduces risks:

• Fine-tuning data poisoning (injecting backdoor triggers during fine-tuning)
• Parameter extraction attacks (fine-tuning to extract training data from base model)
• License violations (fine-tuning non-commercial models for commercial use)
• Drift from safety alignment (fine-tuning removing safety controls from base model)

Software supply chain risks

AI projects depend on complex software stacks spanning ML frameworks, data processing libraries, and deployment tools. Each dependency represents potential compromise.

The ML dependency problem

A useful dependency review answers four questions:

• Which direct and transitive dependencies are present?
• Which versions and integrity hashes were approved?
• Which known vulnerabilities affect the deployed path?
• Who owns patching, rollback, and exception decisions?

The number of dependencies is not itself a risk score. What matters is whether the deployed dependency graph is known, versioned, reviewed, and recoverable.

PyPI package ecosystem risks

PyPI is a large public package ecosystem whose account, publishing, provenance, and malware defenses continue to evolve. Repository controls reduce risk but do not establish that a dependency is appropriate for your deployment; pin, verify, scan, and monitor the exact artefacts you use.

Documented package-ecosystem attacks use techniques including:

• Typosquatting popular packages (tensorflow-gpu, pytorch-cuda, transformers-dev)
• Dependency confusion (uploading packages with internal corporate names)
• Compromised maintainer accounts
• Malicious code in setup.py executing during pip install

Critical ML library vulnerabilities

Dependency pinning failure

Unpinned or loosely constrained dependencies (for example, transformers>=4.0 rather than an exact, resolved version) can reduce reproducibility and admit unreviewed updates. The effect depends on the resolver, lockfile, build, testing, and promotion controls:

• Resolved versions can vary between builds
• Updates can enter a build without deliberate review
• Breaking changes can reach production if testing or promotion controls fail
• Exact versions can be difficult to reconstruct without resolved manifests, lockfiles, or build attestations

Pin direct and transitive dependencies where the toolchain permits it, record integrity hashes, and test updates before promotion. Where exact pinning is impractical, document the resolver, accepted ranges, and rollback procedure.

Infrastructure supply chain risks

AI infrastructure dependencies create additional attack surfaces:

Cloud provider risks

• Metadata exfiltration: Cloud APIs exposing model weights, training data, or credentials
• Shared infrastructure: GPU sharing enabling side-channel attacks
• Access control failures: Misconfigured S3 buckets exposing model checkpoints
• Supply chain concentration: Heavy reliance on AWS/GCP/Azure creates single points of failure

GPU supply chain

Dependence on a small number of accelerator vendors and proprietary toolchains creates concentration and portability risk:

• Proprietary toolchains can make workloads difficult to move or reproduce
• Alternative accelerators vary by workload, software support, region, and availability
• Firmware, drivers, compilers, and orchestration layers each add provenance dependencies
• Supply constraints enable counterfeiting and gray-market hardware

Model hosting services

Third-party model hosting (Replicate, Together AI, Anyscale) introduces risks:

• No visibility into infrastructure security controls
• Model weights stored on third-party infrastructure
• Inference data potentially logged or used for training
• Service outages impacting production AI systems

AI SBOM and ML-BOM

Traditional Software Bills of Materials (SBOMs) don’t capture AI-specific components. The industry is developing two complementary approaches:

AI SBOM extends traditional SBOM

AI SBOM extends formats like SPDX and CycloneDX to include AI components:

• ML framework dependencies (PyTorch, TensorFlow versions)
• Model files as software components
• Data processing pipeline dependencies
• Training and inference infrastructure

The Linux Foundation’s SPDX 3.0 specification (released 2024) includes AI/ML extensions, providing standardized fields for model metadata and dataset references.^[10]

ML-BOM, the machine learning bill of materials

ML-BOM is a specialized format capturing ML-specific supply chain information:

No single BOM format is universally mandated across AI supply chains. CycloneDX 1.7 and SPDX 3.0 support AI/ML component information, but format support does not make an inventory complete; select fields and verification controls for the artefacts, suppliers, and deployment path in scope.

Implementing ML-BOM

Practical ML-BOM implementation requires:

• Automated extraction: Tools that generate ML-BOM from model artifacts and training pipelines
• Cryptographic hashing: SHA-256 hashes of all model weights and datasets
• Provenance tracking: Chain of custody from data collection through deployment
• Version control: ML-BOM versioned alongside model versions
• Signing: Digital signatures on ML-BOM for tamper detection

Secure model sourcing

Organizations deploying third-party models should implement verification controls:

Model Verification Checklist

Model Provenance Tracking

Implementing model provenance requires tracking:

• Source: Original repository, organization, download URL
• Integrity: SHA-256 hash of model weights
• Signature: GPG signature verification if available
• Lineage: Base model → fine-tuned versions → deployed versions
• Modifications: All fine-tuning, quantization, or pruning operations
• Evaluation: Benchmark results, bias testing, safety evaluations

Model Signing

Organizations should implement model signing for internal models:

• GPG sign model artifacts before uploading to internal registries
• Verify signatures before deployment
• Maintain key rotation and revocation procedures
• Log all signature verification attempts

Hugging Face supports model signing via GPG, but adoption remains low. Organizations should sign internal models even if third-party models lack signatures.^[12]

Dependency management for AI projects

Securing the software supply chain requires rigorous dependency management:

Dependency Scanning

Implement automated scanning for:

• Known CVEs: Use tools like pip-audit, safety, or Snyk
• Malicious packages: Detect typosquatting, dependency confusion
• License compliance: Track GPL, commercial licenses in dependencies
• Unmaintained packages: Flag dependencies with no recent updates

Dependency Pinning Best Practices

# Bad - allows any version >= 2.0
torch>=2.0.0
transformers>=4.0.0

# Good - pins exact versions
torch==2.1.2
transformers==4.36.1
tokenizers==0.15.0

Dependency Auditing Workflow

Establish a risk- and event-driven auditing workflow. Cadence should reflect exposure, release frequency, active exploitation and advisories, system criticality, and applicable obligations rather than a universal weekly, monthly, or quarterly schedule:

1. Advisory and exploitation monitoring: Match relevant security advisories and active-exploitation signals to the versioned inventory
2. Risk-based automated scans: Set a documented cadence based on exposure, criticality, change rate, and obligations
3. Release- and event-driven checks: Re-scan before relevant releases, after dependency changes, and when material advisories appear
4. Periodic human review: Review ownership, maintenance, licensing, and update recommendations on a cadence justified for the system
5. Incident response: Maintain an emergency process for material vulnerabilities

Private Package Repositories

For production systems, consider using private package mirrors:

• Mirror PyPI packages to internal Artifactory/Nexus repository
• Security scan all packages before adding to internal mirror
• Prevent direct PyPI access from production environments
• Maintain allow-list of approved packages and versions

Regulatory requirements

Supply-chain controls can support legal, contractual, and standards-based duties, but the applicable requirement depends on the organization’s role, system, components, and jurisdiction.

EU AI Act duties relevant to supply-chain risk

For covered high-risk providers, several AI Act duties can make supplier and component evidence relevant:

• Article 10 requires data-governance and management practices for training, validation, and testing datasets where those datasets are used
• Article 11 and Annex IV require system-specific technical documentation, including relevant design, development, data, and component information
• Article 15 addresses accuracy, robustness, and cybersecurity, including resilience against relevant attempts to alter use, outputs, or performance
• Article 25 can require written agreements, information, access, and technical assistance when a third party supplies a system, tool, service, component, or process used or integrated into high-risk AI

Under the AI Omnibus now in force, relevant Annex III high-risk provisions apply from 2 December 2027 and relevant Annex I product-embedded provisions from 2 August 2028. Organizations in scope should build supply-chain documentation before the applicable date.^[8]

NIST Secure Software Development Framework (SSDF)

NIST SP 800-218 is a high-level set of recommended secure-development practices. NIST SP 800-218A adds an AI-specific community profile for generative AI and dual-use foundation models. Contractual or agency obligations vary; neither publication creates a blanket compliance mandate for every federal contractor.^[13]

U.S. federal-policy status

Executive Order 14110 was revoked on 20 January 2025 by Executive Order 14148. Do not treat its reporting provisions as a current standalone obligation. NIST’s published technical guidance remains useful on its own terms, while binding duties must be traced to current statutes, regulations, procurement terms, or agency requirements.

While primarily aimed at frontier model developers, the transparency requirements establish precedent for supply chain documentation across the AI industry.^[14]

Implementation checklist

Organizations should implement supply chain security controls across six areas:

Applying GLACIS to supply-chain controls

Configured workflow

Operational evidence for supply-chain controls

Inventory spreadsheets, SBOM files, and policy documents describe supply-chain state and intent. For configured in-scope events, GLACIS can add signed records of what supply-chain controls reported; effectiveness and coverage require separate testing and evidence.

1

Use the controls you already operate

Connect a consequential decision point to existing dependency scanning, signature checking, model acceptance, or inventory controls. GLACIS does not generate a complete ML-BOM, replace a scanner, or establish upstream provenance by itself.

2

Record the control decision

Generate signed records when configured dependency-scanning, model-verification, signature-checking, and CVE-scanning controls report an outcome. Independent verification checks covered integrity and provenance properties, not effectiveness or complete capture.

3

Bind selected artefact identifiers

Preserve selected model, dependency, and data identifiers or hashes in the signed record for a covered workflow stage. Integrity checks can reveal changes to covered commitments; they do not establish a complete chain of custody or detect every unauthorized modification.

4

Regulatory Evidence Packages

Map scoped supply-chain records to EU AI Act Article 11, NIST SSDF PO.3.2, and customer review questions. The resulting evidence pack shows what configured controls reported for specific model versions; audit acceptance and compliance require separate assessment.

The difference: Documentation shows intended practice. Signed operational records add scoped evidence of what configured controls reported. Reviewers still need testing and other evidence to assess what actually occurred, effectiveness, and coverage.

Learn About Supply Chain Attestations

Frequently asked questions

References