Artificial intelligence isn’t built from scratch. It’s assembled. Models, plug-ins, training data, and adapters. Developers stitch together these components from all over the internet, then ship them into production.
Sometimes, they don’t stop to ask where those parts came from.
[Editor's Note: This is part one of two where SC Media helps unpack OWASP's Top 10 for LLM Applications. Read part one: Inside an AI supply chain meltdown] That’s what makes the AI supply chain one of the biggest risks in machine learning today. And it’s why OWASP, known for tracking critical web application vulnerabilities, now ranks supply chain attacks among the Top 10 risks facing large language model (LLM) applications.
Here’s how to fix it —
drawn directly from OWASP’s own playbook for reducing those risks.
In its official guidance, OWASP outlines not just the threat, but the solution: a practical, operational checklist for securing every layer of the AI supply chain. These aren’t vague best practices. They’re concrete, field-tested actions that help organizations verify what goes into their models, defend against tampering, and rebuild trust in the pipeline.
Start with an AI Bill of Materials (AI-BOM)
Start with visibility.
OWASP recommends constructing a real-time, signed AI Bill of Materials (BOM). This is a full inventory of every model, plug-in, adapter, training file, and third-party dependency in use. The BOM should be treated like critical infrastructure: signed, stored, regularly updated, and ideally formatted using a
standard like CycloneDX. If you don’t know what’s in your model, you can’t secure it.
Next comes hygiene. Drawing on its
A06:2021 vulnerability category, OWASP urges organizations to patch outdated components, remove deprecated dependencies, and regularly scan their ML development stacks, just like they would in traditional
Continuous Integration and Continuous Deployment (CI/CD) environments. These are the pipelines developers use to build, test, and release code. Without regular scans, outdated or insecure components can sneak into production unnoticed.
Model provenance: Can you trust your source?
Provenance is another OWASP priority. Many AI models, adapters, and weights are shared without any cryptographic proof of origin. That means you have no way of knowing who really created the file or whether it’s been tampered with. To reduce this risk, OWASP calls for file signing, hash validation, and publisher verification.
For example, if you’re downloading a model
from Hugging Face, you should stick to repositories maintained by verified organizations or trusted developers. Personal forks (copies of a model uploaded by an individual user) and mystery uploads (files lacking detailed metadata or clear authorship) may appear trustworthy, but they’re a common source of supply chain compromise. This is true even if they carry five-star ratings or strong community endorsements.
LoRA adapters: Small files, big security risk
OWASP places special emphasis on the security of fine-tuning files and
LoRA adapters. These are small, modular files used to customize a base model — a large, general-purpose AI model — so that it can perform specific tasks, like summarizing legal documents or detecting fraud.
Because LoRA adapters are easy to merge and require little compute power, they’re widely used. But they also introduce risk if they come from unknown sources or are merged without proper review. OWASP recommends scanning these files for anomalies, applying adversarial testing, and using secure registries that enforce file signing.
The security community is also exploring automated red teaming, continuous tests designed to simulate how an attacker might tamper with a model. This includes identifying behavioral drift, where a model subtly changes its responses due to a malicious or buggy adapter being loaded at runtime.
Scan everything: From pull requests to safetensors
In collaborative development environments like GitHub repositories or shared Hugging Face workspaces, OWASP emphasizes the need for build-time scanning and pull request validation. This means automatically checking model files and configurations as they’re submitted for inclusion before they’re accepted into the main codebase.
Think of it as a security checkpoint during software development. Tools like the SF_Convertbot Scanner can detect whether a file in the safetensor format — a safer, static file format for storing model weights — has been altered or corrupted. Safetensors are preferred over older formats like PyTorch pickle files, which can execute arbitrary code when loaded.
This kind of tooling introduces “friction” by slowing down malicious contributors. For example, a scanner might block an adapter from being merged until a human reviewer verifies the file. That delay, combined with clear logging, deters abuse and helps teams identify compromised components before they go live.
Don’t forget the endpoint: On-device AI is a target
Supply chain security doesn’t stop once the model is deployed. OWASP warns that on-device tampering is increasingly a threat, especially as LLMs are embedded in mobile apps, IoT devices, and BYOD (Bring Your Own Device) environments. Their guidance may sound technical — encrypt models at rest, validate firmware signatures, and terminate execution on unauthorized changes — but here’s the human version: Make sure the model is locked down, can prove it’s running on trusted hardware, and will shut itself off if someone tries to jailbreak or overwrite it.
OWASP also calls attention to third-party supplier risk. This refers to any vendor providing adapters, plugins, model training services, or hosting infrastructure. The recommendation is to use automated tools that track license terms and changes, such as shifts in a component’s open-source licensing, or updates to a supplier’s access policies.
Real attacks, real consequences
Imagine this: your team relies on an open-source LoRA adapter hosted on a public repo. One day, the developer deletes the repo or changes the license terms. Your deployment pipeline breaks. Or worse, someone else takes over the repo and replaces the adapter with a malicious version. That’s the kind of event OWASP wants teams to monitor and catch early.
None of this is abstract. Every mitigation OWASP proposes maps to real attacks.
PoisonGPT showed how a manipulated model can pass tests and still output false or misleading information. The
ShadowRay breach demonstrated how open AI orchestration tools — left unsecured — can be hijacked for credential theft and lateral movement. And
LeftoverLocals revealed how GPU memory leakage can allow attackers to spy on other users’ LLM sessions in shared environments.
The future of LLM security starts with the builders
None of these attacks needed prompt injection or clever jailbreaks. They simply exploited holes in the supply chain.
In
Part One of this series, we unpacked how those holes form and how missing metadata, third-party dependence, and inherited trust turned AI development into a high-risk ecosystem.
OWASP doesn’t demand perfection. It asks for accountability. Most of its supply chain fixes, building an AI-BOM, signing adapters, scanning pull requests, are modest changes. But what they offer in return is visibility, traceability, and confidence that your model hasn’t already been compromised before a single prompt is entered.
The tools are here. The map is drawn. The next move belongs to the builders.
[Editor's Note: This is part one of two where SC Media helps unpack OWASP's Top 10 for LLM Applications. Read part one: Inside an AI supply chain meltdown] 
