Safeguard
AI Security•

OWASP LLM03 supply chain: what should engineering leads check?

LLM03 covers risks in models, datasets, adapters and packages. A checklist for engineering leads built on OWASP's mitigation list, with defensive steps.

Safeguard Security Team
4 min read

OWASP LLM03 (Supply Chain) says an LLM application is exposed through its training data, models and deployment platforms, plus ordinary packages. Engineering leads should keep a signed inventory, verify model sources by hash and signature, evaluate third party models themselves, and review provider terms.

What does LLM03 actually cover?

The OWASP page for the 2025 list defines the risk across three layers: training data, models and deployment platforms. Because many applications rely on third party pre-trained models and data that can be tampered with or poisoned, the risk goes beyond traditional code and dependency flaws.

Its common risks include outdated third party packages, licensing conflicts, outdated or deprecated models, vulnerable pre-trained models, weak model provenance, vulnerable LoRA adapters, abuse of shared model merging and conversion services, on device model tampering, and unclear provider terms and privacy policies that could allow your data to be used for training.

That is a long list, but it falls into three groups: things you install, things you download, and things you agree to.

What is different from normal dependency risk?

A package has a version and a public advisory trail. A model file is a large binary with no readable source, and published models often offer no strong guarantee of origin. Benchmarks do not reveal hidden behavior. OWASP notes that a model can look fine on evaluations and still carry a backdoor, and that a fine tuned popular model can pass safety benchmarks while hiding targeted triggers.

So the control is less "scan it" and more "know where it came from, and test it for your use."

What is the checklist?

This follows OWASP's own prevention list, reworded as questions for a review.

Suppliers. Have we vetted data and model sources, including their terms and privacy policies, and do we re-check when those change?

Components. Do we scan and patch the packages around our models, including in development environments that handle sensitive data?

Evaluation. Have we red teamed and evaluated each third party model for our own use cases, rather than trusting published benchmarks?

Inventory. Do we keep a current, signed inventory using an SBOM, and have we looked at AI BOM and ML SBOM formats such as OWASP CycloneDX?

Licenses. Are software, tool and dataset licenses inventoried and audited, with automated license management where possible?

Provenance. Do we use only verifiable model sources, and check integrity with signatures and file hashes? Do we sign code we supply to others?

Collaboration. Do we monitor shared model development environments for abuse?

Anomaly testing. Do we test models and data for anomalies and adversarial robustness, ideally in the MLOps pipeline?

Patching. Do we have a patching policy, and are we on supported APIs and model versions?

Edge. For models on devices, do we encrypt them, verify integrity and use vendor attestation?

How should you start?

Pick the one production application that uses a model and trace it end to end. List every model, adapter, dataset, package and hosted service. For each, write who published it, how you obtained it, what version you run and how you verify it. The gaps you find are your backlog.

Many teams discover they cannot answer "which model version is in production" within a day. That alone is worth fixing first.

Where does Safeguard fit?

Safeguard can inventory and scan the open source packages around an AI application and keep an SBOM, and its Gold registry and free in-browser scan at gold.safeguard.sh/scan cover up to 100 dependencies. Model files and datasets need the provenance steps above, which are process controls as much as tooling.

What to do

  1. Choose one production AI application and inventory every model, adapter, dataset and package.
  2. Record the source, version and verification method for each item.
  3. Verify model files against published hashes or signatures, and refuse unverifiable sources.
  4. Run your own evaluation on each third party model for your use case.
  5. Read provider terms about training on your data and diary a re-check.
  6. Add model and dataset updates to your normal change review.

Quick check

Is a model on a popular hub safe by default?

No. OWASP lists weak model provenance and tampered models among the risks. Verify the source, hash and behavior for your use.

Do I need an AI BOM?

OWASP recommends maintaining a signed inventory with an SBOM and evaluating AI BOM and ML SBOM options. Start with an inventory you keep current.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.