LLM03: Supply Chain
Compromised third-party models, fine-tunes, plugins, or training datasets introduce risk into the deployed stack.
Last reviewed October 2026
Why LLM03 evidence is hard
Third-party models, fine-tunes and datasets arrive carrying whatever is already inside them. Six probes work the memorisation and trigger side from outside: divergent repetition, pattern completion, recall of a planted phrase. A separate model-file scanner walks serialised checkpoints for dangerous constructors before anything is loaded. Neither can tell you the provenance of a weight file. That comes from the supplier record and the AI-BOM entry, where a component the platform discovered by probing is marked differently from one a person declared.
How Penaxtra maps to LLM03
The LLM03 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
LLM03 capabilities
Findings tagged with the OWASP LLM Top 10 LLM03 identifier
Penaxtra severity for this control (high)
Cross-framework identifiers attached to the same finding where controls overlap
PDF and JSON evidence export with the control identifier attached
LLM03 control coverage
Findings for LLM03 carry the OWASP LLM Top 10 LLM03 identifier along with the corresponding control identifiers in the other frameworks Penaxtra maps, so one result is reflected across each mapped framework.
Frequently asked
What is LLM03 (Supply Chain)?
Compromised third-party models, fine-tunes, plugins, or training datasets introduce risk into the deployed stack. It is an OWASP LLM Top 10 control; Penaxtra assesses it at high severity.
How does Penaxtra test for LLM03?
The LLM03 identifier is written onto the finding at the moment it is created, not mapped in afterwards, so the JSON and PDF exports come out already in your assessor's structure. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
Does a finding for LLM03 help with an audit?
Each finding is tagged with the OWASP LLM Top 10 LLM03 identifier and exported in the PDF and JSON evidence pack, so it appears on the auditor control list with the identifier already attached.