A LoRA adapter is a small add-on file that changes a base model's behaviour, and a merge combines models into a new one. Both are easy to share and hard to audit. OWASP lists malicious adapters and unreviewed merges as supply chain risks, so approve sources and test the combined result.
What OWASP says
On its LLM Supply Chain page, OWASP notes that fine tuning methods such as LoRA and PEFT add supply chain risk alongside open access models. It lists malicious LoRA adapters as a risk: adapters that can compromise a base model during merges or when loaded on inference platforms.
It also flags collaborative platforms offering model merging and conversion services, which can be exploited to introduce vulnerabilities and bypass reviews.
Why adapters are awkward to review
An adapter is small, so it moves around casually. It is applied to a base model you may have vetted, which creates false comfort: the base is known, so the combination feels known. But the behaviour you ship is the combination.
Conversion and merge services add another hop. A file that passes through a third party service is a different artefact from the one you started with.
A simple approval policy
- Approved sources only. Keep a short list of publishers and repositories your team may pull adapters from.
- Record lineage. For every merged or adapted model, store the base model, each adapter, versions, hashes and who ran the merge.
- Re-evaluate the result. Test the combined model on your own tasks. OWASP advises running red teaming and evaluations on third party models for your use cases.
- Control the merge environment. Run merges and conversions in isolated, logged environments. OWASP recommends monitoring and auditing collaborative model development environments for abuse.
- Block unreviewed loads. Make the inference platform refuse artefacts that are not on the approved list.
What to log. Keep enough to answer an incident question later: which adapter was in production on a given date, where it came from, and who approved it. If you cannot answer that, you cannot scope an issue when a publisher is compromised or a file is withdrawn.
Keep expectations realistic
You will not be able to read an adapter and certify it safe. The achievable goals are provenance, isolation and behavioural testing. Those turn a blind trust decision into a managed one.
Safeguard's inventory and policy capabilities support the record keeping side of this, including SBOM style records for the software around the model.
Questions for a supplier. When an adapter or merged model comes from someone else, ask who trained it, on what data, from which base, and how it was tested. Ask whether files are signed and whether past versions are retained. Ask what happens if a flaw is found. Vague answers are information too. OWASP also notes that unclear terms and privacy policies can mean your data is used for training.
Quick check
If the base model is vetted, is the adapted model vetted?
No. An adapter can change behaviour, so the combination needs its own evaluation.
Sources
Last reviewed: 19 October 2026.
