The DeepSeek Moment: A Supply Chain Wake-Up Call
DeepSeek's R1 model arrived in January 2026 as a high-performance open source large language model that could match or exceed the capabilities of leading closed-source models at a fraction of the reported training cost. Within weeks, it was being integrated into enterprise applications, developer tooling, and internal AI platforms across industries.
The security community's response was swift — and focused on a set of concerns that existing software supply chain frameworks were poorly equipped to handle:
- What data was used to train the model, and under what license?
- What base model or pre-trained weights, if any, did the model build upon?
- What runtime libraries and serving frameworks does the model require, and are they patched?
- Does the model's behavior encode any embedded instructions or backdoors not visible in the weights?
- What is the provenance chain for the model artifacts distributed via Hugging Face?
None of these questions have clean answers in a traditional SBOM. They require a different — or significantly extended — approach to component transparency.
Why AI Models Are a Supply Chain Problem
In conventional software supply chain security, the unit of analysis is a software component: a library, a package, a binary. Components have versions, licenses, known CVEs, and package identifiers (PURLs) that SCA tools can enumerate and match against vulnerability databases.
AI models challenge every assumption in this framework:
1. Models Do Not Have Package Identifiers
A PyPI package or npm module has a canonical identifier. A model published on Hugging Face has a repository path and a commit hash, but no standardized PURL equivalent recognized by NVD, GHSA, or OSV. This means SCA tools cannot automatically identify a deployed model, match it against a vulnerability database, or generate an SBOM entry in any meaningful sense.
2. Training Data Is a Dependency With No Inventory Standard
Models trained on datasets that include copyrighted or personally identifiable data carry legal and security risk that does not map to CVEs but is very real in terms of regulatory exposure. The EU AI Act, which entered its first enforcement phase in February 2025, requires documentation of training data sources for high-risk AI systems. Most organizations deploying open source models have no mechanism to produce this documentation.
3. Model Weights Are Opaque
Unlike source code, model weights cannot be audited for backdoors or adversarial behavior through static analysis. The only viable approach is behavioral testing — red-teaming, adversarial probing, and output monitoring — which is fundamentally different from code review or dependency scanning.
Research published in late 2025 demonstrated that adversarial behavior can be embedded in model weights during fine-tuning and is effectively invisible to static inspection of the training code. A model that passes all code-level supply chain checks can still exhibit malicious behavior triggered by specific inputs.
The Emerging Framework: Model Cards, Data Cards, and AI SBOMs
The industry has not solved this problem, but a set of emerging practices is beginning to establish a foundation for AI supply chain transparency:
Model Cards
Introduced by Google researchers in 2018 and widely adopted on Hugging Face, model cards document intended use, performance characteristics, and known limitations. They are not security documents and do not enumerate dependencies, but they represent the closest existing analog to an SBOM for AI models. NIST's AI Risk Management Framework (AI RMF 1.0) recommends model cards as a governance artifact.
Data Cards / Datasheets for Datasets
Analogous to model cards, data cards document the composition, collection methodology, preprocessing steps, and known limitations of training datasets. The EU AI Act's technical documentation requirements for high-risk AI systems closely align with what a comprehensive data card should contain.
The CycloneDX ML-BOM Extension
OWASP's CycloneDX team published an extension specification for machine learning bill of materials (ML-BOM) that extends the standard CycloneDX schema to include model metadata, training dataset references, and hyperparameter documentation. As of early 2026, tool support for ML-BOM is nascent but growing — a small number of MLOps platforms have begun generating CycloneDX ML-BOM documents as part of their model release pipelines.
Note the "undisclosed" training dataset — this is the honest state of most open source
model documentation today and precisely the gap that supply chain security requires closing.
Runtime Dependencies: Where Existing Tools Do Apply
While model weights themselves are outside the scope of current SBOM tooling, the runtime environment required to serve AI models is entirely within scope — and represents a significant and often under-scanned attack surface.
A typical open source model deployment involves:
- Python runtime (3.10–3.12) and a large set of Python packages (transformers, torch, accelerate, safetensors)
- CUDA libraries and GPU drivers (for inference acceleration)
- A serving framework (vLLM, Ollama, TGI, FastAPI)
- Container base image (often NVIDIA CUDA base, Debian, or Ubuntu)
Each of these has packages, versions, and known CVEs that standard SCA tools can enumerate.
The challenge is that AI model deployments frequently bypass standard software packaging entirely —
teams pull model weights directly from Hugging Face, install dependencies via pip install -r requirements.txt
without pinning, and deploy into Docker images built from base images that have not been scanned.
An analysis of common LLM inference stacks in early 2026 found that the average deployment included 47 transitive Python dependencies with at least one known CVE. The most common critical vulnerabilities were in serialization libraries (pickle, safetensors pre-1.0.4) and HTTP serving components.
What Security and Compliance Teams Should Do Now
The regulatory and tooling landscape for AI supply chain security will not be complete in 2026. But waiting for perfect frameworks is not a defensible posture. Here is what is practical today:
For Runtime Dependencies
Treat AI model deployments like any other software artifact. Generate an SBOM for the container image and Python environment. Scan for known CVEs in the serving stack. Pin dependency versions. This is standard practice — the gap is that most AI teams operate outside the DevSecOps processes applied to the rest of the organization's software.
For Model Provenance
Maintain an internal registry of approved models. For each model: document the source repository and commit hash, the license, any known model card content, and the business justification for use. This is not an SBOM — it is a model inventory — but it provides the minimum documentation baseline required for EU AI Act compliance for high-risk systems.
For Training Data
For models you fine-tune internally, document your training datasets in a data card format. For externally sourced models, request training data documentation from the model provider before deployment in production or customer-facing systems. If the provider cannot supply it, that is a risk factor that should be explicitly accepted and documented.
Scan the Software Around Your AI Models
Fossity generates SBOMs and vulnerability reports for container images, Python environments, and build artifacts — including the inference stacks that power open source AI deployments. While the model weights themselves remain outside current SCA scope, Fossity covers everything around them: the serving framework, base images, and transitive dependencies.
Scan Your AI Stack →The Regulatory Trajectory
The EU AI Act created the first binding legal framework for AI supply chain documentation, requiring technical documentation that covers training data, model architecture, and intended use for high-risk AI systems. NIST's AI RMF provides a voluntary governance framework. CISA published guidance in late 2025 on AI supply chain risk management for critical infrastructure.
The direction is clear: AI components will increasingly be subject to the same transparency requirements as conventional software. Organizations that begin building model inventory and documentation practices now will be ahead of mandatory requirements that are likely to arrive within the next 18 to 24 months.