OWASP's LLM03:2025 Supply Chain risk covers everything your AI application takes from outside: pre-trained models, LoRA adapters, datasets, packages and hosting platforms. Detection starts with a log of what was loaded, from where, and with which hash. Alert when any of those change without a ticket.
What does OWASP include in this risk?
The OWASP page lists nine common risks: vulnerable third-party packages, licensing problems, outdated models, vulnerable pre-trained models, weak model provenance, vulnerable LoRA adapters, exploited collaborative development such as merge and conversion services, on-device model supply chain issues, and unclear terms and privacy policies. Example scenarios include a compromised Python library, a tampered model published to spread misinformation, a tainted LoRA adapter, and an impersonation of a removed model under the same name.
The prevention list leans on inventory and verification: vet suppliers, scan and patch components, red-team third party models, keep a signed SBOM and AI or ML bill of materials, use models only from verifiable sources with signatures and hashes, monitor collaborative environments, and use anomaly detection.
This post turns that into events you can record. It describes defensive logging only.
What should you log?
- Every model load. Record the model name, version, source URL or registry, file hash, signature result, who or what requested it, and time.
- Every adapter attach or merge. Record the base model hash, adapter hash and source, and the operator.
- Dataset and embedding source changes. Log new sources, new ingestion jobs and changes to sources already approved.
- Dependency changes in the AI runtime. Capture lockfile diffs, new packages and version bumps for the serving code.
- Model file format and loader. Note when a format that can execute code on load, such as pickle files (called out on the related OWASP data and model poisoning page), is read.
- Outbound connections at load and inference. Record new destinations from the model server.
- Provider and licence terms. Keep a dated copy of terms for each external model or API, since OWASP names unannounced term changes as a risk.
- Evaluation results per version. Log the red team and regression scores that approved each model.
Which alerts are worth wiring up?
- A model or adapter loads with a hash that is not on the approved list.
- A signature check fails or is absent for an artifact that used to be signed.
- A model is pulled from a registry or account you have never used.
- A model name matches an approved one but comes from a different publisher, which is the impersonation case OWASP describes.
- A new package appears in the serving environment outside a reviewed change.
- A known vulnerable component is found in the AI stack. Safeguard's dependency inventory and reachability analysis can flag these.
- The model server opens a connection to a new external host.
- Evaluation scores for a deployed version drop between runs.
- An external provider's terms or retention policy change.
- An on-device model file differs from the shipped version.
How do you keep the noise down?
Start with an allowlist of approved sources, hashes and publishers, so alerts are exceptions rather than a stream. Route load events through one internal registry, so you log in one place. Tie each alert to an owner and to a change ticket, and close the alert when the ticket matches.
What to do
- Create an internal model and dataset registry and require all loads to come from it.
- Generate an AI bill of materials for each deployed system, in a format such as CycloneDX, as OWASP suggests.
- Add the eight log events above to the model server and pipeline.
- Build the first three alerts (unknown hash, failed signature, unfamiliar source) before the others.
- Test the alerts by loading an unapproved test artifact in staging.
- Review provider terms on a calendar, quarterly at least.
Quick check
Does a model card prove where a model came from?
No. OWASP says model cards document a model but do not verify it, and attackers can impersonate or compromise supplier accounts.
What is the first thing to log?
Every model load, with source, version and file hash. Without that record you cannot tell what ran or alert on a change.
Sources
Last reviewed: 18 October 2026.
