OWASP's LLM03:2025 Supply Chain says the risk reaches beyond code libraries to pre-trained models, datasets and adapters you did not build. Controls that work are verifiable sources, signed inventories, vendor review and patching. Controls that fall short alone are model cards, benchmark scores and static inspection of model files.
This post is based on the OWASP page for LLM03:2025, which we fetched on 18 October 2026.
What does LLM03 cover?
OWASP states that LLM supply chains are vulnerable at every stage, including training data, models and deployment platforms. Unlike traditional software, where concerns centre on code flaws and dependencies, ML systems depend on third party pre-trained models and datasets that can be tampered with or poisoned.
Its list of common risks includes vulnerable third party packages, licensing problems, outdated or deprecated models, vulnerable pre-trained models, weak model provenance, vulnerable LoRA adapters, exploited collaborative development such as shared model merge services, on-device model risks and unclear terms and privacy policies of model operators.
Which controls work?
These come from OWASP's prevention list.
Verifiable sources and integrity checks. Use models only from verifiable sources and verify integrity with signatures and file hashes. This directly addresses weak provenance.
A signed bill of materials. Maintain an up-to-date, signed software bill of materials, and evaluate AI BOMs and ML BOMs such as those in OWASP CycloneDX. It speeds response when a new vulnerability is announced and helps prevent tampering.
Supplier vetting. Review data sources and suppliers, including terms and privacy policies, and audit supplier security and access regularly. This is how you learn that a provider's terms allow your data to be used for training.
Patching and scanning. Apply vulnerability scanning, management and patching to components, including in development environments that handle sensitive data. A model server is software with dependencies like any other.
A licence inventory. Inventory all software, tool and dataset licences using BOMs and audit them regularly. Dataset licences may restrict use or commercialisation.
Red teaming before selection. Run AI red teaming and evaluations for your use cases before choosing a third party model.
Edge hardening. For on-device models, encrypt them, verify integrity and use vendor attestation to block tampered apps.
Which controls do not work alone?
Model cards. OWASP says model cards document a model but do not verify where it came from. Attackers can compromise a supplier's repository account or create a lookalike repository.
Benchmarks. OWASP says benchmarks alone are insufficient because models can be fine-tuned to pass them.
Static inspection. OWASP calls models binary black boxes, so static inspection gives limited assurance. Backdoors may stay hidden through safety evaluations.
Trusting a hub or a brand. A popular repository can still host a poisoned or look-alike model. Reputation is a signal, not a guarantee.
One-time review. Adapters, merges and updated model versions arrive after the review. Treat each new artifact as a new input.
None of these is useless. They are inputs. The point is that none of them answers the question "is this the file the author published, and has it been tampered with?"
What to do
- Inventory every model, adapter, dataset and AI related package in use, with source and version.
- Pin models by hash and verify signatures where the publisher provides them.
- Record the inventory as an AI BOM or ML BOM and sign it.
- Review each supplier's terms on training use of your data.
- Scan the serving stack for vulnerable packages and patch on a schedule.
- Test models on your own use cases before adoption, and again after any update.
Quick check
Is a model card proof of origin?
No. OWASP states that model cards document a model but do not verify its origin. Verify with signatures and file hashes from a source you can verify.
Do benchmark scores prove a model is safe?
No. OWASP says benchmarks alone are insufficient because models can be fine-tuned to pass them. Test for your own use cases.
Sources
Last reviewed: 18 October 2026.
