The rules are simple on a boat. Really simple. Keep the water out and the people in. That is a simple truism, and for some reason everybody is trying to break that rule every damn day. Another reasonable rule: if it is supposed to allow water in and doesn’t, it’s an impeller, and if it is not supposed to allow water in and does, it’s an o-ring. Simple to understand, right?
Well, here is a rule about information technology. If you have a tool, software or hardware, in your environment, it represents an attack surface. Whether you own it or not, you have the unenviable requirement to make sure it is securely configured and patched.
Now apply that to AI. All the roll-your-own IT, the AI-generated stuff, and the AI-operated stuff are all subject to the same likely unsecured infrastructure. How you manage this side of the operation is problematic at best. After my first drink, I keep coming back to this: AI can generate additional attack surface without you knowing about it. We need to know what AI is creating, and we need to know about it as soon as it happens.
Threat Model
The software supply chain attack is not new. SolarWinds happened in 2020. The 3CX compromise in 2023 hit a vendor whose software served more than 600,000 companies. The XZ Utils backdoor nearly slipped a suspected nation-state implant into major Linux distributions in 2024. What has changed is the cost structure. The operations that used to require patient, skilled humans working for months can now be partially automated, scaled out, and made to look natural by the same large language models your developers use to write code.
An AI-augmented supply chain attacker operates across four vectors, sometimes in parallel, sometimes in sequence, and often through the same developer tooling your organization already trusts.
The first vector is poisoned packages. Sonatype’s 2026 State of the Software Supply Chain report counted more than 454,600 new malicious packages discovered in 2025 alone, bringing the cumulative total past 1.2 million across npm, PyPI, Maven Central, NuGet, and Hugging Face. Phoenix Security’s tracking showed the first half of 2026 producing 2.6 times the campaign volume and 4.5 times the package volume of the entire preceding year. The scale has gone industrial, and in my judgment a growing share of that industrialization is AI-assisted. Attackers use LLMs to generate plausible package names, write convincing README files, populate repositories with realistic commit histories, and produce code that looks functional while hiding a data exfiltration payload in a post-install script. The packages don’t need to be good. They need to survive a five-second glance from a developer or, increasingly, no glance at all because an AI coding assistant chose the dependency without asking.
That last sentence matters more than it might seem. A 2025 USENIX study tested 16 code-generating models and found they hallucinated nonexistent package names in 19.7% of the packages they recommended. Commercial models averaged at least 5.2%, while open-source models averaged 21.7%. Attackers have figured this out. The technique is called slopsquatting: register the package names that LLMs are most likely to hallucinate, then wait for the AI assistant to recommend your poisoned package to a developer who never typed the name themselves. The Cloud Security Alliance documented real-world examples in early 2026, including an npm package called “unused-imports” that mimicked what models hallucinate instead of the legitimate eslint-plugin-unused-imports. It accumulated hundreds of weekly downloads, and many of those installs came from automated pipelines where no human reviewed the dependency list.
The second vector is AI-generated pull requests and contributions. The XZ Utils attack demonstrated the playbook in analog form: a patient contributor builds trust over two years, then inserts a backdoor. AI compresses that timeline. An attacker can generate dozens of plausible, helpful-looking contributions across multiple repositories, building a commit history that looks like a real developer’s. The pull requests fix real bugs, improve real documentation, and add real test coverage. Somewhere in the middle of that stream, buried in what looks like a refactoring commit, sits the payload. Reviewing AI-generated code is harder than reviewing human-written code because AI-generated code is stylistically consistent, syntactically clean, and formatted in ways that pattern-match against what a reviewer expects to see. The malicious logic doesn’t stand out because it’s written in the same voice as everything around it.
The third vector is dependency confusion. Alex Birsan demonstrated this in 2021 against Apple, Microsoft, and PayPal, and the technique remains effective in 2026. If your organization has internal packages and hasn’t reserved those names on public registries, an attacker who publishes the same name on npm or PyPI with a higher version number can trick your package manager into pulling the public version. AI accelerates the reconnaissance phase. An attacker can use LLMs to parse job postings, GitHub profiles, leaked CI configurations, and public documentation to identify likely internal package names for a specific target. In May 2026, Microsoft documented a campaign where a threat actor published 33 malicious npm packages across nine organizational scopes using dependency confusion, with packages spoofing internal enterprise URLs in their package.json to look legitimate.
The fourth vector is trojanized updates to legitimate packages. The Shai-Hulud npm worm, discovered in September 2025, was the first self-replicating supply chain worm found on npm. Once installed on a developer’s machine, it searched for npm tokens, authenticated as that maintainer, and published trojanized versions of the packages that person maintained. The first wave hit more than 500 packages, including dependencies with millions of weekly downloads. The TeamPCP campaign in 2026 compromised the Trivy security scanner’s release infrastructure, then used a stolen publishing token to upload malicious versions of LiteLLM, a popular AI gateway library, to PyPI. The Keyv npm worm of August 2026 poisoned as many as 868 packages and planted persistence hooks targeting Claude Code and VS Code, turning AI coding agents themselves into an execution vector. Every one of these attacks passed standard provenance and signature checks before deployment.
The attacker for this chapter is someone with access to LLMs, a basic understanding of package ecosystems, and the patience to register accounts on npm or PyPI. They don’t need zero-days. They don’t need to breach your network. They need your build pipeline to pull a package from a public registry, which it does hundreds of times a day.
Traditional Tools
Most organizations that take supply chain risk seriously have deployed some combination of the following. None of these tools are failures. They were designed for a threat environment that existed until recently, and they do what they were built to do.
Software Composition Analysis tools are the backbone of most supply chain security programs. Products like Black Duck, Snyk, Mend, and Checkmarx SCA scan your manifest files, lock files, and sometimes your binaries to identify every open-source component in your application. They compare that inventory against vulnerability databases, primarily the National Vulnerability Database, and flag components with known CVEs. They generate Software Bills of Materials in standard formats like SPDX and CycloneDX. They track licenses for compliance. The better ones offer reachability analysis, which tells you whether a vulnerable function is actually called in your code. In my experience, that removes most of the noise, because the large majority of flagged vulnerabilities aren’t reachable in your specific build.
Package registries and repository managers sit between your developers and the public registries. Artifactory and Nexus let you proxy npm, PyPI, and Maven Central through an internal server, cache approved packages, and enforce policies about what can enter your build environment. Some organizations run these as gatekeepers, allowing only packages that have been reviewed and approved. Others run them as caching proxies with minimal policy enforcement, which provides speed but limited security.
Dependency pinning and lock files are configuration practices, not products, but they matter. A package-lock.json or poetry.lock file records the exact versions and hashes of every dependency resolved at build time. When enforced correctly, pinning prevents the build from silently upgrading to a newly published (and potentially malicious) version. Most organizations pin their direct dependencies. Fewer pin their transitive dependencies consistently.
Code review processes, whether manual or tool-assisted, catch some malicious contributions before they merge. GitHub branch protection rules, required reviewer counts, and CODEOWNERS files create gates around the merge path. Static analysis tools like Semgrep and CodeQL scan pull requests for known vulnerable patterns. These gates are designed for a world where contributions come from humans whose output has a recognizable variance in style, quality, and intent.
Build provenance and signing frameworks like SLSA (Supply-chain Levels for Software Artifacts) and Sigstore are the newest layer in the stack. The current SLSA specification (v1.2) defines a Build track with levels 0 through 3, from provenance that simply exists at Build L1 to a hardened build platform at Build L3, and v1.2 added a separate Source track. Sigstore enables keyless signing by tying artifact signatures to OIDC identities, eliminating the need to manage long-lived signing keys. Both are mature enough for production use. Both provide verifiable proof that a specific artifact was built from a specific source commit by a specific build system.
Together, these tools give you a known-vulnerability inventory, a gatekeeper for package ingestion, version pinning against surprise upgrades, human review of contributions, and cryptographic attestation of build integrity. Five years ago, this was a strong supply chain security program.
The Gap
Every tool in that inventory relies on one foundational assumption: human-speed operations generate human-recognizable signals. SCA tools assume malicious packages will eventually be reported, assigned a CVE, and appear in a vulnerability database. Repository managers assume the list of approved packages changes slowly enough for a human to curate it. Dependency pinning assumes the dependencies were safe when they were first pinned. Code review assumes contributions arrive at human pace, in human quantity, with human variation in quality. Build provenance assumes the upstream source being attested is itself trustworthy. AI removes the constraint that made every one of those assumptions hold, and it does so across all five simultaneously.
Start with SCA. The tool works by matching component identifiers against a database of known vulnerabilities. The operative word is “known.” In 2025, Sonatype found that 64% of open-source CVEs in the NVD were not assigned CVSS scores. That gap is about the pace of documentation, and it existed before AI entered the picture. What AI changes is the pace of creation. When attackers can generate hundreds of unique malicious packages per week, each with a different name, each with different obfuscation, the window between publication and detection grows relative to the volume. Your SCA tool will eventually flag these packages. The question is whether “eventually” comes before or after your CI pipeline has already pulled and executed one. The Shai-Hulud worm demonstrated this gap in practice: the trojanized versions of legitimate packages passed SCA checks because the package identity and version lineage looked correct. The malicious code was injected into a package your SCA tool already trusted.
Repository managers and approval gates have a curation constraint. They assume someone reviews what goes into the approved list and that the list changes at a pace humans can manage. AI coding assistants generate dependency requests at machine speed. A developer using Copilot or Claude Code might introduce five new dependencies in an afternoon. An AI agent running autonomously in a build pipeline might introduce dependencies without any developer seeing them at all. Andrew Nesbitt, a package management researcher, observed in April 2026 that agents resolve packages programmatically without a human glancing at the name to notice something is off. The agent generates code, identifies its own dependencies, and invokes the package manager. Post-install scripts in agentic contexts execute in environments that typically hold API keys, cloud credentials, and source control tokens.
Code review gates were designed for the natural variance in human output. When a human contributor writes a backdoor, it tends to look different from the surrounding code. The style is slightly off, or the logic is unnecessarily complex, or a function does something unrelated to the commit message. AI-generated code removes that variance. Every line reads the same. The malicious logic is written in the same syntactic style as the legitimate code around it, because the same model wrote both. Code review, whether by humans or by static analysis tools trained on pattern matching, operates on the assumption that malicious intent produces recognizable deviation. When the deviation disappears, the review becomes a check on functionality rather than intent.
Build provenance and SLSA attestation verify that an artifact was built from a specific source by a specific builder. They do not verify that the source itself is safe. A SLSA Level 3 attestation on a package built from a repository containing a backdoor is a cryptographically signed statement that yes, this backdoor was built exactly as intended. The TeamPCP campaign exploited this directly: the attackers compromised the Trivy release infrastructure, which meant the malicious LiteLLM packages were built and signed through the legitimate build pipeline. The provenance was genuine even though the artifact was malicious. SLSA answers “was this artifact built correctly?” and says nothing about “should this artifact have been built at all?”
The constraint that held these tools together was speed. Attackers published malicious packages slowly enough for databases to catch up, submitted contributions rarely enough for reviewers to be thorough, and compromised build systems infrequently enough for provenance to mean something. AI removed the speed constraint. The tools still work, but they’re defending against yesterday’s production rate while today’s attackers operate at a volume and velocity that exceeds what the tools were calibrated for.
AI Augmentation
The defense has to address each of the four attack vectors, and it has to do so using what you already have. None of what follows requires a new platform purchase. All of it can be prototyped by a small team in a week using API calls, scripts, and existing log infrastructure.
Automated dependency analysis with behavioral profiling. Your SCA tool tells you what packages you have and whether they carry known CVEs. What it doesn’t tell you is whether a package behaves differently from what its stated purpose suggests. Build a script that runs against every new or updated dependency before it enters your build environment. The script pulls the package, extracts the code, and sends it to an LLM via API with a structured prompt: “This package claims to be a date formatting library. Analyze the code and identify any behavior that is inconsistent with that stated purpose. Specifically flag: network calls to external hosts, file system access outside the package directory, environment variable reads, credential access patterns, and obfuscated code segments.” Cross-reference the LLM’s analysis against the package’s declared permissions, its dependency tree, and its install scripts.
This is not a replacement for SCA. It’s a behavioral layer that catches what known-vulnerability matching cannot: a brand-new package with zero CVE history that does something its description says it shouldn’t. Run it as a pre-merge gate in your CI pipeline. If the behavioral analysis flags something, quarantine the package and route it to a human for review.
The dependency risk is real and specific. Your behavioral analysis is only as good as the model’s ability to read code accurately. LLMs can be fooled by sufficiently obfuscated payloads, particularly in languages with complex metaprogramming features. The manual fallback is a quarantine queue: any package that the model can’t confidently assess goes to a human reviewer, and the build blocks until that review is complete. If the LLM API is unavailable, the pipeline holds all new dependencies for manual review, which is slow but not blind.
Behavioral analysis of build pipelines. Your CI/CD system produces logs. Most organizations ship those logs to a SIEM and never look at them unless something breaks. Build a monitoring layer that watches for anomalous build behavior, not vulnerability signatures. The specific signals to track: dependencies resolved from registries that aren’t in your approved list, packages installed that don’t appear in the lock file, post-install scripts that make network connections, build steps that access secrets they haven’t historically accessed, and build durations that deviate significantly from the baseline for that project.
Feed those signals to an LLM with context about your normal build patterns. The model doesn’t need to understand your entire codebase. It needs to identify when a build does something it hasn’t done before, particularly when that something involves network access, credential access, or file system writes outside the build directory. Alert the on-call engineer when the model flags a deviation.
The dependency risk here is that your build monitoring becomes a single point of failure. If an attacker knows you’re running behavioral analysis on build pipelines, they can test their payloads in similar environments before deployment, looking for patterns that won’t trigger your model. The manual fallback is straightforward: maintain a log review checklist for builds that deploy to production, and review those logs on a regular cadence whether the model flags anything or not. The automated system handles volume, and the periodic human review serves as an independent check against whatever the model fails to flag.
AI-assisted code review of upstream changes. This applies to any dependency where you have access to the source repository, which for open-source dependencies means most of them. Set up a monitoring process that watches for new releases of your top-tier dependencies (the ones that, if compromised, would give an attacker access to your production environment or sensitive data). When a new release drops, pull the diff between the previous version and the new one. Send the diff to an LLM with a prompt focused on behavioral change: “Compare the previous release to this release. Identify any new behaviors that were not present in the previous version. Specifically flag: new network calls, new file system access patterns, new environment variable reads, new dependencies added, changes to install or build scripts, and any code that appears to be obfuscated or unnecessarily complex for its stated function.”
The model’s output is a behavioral change report. Route it alongside the standard SCA scan results when the dependency upgrade enters your review queue. This doesn’t replace looking at the diff. It gives the reviewer a focused analysis that highlights where to look first.
Restrict this to your critical dependencies, not every package in your tree. If you have 400 direct dependencies, you probably have 20 that matter enough to warrant this level of scrutiny. Those are the packages with broad permissions, deep access to your runtime, or a position in your build pipeline where a compromise propagates downstream to production.
The dependency risk is cost and latency. Running every upstream release through an LLM analysis takes API tokens and time. For a small team, limiting this to your critical dependency list keeps the cost manageable. If the LLM service is down, the fallback is the diff itself: the reviewer reads the raw changes without the AI summary. This is slower and more prone to missing subtle behavioral shifts, but it’s what you were doing before you had the augmentation.
Slopsquatting detection. This one is specific to organizations using AI coding assistants. Monitor the packages your developers install and compare them against a curated list of known-legitimate packages. When a developer or an AI agent installs a package you haven’t seen before, run a validation check: does this package exist on the public registry? How long has it existed? How many downloads does it have? How many contributors? Does its name closely resemble a well-known package? Is it a known hallucination target?
Build this as a lightweight post-install hook or a CI gate. The logic is simple conditional checking against your approved package list, combined with an LLM query to assess whether the package name is a plausible hallucination of a legitimate package. Maintain a running list of packages your AI coding tools recommend, and periodically audit that list against the registry. If a recommended package has fewer than a thousand downloads, fewer than five contributors, and was published within the last 90 days, it needs a human look before it enters your build.
The dependency risk is false positives, because legitimate new packages also have low download counts and few contributors. The mitigation is to use the age and popularity check as a triage filter, not a block. Route flagged packages to a review queue rather than rejecting them outright. If the validation system goes down, the fallback is a hard block on any package not in your approved list, which will slow developers down but won’t leave you exposed.
Scope-locking your registries. This item is a configuration fix, and it belongs here because it addresses the dependency confusion vector that AI-driven reconnaissance makes cheaper to exploit. For every internal package scope your organization uses, configure your .npmrc (or pip.conf, or settings.xml) so those scopes resolve exclusively to your private registry and never fall back to the public registry. Microsoft said exactly this in their May 2026 advisory after documenting the 33-package dependency confusion campaign. This is not a new recommendation. It has been standard guidance since 2021. The number of organizations that still haven’t done it is staggering, and AI-driven reconnaissance of job postings, GitHub profiles, and leaked CI configs makes identifying target scopes easier than ever.
There’s no dependency risk to this one. It’s a configuration change. The manual fallback is the same as the automated control: the registry resolves to your internal server or it doesn’t. Do it today.
The supply chain is a surface you monitor continuously, and the monitoring has to run at the same speed as the threat. Your SCA tool, your repository manager, your lock files, your code review process, and your build provenance framework all still matter. They form the base that these augmentations build on. What they can no longer do alone is keep pace with an adversary whose cost of producing convincing, functional, malicious packages dropped by an order of magnitude in the last two years. The augmentations described here are cheap, scriptable, and designed to sit inside pipelines you already run. They won’t make you invulnerable, but they’ll make you faster than the tools alone can be, and that speed gap is now the minimum viable defense.
Works Cited
Cloud Security Alliance AI Safety Initiative. (2026, March 31). TeamPCP: Cascading PyPI attack on AI/ML infrastructure. https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-ml-pypi-supply-chain-attack-teampcp-202
Cloud Security Alliance. (2026, April 25). Shai-Hulud npm worm and the AI developer supply chain [Research note]. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_shai-hulud-npm-worm-ai-developer-supply-chain_20260425-csa-styled-2.pdf
Microsoft Threat Intelligence. (2026, May 29). 33 malicious npm packages abuse dependency confusion to profile developer environments. https://microsoft.com/en-us/security/blog/2026/05/29/33-malicious-npm-packages-abuse-dependency-confusion-profile-developer-environments
Nesbitt, A. (2026, April 24). AI vs package management [Conference presentation]. KTH Software Supply Chain Workshop, Stockholm. https://chains.proj.kth.se/workshop_5_assets/slides/ai_vs_package_management.pdf
Phoenix Security. (2026). The acceleration: How supply chain attacks went industrial. https://phoenix.security/whitepapers-resources/supply-chain-acceleration-report-2026/
SLSA. (2025). Build: Track basics (Version 1.2). https://slsa.dev/spec/v1.2/build-track-basics
Sonatype. (2025, November 20). Trust issues: The CVE crisis. https://www.sonatype.com/resources/research/the-cve-crisis
Sonatype. (2026, January 28). 2026 state of the software supply chain report [Reported in Infosecurity Magazine, “Researchers uncover 454,000+ malicious open source packages”]. https://www.infosecurity-magazine.com/news/454000-malicious-open-source/
Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., & Viswanath, B. (2025). We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs. In 34th USENIX Security Symposium. https://www.usenix.org/conference/usenixsecurity25/presentation/spracklen
The Hacker News. (2026, August). Keyv-linked npm worm poisons hundreds of packages. https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html
About the Author
