In March 2024 a Microsoft engineer investigating a half-second SSH slowdown uncovered a backdoor in xz-utils that a patient attacker had spent years positioning — grooming a maintainer identity, earning commit rights, and hiding a payload in test files. The industry got lucky exactly once. Supply-chain attacks 2.0 is the recognition that the target has moved: not your code, not even your dependencies' code, but the entire social and technical machinery that produces software — registries, maintainer accounts, build pipelines, and now the AI systems that suggest what to install.
The first wave, exemplified by SolarWinds, taught attackers that one compromised build system beats a thousand phishing campaigns. The second wave is broader and cheaper: instead of breaching a vendor, you become one.
The registry is the battlefield
Public package registries are the highest-leverage distribution channel ever offered to attackers: global reach, automatic execution via install scripts, and inherited trust.
- ▸Typosquatting and dependency confusion: Alex Birsan's 2021 research showed internal package names could be hijacked from public registries; years later, unscoped internal names and misordered resolution still bite.
- ▸Maintainer account takeover: the ua-parser-js and event-stream incidents both weaponized legitimate, widely-used packages by compromising or inheriting maintainer access. Your dependency tree trusted the name; the human behind it changed.
- ▸Install-time execution: npm postinstall scripts and Python setup routines run arbitrary code at install, meaning evaluating the package after the fact is already too late if your CI installed it first.
Slopsquatting: the AI-shaped hole in dependency management
LLM coding assistants hallucinate package names — plausible, convention-following names that do not exist. Researchers have shown these hallucinations are surprisingly repeatable across prompts, which turns them into an attack surface: register the hallucinated name, wait for developers to paste the suggested install command, collect executions. The term slopsquatting is new; the defenses are not.
- ▸Lockfiles everywhere: builds install only what is pinned and hash-verified — never what a README, a model, or a teammate's terminal history suggests.
- ▸A registry proxy with a gate: route all installs through an internal proxy (Artifactory, Nexus, or equivalent) that quarantines packages that are days old, have near-zero downloads, or lack repository history.
- ▸Treat AI suggestions as untrusted input: a suggested dependency gets the same review as a pull request from an unknown contributor, because functionally that is what it is.
Models and datasets are dependencies too
If your teams pull models from public hubs, you are running a second package manager with weaker norms. Malicious pickle-serialized models that execute code on load have been found repeatedly on public model hubs, and the PyTorch nightly torchtriton compromise showed the ML toolchain itself is in scope. Datasets can be poisoned upstream of every model trained on them.
The controls translate directly from the code supply chain: prefer safetensors over pickle-based formats and refuse unsafe deserialization in loaders, pin models by content hash rather than by name and tag, scan artifacts before they enter your internal hub, and record model provenance — who trained it, on what data, with which pipeline — the way you record build provenance for a binary.
What your SBOM does not tell you
SBOMs answer what is inside — necessary, and mandated in more and more procurement — but an inventory is not an integrity guarantee. An SBOM of the backdoored xz would have listed xz, accurately. The complementary layer is provenance and attestation:
- ▸SLSA: a maturity ladder for build integrity, with hosted, hardened, provenance-generating builds as the goal state.
- ▸Sigstore and cosign: signing and verifying artifacts becomes cheap enough to enforce in CI, and npm's provenance attestations link a package to the exact source commit and workflow that produced it.
- ▸in-toto attestations: chain the whole pipeline, so the claim that this artifact came from that repository via this builder is verifiable rather than assumed.
A hardening checklist for the second wave
1. Enforce lockfiles with integrity hashes in every ecosystem you build in, and fail CI on unpinned additions. 2. Front all registries — packages and models alike — with a proxy that quarantines new and low-reputation artifacts. 3. Disable or sandbox install-time scripts wherever the ecosystem allows it. 4. Require provenance attestations for internal artifacts and verify signatures at deploy time, not just build time. 5. Add hallucination checks to developer workflow: confirm a package exists, is established, and matches its claimed repository before first install. 6. Extend all of the above to ML artifacts, with pickle-format loading blocked by policy.
The uncomfortable truth of supply-chain security is that you are betting on ecosystems you do not control, maintained by people you have never met, increasingly recommended by models that do not know whether their suggestions exist. You cannot audit your way out of that. You can, however, make your organization a hard target for commodity attacks — pinned, proxied, attested, verified — so that reaching you requires xz-level patience. Most attackers will not spend it. The business return is concrete: fewer emergency dependency incidents, faster answers when the next disclosure lands, and procurement conversations where your provenance story is an asset instead of an apology.