Why do model artefacts create supply chain risk even when no CVE exists?

Why model artefacts create supply chain risk even without a CVE

Model artefacts are supply chain inputs, so the security question is not whether a public vulnerability has been assigned, but whether the file or package can be trusted end to end. A model can be tampered with before it ever reaches production, and that tampering may survive normal patch and CVE workflows because the danger is integrity, provenance, and runtime behaviour.

What can go wrong with a model artefact

Model files are often treated like inert downloads, yet they can carry poisoned weights, altered checkpoints, unsafe deserialisation paths, or embedded behaviour changes that only appear when the artefact is loaded. That means the risk sits in acquisition, storage, transfer, and loading, not only in the source repository that published it.

In practice, provenance failures are the most important failure mode. If a team cannot prove where the artefact came from, who signed it, what was built, or whether the checksum matches the expected release, then the artefact may be malicious, swapped in transit, or simply not the model they think they received.

Why CVE thinking is too narrow for model supply chain security

CVE records are useful for known software flaws, but they do not cover every way an artefact can be abused. A model can be risky because of poisoned training data, compromised release infrastructure, malicious packaging, or unsafe loading behaviour, even when no public advisory exists.

That is why integrity controls matter more than version tracking alone. The relevant security question is whether the artefact can be verified before use and whether the runtime can limit what happens if the artefact is corrupted, substituted, or loaded from an untrusted source.

Risk and Threat Considerations

Model artefacts create exposure when teams trust file origin, checksum, or repository reputation more than verifiable provenance. Attackers can target the artefact upstream, then rely on normal deployment processes to carry the compromise into inference, automation, or downstream applications.

Failure mechanism: A poisoned, swapped, or improperly loaded artefact can alter model behaviour or trigger unsafe execution paths without needing a published CVE, which means traditional vulnerability management may never flag the problem.

Impact: The result can be silent integrity loss, credential or data exposure, corrupted outputs, and a supply chain compromise that persists until the artefact is replaced and every dependent consumer is reviewed.

Practitioner Guidance

What to verify: Treat every model artefact as a controlled supply chain object. Verify source identity, signing or checksum status, storage location, dependency lineage, and whether the loading path permits deserialisation or plug-in style behaviour that expands the blast radius.

Decision rule: If you cannot prove artefact provenance and integrity, do not treat the model as safe just because the registry shows no CVE. Quarantine the artefact, validate it against a trusted release process, and only then allow promotion into environments that can access sensitive data or tools.

Common mistake: Teams often focus on the model name or version number and ignore the delivery path, the training inputs, and the loader. That leaves them blind to the most common supply chain failure patterns, which are substitution, poisoning, and trust abuse rather than classical patched software defects.

Practitioner takeaway: For model supply chain, the control objective is trust in the artefact’s origin and behaviour, not the existence of a CVE entry.

Related resources from NHI Mgmt Group

• Why do hallucinated packages create supply-chain risk even when the model is not directly compromised?
• Why do npm supply chain worms create so much risk even without a CVE?
• Why do exposed model registry tokens create supply-chain risk?
• Why do package publishing workflows create supply chain risk even when code reviews exist?