Software supply chain security spent the last few years learning a hard lesson: the code you did not write can hurt you as badly as the code you did. AI extends that lesson to two new classes of artifact that most programs still treat as data rather than as dependencies — the models you download and the datasets you train on. A pretrained model is executable-adjacent code from a third party. A training set is input that shapes your system's behavior. Both arrive from outside your organization, both can be tampered with, and both bypass the SCA tooling that guards your package manifests. Securing the AI supply chain means bringing models and datasets under the same provenance, verification, and inventory discipline you already apply to open-source software.
Models are dependencies that can execute
The most immediate risk is the format models ship in. Many model files are serialized with Python's pickle format, and deserializing a pickle can run arbitrary code by design — loading the weights is code execution if the file is malicious. Security researchers have repeatedly found weaponized models on public hubs that execute a payload the moment they are loaded, well before any inference happens. This is the model-world equivalent of a package with a malicious install script, except it hides inside an artifact teams download casually and load without a second thought.
Practical defenses:
- Prefer safe serialization. Formats like
safetensorsstore weights as data with no code-execution path. Prefer them, and treat pickle-based weights from untrusted sources as you would treat running an unknown binary. - Sandbox untrusted model loading. If you must load a format that can execute, do it in an isolated environment with no credentials and no network egress until you have verified it.
- Verify provenance. Pin models to specific, hashed versions from known publishers. A model that changed silently under the same name is a rug-pull, exactly like a compromised package version.
- Scan model files. Treat a downloaded model like a downloaded dependency: inventory it, record where it came from, and scan it for known-malicious signatures and unsafe embedded code.
Datasets are inputs that shape behavior
Data poisoning is the subtler risk. An attacker who can influence even a small fraction of training or fine-tuning data can implant behaviors — a backdoor that triggers on a specific phrase, a bias that surfaces in specific contexts, or degraded performance on targeted inputs. Research has shown that poisoning web-scale datasets is not just theoretical: because large corpora are assembled from URLs that can expire and be re-registered, or from snapshots an attacker can time, injecting tainted content into a dataset that others will train on is practical for a determined adversary.
For retrieval-augmented systems, the analogous risk is index poisoning: plant a document that will be retrieved for a common query, and you have inserted an instruction or a falsehood into every user's context whose question matches.
Practical defenses:
- Vet and control data sources. Know where every training and fine-tuning dataset came from, restrict who can add to it, and prefer curated sources over scraped ones for anything sensitive.
- Record data provenance. Maintain a traceable record of dataset versions and origins so a discovered poisoning is a lookup, not an archaeology project.
- Protect retrieval indexes. Validate and sanitize documents entering a vector store, strip hidden content, and enforce access control so one tenant cannot poison another's retrieval.
The pattern is not new — the artifacts are
It is worth remembering that the software world has already run this play. The December 2022 torchtriton incident, where a malicious package on the public index shadowed a legitimate PyTorch dependency and exfiltrated system information on install, was a wake-up call that "we only use trusted projects" is not a control when the trusted project's supply chain is the entry point. Models and datasets are simply the newest artifacts to inherit that lesson. A team that would never curl | bash an unknown script will happily from_pretrained an unknown model, and the risk profile is closer than the difference in ceremony suggests. Applying the muscle memory you already built for packages — pin, verify, inventory, scan — to models and data is most of the battle.
Inventory: the AI bill of materials
You cannot secure what you have not enumerated. The idea gaining traction is an AI bill of materials (AI-BOM or ML-BOM) — an extension of SBOM thinking that records the models, datasets, adapters, and prompts a system depends on, with their sources and versions. It is the foundation everything else rests on. Without it, a disclosed malicious model or poisoned dataset becomes a frantic hunt across teams; with it, it becomes a query.
How Safeguard helps
Safeguard brings AI artifacts under the same supply-chain discipline as your code. Software composition analysis (SCA) inventories the components your AI application depends on and reconciles them against vulnerability and reputation data, extending the dependency-governance model that already protects your packages to the surrounding AI stack. The Griffin AI detection engine inspects the loading and integration code where an unsafe deserialization or an unvalidated model source turns a downloaded artifact into code execution, flagging it before it ships. When a fixable weakness appears — an unsafe load path, a pinned-but-vulnerable dependency — auto-fix remediation proposes the corrected version. As a model-family builder itself, Safeguard's own Griffin Zero model reflects a provenance-first approach to how AI artifacts should be sourced and shipped.
The lesson the software world already learned applies cleanly here: the model you did not train and the data you did not curate are dependencies. Inventory them, verify them, and stop treating them as inert.
Bring your AI supply chain under control — create a free account, read the documentation, or see how Safeguard compares.