Every imported component brings a history
Treat a model, package, or dataset as something to inspect before trusting.
An outside artifact
A model, package, or dataset arrives from elsewhere.
A careful check
Review its origin, format, and behavior in isolation.
A controlled release
Only reviewed versions become part of the application.
A familiar name is not evidence of origin. Record the publisher, exact version, source, and expected integrity information for the artifacts your application uses.
Integrity checks help detect changes to an expected artifact. They do not prove that the original artifact is safe. Review dependencies and test behavior in an isolated environment too.
Keep a component inventory and a rollback path. A later update can change the risk, so the review belongs in the release process rather than only at the first installation.
An AI feature is rarely built entirely by the team shipping it. It may depend on a hosted model, a downloaded model file, a Python package, a document parser, an adapter, and a cloud service.
Supply chain risk concerns the components and services you inherit from others, and the way you accept and maintain them. OWASP LLM03:2025 extends familiar dependency concerns to models, datasets, adapters, and the infrastructure used to build and serve them.
You do not need to train a model to have an AI supply chain. Calling an external model through an SDK and a gateway already creates one.
The convenient download in a demo project
Imagine a fictional developer, Sam, building an internal document assistant. A tutorial recommends a community model and a small adapter advertised as improving business vocabulary.
Sam downloads both, copies a loading command, and connects the demo to the company document store. The demo works. Everyone focuses on answer quality.
Before promotion, a review should ask:
- Who published the model and adapter?
- Which exact revisions did Sam download?
- Does the loading process run code from those repositories?
- What network and filesystem access does the demo process have?
- Has this exact combination been evaluated for the intended task?
A popular name or convincing model card helps discovery. It is not proof that every associated artifact is trustworthy. The review is about an identifiable component and its acceptance path, not a general impression of its brand.
Map what your application inherits
| Component | What to record | What to examine |
|---|---|---|
| Model or adapter | Publisher, revision, source, integrity information | Expected behavior and any custom loading code. |
| Software package | Exact version and dependency lockfile | Known vulnerabilities and update ownership. |
| Dataset | Origin, snapshot, intended use | Quality, provenance, and permission to use it. |
| Hosted API or gateway | Operator, selected model, configuration | Data handling, access scope, and change notifications. |
| Build or conversion service | Service identity and processing steps | Who can alter the output before deployment. |
An adapter is a smaller set of learned changes applied to a base model. Techniques such as LoRA make adaptation more efficient, but the combined system still needs review. Treat “trusted base plus new adapter” as a new combination, rather than assuming the base model’s earlier evaluation covers it.
An inventory is useful because it makes a later question answerable: which deployments contain the component that changed?
Two failures that need different controls
The first failure is unsafe loading. Some serialization mechanisms can execute code while reconstructing an object. Python’s pickle documentation explicitly warns that malicious pickle data can execute arbitrary code during unpickling. Loading an untrusted artifact in a process with company credentials can therefore be dangerous before the model answers anything.
The second failure is harmful learned behavior. Model weights can encode a targeted failure even when the file-loading mechanism does not execute arbitrary code. A behavioral problem requires appropriate evaluation and provenance checks.
Safetensors provides a format designed for safer tensor storage than pickle. That addresses a loading concern; it does not certify the honesty of the model’s answers. Custom repository code is another concern: Hugging Face explains that some custom models require explicitly trusting remote code.
For Sam’s review, ask these questions separately: what executes when we load this, and what does the loaded system do?
A practical acceptance process
Apply these steps to the demo before it receives valuable access. This workflow turns the inventory, provenance, evaluation, and maintenance concerns in OWASP LLM03 into concrete review tasks.
- Choose the source deliberately. Confirm the publisher through a known channel and record the selected revision. A lookalike account or a moving “latest” reference makes later investigation harder.
- Verify integrity against a trusted reference. Compare the artifact with an approved digest or verified signature. A checksum copied from the same untrusted download location is not independent evidence of authenticity.
- Review the loading path. Inspect custom code and avoid unnecessary code-executing loaders. Test new components in an isolated environment without production credentials, because a loading failure should not expose the document store.
- Evaluate the exact combination. Test the model, adapter, prompts, and tools together on representative tasks and targeted failure cases. A general benchmark does not cover every permission or business rule in your application.
- Record use and data-handling terms. Note the relevant license and provider settings alongside the component. This gives the responsible team a concrete basis for reviewing distribution, retention, or training use.
- Assign maintenance and rollback ownership. Name who monitors advisories, approves upgrades, and restores the previous version. Pinning a vulnerable component indefinitely is not a maintenance strategy.
A local exercise without downloading a model
Create a small text file called demo-component.txt containing an invented version label. Record its filename, purpose, owner, and SHA-256 digest in a notebook. On Windows, you can inspect the digest with:
Get-FileHash -LiteralPath .\demo-component.txt -Algorithm SHA256Change one character in your own file and calculate the digest again. The changed value tells you the bytes differ from your recorded baseline.
Now answer the more interesting questions: who approved the baseline, where is it stored, and could the same person replace both the file and its recorded digest? The exercise demonstrates integrity comparison. It does not prove that the original file was safe or that its publisher was legitimate.
Finish by drafting one inventory row for a real dependency in your own project. Use documentation and existing files; do not execute an unfamiliar model to complete the exercise.
Where LLM03 meets LLM04
A poisoned model supplied by a third party can involve both categories. LLM03 asks how the artifact entered your system and gained trust. LLM04 examines the corruption of data or model behavior.
A passing scan, a signature, and a good benchmark each answer a different question. None is a complete guarantee. Combine evidence, limit the component’s privileges, and keep a practical way to replace it.