AI supply-chain risks: models, data, software and services
AI systems inherit every software supply-chain risk and add new ones: poisoned data, tampered weights, malicious adapters and hosted models that change under you. Three public frameworks describe them, and an AIBOM is where you track exposure.
- OWASP's 2025 Top 10 for LLM Applications lists Supply Chain (LLM03) and Data and Model Poisoning (LLM04).
- MITRE ATLAS technique AML.T0010, AI Supply Chain Compromise, has sub-techniques for hardware, AI software, data, models, container registries and agent tools.
- NIST AI 100-2 E2025 provides a common taxonomy of adversarial ML attacks for predictive and generative AI.
- The EU AI Act's cybersecurity article names data poisoning and model poisoning explicitly.
Why AI supply chains are different
A conventional application depends on code. An AI system also depends on data it learned from and weights it did not write, often obtained from public hubs. OWASP notes that, unlike traditional software risks focused on code flaws, ML supply-chain threats extend to third-party pre-trained models and datasets that can be tampered with or poisoned [1].
Three reference frameworks
OWASP Top 10 for LLM Applications (2025)
The 2025 list includes LLM03 Supply Chain and LLM04 Data and Model Poisoning among its ten entries [2]. LLM03 describes vulnerable pre-trained models, weak model provenance, vulnerable LoRA adapters, model merge exploitation, on-device supply-chain risks, traditional package vulnerabilities and licensing risks. Its prevention guidance includes keeping an up-to-date, accurate and signed inventory of components using an SBOM, and verifying model integrity with signing [1].
MITRE ATLAS
ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is MITRE's knowledge base of adversary tactics and techniques against AI systems [3]. Technique AML.T0010, AI Supply Chain Compromise, covers compromise of "the unique portions of the AI supply chain", with sub-techniques for Hardware, AI Software, Data, Model, Container Registry and AI Agent Tool. Related techniques include Publish Poisoned Datasets (AML.T0019), Poison Training Data (AML.T0020) and Publish Poisoned Models (AML.T0058) [4].
NIST AI 100-2 E2025
NIST's Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, published in March 2025, covers predictive and generative AI and is intended to give standards and practice guides a common language for adversarial ML, including poisoning attacks [5].
Risk map and what an AIBOM records
| Risk | Framework reference | AIBOM field that helps |
|---|---|---|
| Backdoored or tampered pre-trained model | OWASP LLM03; ATLAS AML.T0010 (Model), AML.T0058 | Model source, revision, artefact hash, signature |
| Poisoned training or fine-tuning data | OWASP LLM04; ATLAS AML.T0019, AML.T0020 | Dataset source, version, collection process |
| Malicious adapter or merged model | OWASP LLM03 | Base model and adapter lineage |
| Vulnerable ML framework or inference server | OWASP LLM03; ATLAS AML.T0010 (AI Software) | Software dependencies with versions |
| Compromised container image | ATLAS AML.T0010 (Container Registry) | Image digest and registry |
| Malicious agent tool | ATLAS AML.T0010 (AI Agent Tool) | Tools and plug-ins with versions and sources |
| Licence conflict in model or data | OWASP LLM03 | Model and dataset licences |
| Unsafe serialised model file | Serialisation attacks | File format; scan result reference |
Controls that pair with the inventory
- Pin and verify. Record revisions and hashes, and verify signatures where available. Sigstore's
model_signingsupports this for model artefacts [6]. - Scan before loading. Tools such as ModelScan check Pickle, H5 and SavedModel files for embedded code [7].
- Track hosted models. Record the provider and model identifier for each external API, and watch for changes.
- Correlate. Match framework versions in the AIBOM against vulnerability data, as you would for any SBOM.
Regulatory angle
The EU AI Act requires high-risk AI systems to include measures against data poisoning, model poisoning of pre-trained components, adversarial examples, confidentiality attacks and model flaws [8]. Knowing which pre-trained components you use is the starting point for those measures.
Risks that change without a release
Two risks are easy to miss because nothing in your own pipeline changes. A hosted model provider can update the model behind an API name, altering behaviour and limitations. An agent can load a new tool or plug-in at runtime. Both need AIBOM entries with a recorded identifier and a date observed, so that a change can be detected and reviewed.
How IntelliXBOM helps
IntelliXBOM correlates the models, datasets and frameworks in your AIBOMs with vulnerabilities, known-exploited lists, licences and the business services that depend on them. Required-field policies flag missing hashes or unpinned revisions, and VEX decisions record how each finding was assessed.
Frequently asked questions
What is an AI supply-chain attack?
It is an attack that compromises a component an AI system depends on, such as a pre-trained model, a dataset, an ML framework, a container image or an agent tool, rather than the system itself. MITRE ATLAS catalogues these under AML.T0010, AI Supply Chain Compromise.
What does OWASP LLM03 cover?
LLM03:2025 Supply Chain covers vulnerable pre-trained models, weak provenance, malicious LoRA adapters, model merges, on-device risks, outdated packages and licensing. Its mitigations include a signed, up-to-date component inventory and model integrity checks.
How does an AIBOM reduce AI supply-chain risk?
It records which models, datasets and frameworks each system uses, with versions, sources and hashes. When a component is found to be compromised, you can identify affected systems quickly.
Sources
- LLM03:2025 Supply ChainOWASP Gen AI Security Projectgenai.owasp.org/llmrisk/llm032025-supply-chain/
- 2025 OWASP Top 10 for LLM ApplicationsOWASP Gen AI Security Projectgenai.owasp.org/llm-top-10/
- MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems)MITREatlas.mitre.org/
- ATLAS data: tactics, techniques and case studiesMITRE ATLAS (GitHub)github.com/mitre-atlas/atlas-data
- NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (March 2025)NISTcsrc.nist.gov/pubs/ai/100/2/e2025/final
- Model Transparency (model_signing)Sigstore (GitHub)github.com/sigstore/model-transparency
- ModelScan: protection against model serialisation attacksProtect AI (GitHub)github.com/protectai/modelscan
- AI Act Article 15: Accuracy, Robustness and CybersecurityEU AI Act Explorer (Future of Life Institute)artificialintelligenceact.eu/article/15/
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.