Open source security used to have a clean mental model: a human writes a dependency, a human publishes it to npm or PyPI, and tools like Sonatype's Nexus scan the manifest against a known-vulnerability database before it ships. That model assumed a human at every step — choosing the package name, typing it correctly, and reading the changelog before upgrading. In 2025, that assumption broke. Coding agents now pick dependencies, write the install commands, and merge the pull requests, often without a person ever looking at the package name. Attackers noticed first: they're registering packages that only an AI would recommend, backdooring the AI tooling itself, and burying malicious logic that legacy component scanners were never built to see. This piece looks at what actually changed, where the old model — the one Sonatype built its business on — is now structurally behind, and what a security model built for an AI-authored codebase needs to do instead.
What Actually Changed When AI Started Choosing Dependencies?
What changed is that the decision to trust a package moved from a human reading documentation to a model predicting the most statistically likely token sequence — and that prediction is sometimes a package that doesn't exist. Researchers at USENIX Security 2025 analyzed more than 576,000 code samples generated by 16 different large language models and found that roughly 1 in 5 recommended packages didn't exist at all — about 205,000 unique hallucinated names, with open-source models hallucinating at nearly 22% and commercial models around 5%. Before generative coding tools, a typo-squatted or invented package name was a narrow, low-yield attack: it relied on a human mistyping reqeusts instead of requests. Now the mistake is systematic and reproducible. If an LLM hallucinates the same fake package name across thousands of independent developer sessions, an attacker who registers that one name gets a predictable, repeatable distribution channel — no phishing required, no typo required, just a coding assistant doing exactly what it was asked to do.
What Is Slopsquatting, and Why Does It Break the Old SCA Model?
Slopsquatting is the practice of registering a package name that an AI model hallucinates, so that the next developer (or agent) who trusts the suggestion pulls down attacker-controlled code — and it breaks legacy software composition analysis (SCA) because SCA was built to score known packages, not to question new ones. Sonatype's Nexus Firewall, JFrog Xray, and similar tools work by matching what's already in a manifest against vulnerability and malware databases; they are excellent at telling you a known CVE exists in lodash@4.17.15. They are not designed to ask "did a human or a model choose this dependency, and does this name statistically resemble a hallucination pattern?" Security researcher Bar Lanyado demonstrated the mechanics back in 2023 by publishing a proof-of-concept package under a name GPT had hallucinated; it was pulled tens of thousands of times within months before takedown. By 2025 the pattern was well-known enough that the Python Software Foundation's Seth Larson gave it the name "slopsquatting" in a public advisory, and it now sits alongside typosquatting as a named category in supply-chain threat models — a category that didn't need to exist five years ago.
Why Isn't Sonatype's Component Intelligence Enough Anymore?
Sonatype's component intelligence isn't enough anymore because it was architected around the manifest file as the unit of trust, and AI-era attacks increasingly live outside the manifest entirely. A traditional SCA scan looks at package.json, requirements.txt, or a Maven POM and evaluates the declared dependency tree. But in September 2025, security researchers at Koi Security disclosed that a Model Context Protocol (MCP) server package, postmark-mcp, had been quietly modified starting at version 1.0.16 to BCC every outgoing email — sent through an AI agent's email tool — to an attacker-controlled address. That package sat inside an agent's tool configuration, not a conventional dependency manifest, and it shipped fully functional for months before anyone noticed the single added line of code. This is the widening gap: MCP servers, agent skill definitions, IDE extensions, and model weights themselves are now part of the software supply chain, and a scanner built to parse package-lock.json has no visibility into any of it. Sonatype's own 2024 State of the Software Supply Chain report tracked malicious open source packages climbing into the hundreds of thousands cumulatively — proof the volume problem was already outpacing manual curation before agentic tooling even entered the picture.
How Are Attackers Already Exploiting the AI Supply Chain, in Practice?
Attackers are already exploiting the AI supply chain by targeting the tools developers now trust implicitly, and the incidents aren't hypothetical. Beyond slopsquatting and the Postmark MCP backdoor, curl maintainer Daniel Stenberg wrote publicly in January 2025 that AI-generated ("slop") vulnerability reports had become so voluminous and low-quality that they were consuming meaningful maintainer time meant to secure real open source infrastructure — a second-order supply chain risk where AI doesn't inject malware but instead degrades the humans defending the ecosystem. Meanwhile, malware authors are using LLMs to generate polymorphic obfuscation on the fly: each downloaded copy of a malicious package can carry differently structured but functionally identical malicious code, specifically to defeat signature-based scanning — the exact detection method most legacy SCA tools still lean on. The common thread across all three examples is that none of them require a human to make a mistake in the way 2015-era supply chain security assumed. The mistake is now built into the tooling's default behavior.
What Would an Open Source Security Model Built for AI-Authored Code Actually Require?
A security model built for AI-authored code requires shifting the checkpoint from "what's declared in the manifest" to "what does this dependency actually do before and after install," evaluated continuously rather than at a single scan gate. That means four concrete shifts: first, provenance and signing (SLSA-style attestation, Sigstore) so a package's origin can be verified independent of its name; second, behavioral and runtime analysis that watches install scripts and network calls rather than trusting a version number; third, policy enforcement that sits inside the AI agent's workflow itself — at the point where Cursor, Claude Code, Copilot, or a custom agent proposes a dependency, not after it's already merged; and fourth, detection tuned specifically to AI-era patterns, including name-similarity models that flag likely hallucination targets and monitoring for the kind of tool-definition tampering seen in the Postmark MCP case. None of this replaces vulnerability databases — CVE and advisory data is still necessary — but it can no longer be sufficient on its own, because the attack surface has expanded to include the AI tooling layer that legacy SCA products were never designed to inspect.
How Safeguard Helps
Safeguard was built around the premise that the manifest file is no longer the whole supply chain, so its detection runs where legacy SCA tools stop looking. Rather than relying solely on matching declared dependencies against a known-vulnerability list, Safeguard evaluates package behavior at install and runtime — flagging unexpected network calls, obfuscated payloads, and post-install scripts regardless of whether the package has a matching CVE yet. That matters directly for AI-era threats: a hallucinated package with zero prior reputation and no CVE history still gets evaluated on what it actually does, not just what it's named. Safeguard also extends coverage to the parts of the AI development stack that traditional component intelligence platforms don't parse at all — MCP servers, agent tool configurations, and CI/CD pipelines where autonomous coding agents now commit code — closing exactly the blind spot exploited in incidents like the Postmark MCP backdoor. For teams adopting agentic coding tools, Safeguard can sit inline in the developer and CI workflow, evaluating a proposed dependency before it's installed rather than auditing it after the fact, which is the checkpoint AI-generated code actually needs. And because provenance and signing verification are built into that evaluation, teams get an answer to the question legacy tools can't: not just "is this package known-bad," but "can we prove where this package actually came from." As AI writes a growing share of the code entering production, that shift — from cataloging known threats to verifying behavior and origin in real time — is the difference between a supply chain security model built for 2015 and one built for how software actually gets written now.