Software Supply Chain Attacks Targeting DevOps Toolchains
The open-source package registry was built for trust and frictionless consumption. That design is now being systematically exploited. In 2025, according to ReversingLabs' 2026 State of Software Supply Chain Security report, open-source malware on registries grew 73%, with npm accounting for over 99% of that malicious activity. The concentration isn't incidental. npm's scale, its automatic dependency resolution, and the transitive dependency chains that ship with any non-trivial JavaScript project make it the highest-leverage distribution channel an attacker can access without ever touching a production system.
Two distinct attack patterns have matured within this environment. The first is volume flooding: a threat actor identified as IndonesianFoods published more than 150,000 malicious packages within days, deliberately overwhelming registry moderation capacity while seeding typosquatting variants at industrial scale. The goal was not precision but saturation. The second is precision poisoning, exemplified by Lazarus Group's evolution from simple malware droppers to five-stage payload chains combining initial dropper delivery, credential harvesting, and persistent remote access, all nested inside what appears to be a routine developer dependency.
The most structurally significant development is something that didn't exist before 2025: self-replicating registry malware. Shai-Hulud, the first self-replicating npm malware on record, pairs credential theft with autonomous propagation through the npm ecosystem. When malware can spread itself through a registry without further attacker action, the registry becomes part of the attack infrastructure itself. Scanning assumes the distribution system is neutral, but it isn't, and no volume of scanning addresses that.
Copycat campaigns, including Miasma, Hades, IronWorm, and GlassWorm, have already demonstrated that this propagation logic generalizes beyond npm into IDE plugin marketplaces and other developer tooling registries. For most engineering teams, the realistic exposure isn't a targeted Lazarus Group operation. It's the sheer volume of malicious packages that automated installs and transitive dependency resolution pull in without any developer awareness.
How Trusted Maintainer Accounts Become the Attack's Entry Point
What makes maintainer-account compromise so effective is also what makes it difficult to defend against: the packages being weaponized are precisely the ones developers trust most. High download counts, long maintenance histories, and widespread community adoption create confidence that functions as camouflage.
In September 2025, a single maintainer credential stolen through phishing gave attackers the ability to push malicious updates to 18 popular npm libraries, including debug, chalk, and ansi-regex. These aren't obscure packages. Combined, they accumulate billions of weekly downloads. The malicious code was live for two hours. That window sounds narrow until you think carefully about what two hours actually means across infrastructure running continuous pipelines. The blast radius isn't two hours times a handful of developers manually running installs. It's two hours times every automated pipeline globally that resolved those packages during that window, with no human in the loop to notice anything was wrong.
The Gluestack incident in the summer of 2025 followed the same structure but with a different entry point: a stolen access token rather than a phishing credential. Attackers injected backdoors into 17 npm packages. One package, @react-native-aria/interactions, recorded 125,000 weekly downloads on its own; the compromised set combined exceeded a million weekly downloads. TeamPCP, which emerged as one of the most actively identified supply chain threat groups beginning in November 2025, has built its operations around exactly this vector, targeting maintainer credentials and access tokens as the primary means of entry.
What these incidents share isn't a code vulnerability. The attack surface is identity and access management around maintainer accounts. Software composition analysis tooling that checks packages against known-vulnerable version databases offers zero protection against a freshly compromised package that was entirely clean the last time it was scanned. The threat has moved upstream of the tools most organizations have deployed. The gap between where attacks occur and where defenses are pointed isn't a subtle one.
The CI/CD Pipeline as a Credential Harvesting Target
The spring 2025 GitHub Actions attack chain is worth examining at full resolution, because the compounding leverage inside a CI/CD environment once you have a single foothold is easy to underestimate until you've traced one of these chains in its entirety.
It began with one stolen personal access token from a SpotBugs maintainer. That token provided access to the reviewdog/action-setup workflow. Compromising reviewdog then provided the foothold needed to hijack tj-actions/changed-files, a widely used action across thousands of repositories. The malicious payload injected into that action was a Python script built to hunt through pipeline environments for AWS, Azure, and Google Cloud credentials, GitHub and npm tokens, database credentials, and RSA private keys, then exfiltrate anything it found. Each compromised component yielded access to the next. The target at each step wasn't data in the traditional sense. It was credentials to everything downstream.
CI/CD pipelines are structurally appealing for this kind of chained exploitation. Build runners typically hold credentials to every environment they deploy to. Pipeline logs routinely capture secrets passed as environment variables, a practice that persists despite years of documented risk. Artifact stores sit between the build process and production, meaning a tampered artifact introduced at that layer bypasses every upstream security check that preceded it. Audits of CI/CD configurations consistently surface the same chained conditions: credentials leaked in repository history, misconfigured runners with excessive permissions, insecure artifact stores, overly permissive cloud IAM roles.
The asymmetry is genuine and it doesn't resolve with effort. Defenders must secure every link; attackers need one. Configuration drift in CI tooling amplifies this asymmetry in ways that accumulate quietly. Changes made through a Jenkins UI that never propagate to version-controlled Jenkinsfiles or YAML definitions create an undocumented configuration layer that grows silently over months. Nobody intended it. Nobody owns it. It grows invisibly until someone finds it from the outside.
Slopsquatting and the AI Code Generation Vector
Large language models don't merely write code. They recommend dependencies. Research conducted across three universities, the University of Texas at San Antonio, the University of Oklahoma, and Virginia Tech, found that LLMs demonstrate approximately a 20% rate of recommending non-existent libraries and packages. Anyone who has watched how quickly AI-assisted development gets adopted across engineering organizations, without commensurate scrutiny of what the model is actually recommending, should find that figure worth pausing on.
The slopsquatting attack model follows directly from that finding. Identify which package names popular LLMs reliably hallucinate, register those names in the relevant registry, and wait. This is structurally different from typosquatting, and the difference matters operationally. Typosquatting exploits human error: random, individual, stochastic. Slopsquatting exploits model behavior: deterministic and consistent across millions of prompts from the same or similar models. The same hallucination recurs because the model's training distribution consistently generates the same plausible-sounding but nonexistent package name. An attacker doesn't need a wide net. They need to know what the model believes, then register it first.
The developer behavior that enables this is the same behavior that makes AI-assisted development productive: faster dependency adoption, less friction, and frequently less scrutiny than a deliberate unassisted decision would entail. As AI tooling penetrates deeper into development workflows, the rate at which unvetted dependencies enter codebases increases proportionally. This vector requires no attacker sophistication. It requires only knowledge of model behavior and a willingness to register a name before anyone else does. It scales with AI adoption, not with attacker resources.
Why Environment Drift Makes All of These Attacks Harder to Detect and Easier to Sustain
If the same source code doesn't produce a bit-for-bit identical artifact across builds, then any malicious injection at the build layer becomes functionally indistinguishable from routine environmental variation. That's the core detection problem, and it compounds quietly over time.
The mechanism is familiar to anyone who has spent time in production operations. A hotfix applied directly to a server during an incident. An environment variable added during a postmortem and never formalized. A scaling rule tweaked and not reverted. A CI runner image updated outside of version control. Each change is individually defensible, often defensible in the moment. Collectively, over weeks and months, they produce a runtime configuration that no single person fully understands and that differs materially from what the version-controlled definitions describe. When incident responders attempt to reconstruct the state of a build environment at the moment of compromise, drift makes that reconstruction unreliable, sometimes impossible. I've seen incident timelines fall apart at exactly this point, not because the logs were missing but because nobody could say with confidence what the environment had actually been.
Artifact signing doesn't solve this. A cryptographic signature proves the artifact was not tampered with after signing. It says nothing about whether the build environment that produced the artifact was clean. A compromised build runner generating a signed artifact produces a signed, compromised artifact. Integrity and provenance are different guarantees, and conflating them shows up repeatedly in how organizations describe their security posture to each other, often in ways that create false confidence upstream.
Reproducible builds address the underlying problem directly. When two developers, starting from the same environment definition on different systems on different days, produce the exact same artifact, deviations become detectable signals rather than background noise. This is the technical precondition for trustworthy artifact provenance. The configuration drift specific to CI tooling, click-operations changes that never reach version control, is the most common and consequential instance of this broader problem. It's also the specific condition the GitHub Actions attack chain exploited.
What SBOMs Actually Provide, and Where They Fall Short Without Provenance
A Software Bill of Materials is a machine-readable nested inventory of all software components and dependencies in a given artifact. The operational case is well established. When Log4Shell surfaced, organizations with SBOMs identified affected applications within minutes. Organizations without them spent days or weeks doing manual discovery work. That time differential is quantifiable exposure, and the organizations on the wrong side of it knew it.
The regulatory environment has accelerated SBOM adoption from a best practice to a compliance requirement. US Executive Order 14028 requires SBOMs for software sold to federal agencies. The EU Cyber Resilience Act (Regulation EU 2024/2847) places mandatory cybersecurity requirements on digital products throughout their lifecycle, with initial deadlines arriving in September 2026. CISA's 2025 updated minimum elements guidance explicitly requires flagging components of unknown provenance. Gartner predicted that by 2025, 60% of organizations building or procuring critical infrastructure software would mandate SBOMs, up from less than 20% in 2022. Organizations still treating SBOMs as optional are making a decision that regulators will eventually make for them.
The two dominant standards, SPDX and CycloneDX, serve different primary consumers. SPDX prioritizes license metadata and rich provenance fields; CycloneDX emphasizes security use cases and vulnerability database integration. Selecting between them is a question of who consumes the SBOM and for what purpose, not a question with a universal answer.
Where SBOMs fall short is documented but consistently underemphasized in implementation guidance. A point-in-time SBOM generated at release goes stale immediately. Dependencies change, environments drift, vulnerabilities emerge. Alert fatigue from scanners that can't distinguish exploitable findings from theoretical ones degrades trust in the tooling over time. Most critically, an SBOM without provenance attestations and cryptographic signatures can demonstrate what is in the software but can't demonstrate where it came from or whether the build process was clean. The inventory is necessary, but without provenance, it's insufficient.
The Pipeline Bill of Materials concept addresses the staleness problem by continuously tracking dependencies, configurations, and build pipelines across every build and release event. SBOMs generated at image build time, capturing the full dependency tree including operating system packages and build tooling, treat the build environment itself as part of the inventory. That inclusion isn't a refinement. The build environment is where the most consequential attacks occur.
The MCP Ecosystem as an Emerging Supply Chain Attack Surface
The Model Context Protocol crossed 97 million downloads before most enterprise governance frameworks had formally acknowledged its existence. The speed of adoption reflects genuine utility; MCP solves a real integration problem for AI agent deployment. That speed has also produced a gap between deployment scale and governance maturity that looks, structurally, exactly like every other supply chain risk surface before it was well understood. The pattern isn't new. The substrate is.
MCP's function is to allow AI agents to call registered servers that expose interfaces the model can interpret, eliminating hard-coded integration logic for every external service. This creates a generalized trust relationship between an agent and the tools it can invoke, and that generalized trust is the attack surface.
In April 2025, Invariant Labs published a disclosure on MCP tool poisoning attacks, demonstrating that malicious MCP servers can return instructions that manipulate agent behavior, exfiltrate data, or redirect actions without developer or user awareness. An agent treating an MCP server's responses as authoritative is making the same trust assumption a developer makes about packages pulled from npm: that because the channel is trusted, the content must be. That assumption is the same one being exploited across every attack pattern described here, and there's no structural reason to expect the MCP ecosystem to be immune simply because it's newer.
The enterprise governance gap is familiar to anyone who watched CI/CD security mature. Organizations centralizing AI agent deployment through internal enablement teams often lack tooling to track which MCP servers are running, what versions those servers use, or what actions they're performing. The governance requirements that close this gap parallel software supply chain controls precisely: verifying that the right models can call the right tools with the right permissions, tracking MCP server versions with the same rigor applied to npm dependencies, auditing what actions MCP servers perform with the same scrutiny applied to artifact provenance.
AI agents are first-class pipeline participants. They run in environments, consume dependencies, call external tools, and produce artifacts. Applying less security rigor to their environment than to a human developer's build environment is an inconsistency, and supply chain attackers are specifically looking for inconsistencies in trust models.
What Treating the Pipeline as the Primary Defense Perimeter Requires in Practice
Security controls that live outside the pipeline are structurally late. Perimeter firewalls, endpoint detection agents, and post-deployment scanning all operate after the build has completed, after the artifact has been signed, and, in most supply chain compromise scenarios, after the malicious payload has already propagated through the environments consuming it. Those controls remain necessary. They're simply the wrong primary perimeter for this threat class, and organizations that position them as primary are accepting a structural disadvantage they may not have explicitly chosen.
Environment integrity is the first-line control because it makes tampered build environments visible rather than invisible. Reproducible, version-controlled environment definitions create a known-good state from which any deviation is a detectable signal. The same definition a developer runs locally should produce the same environment in CI. Closing the "works on my machine" gap and closing the gap between what was tested and what was built are the same operation, addressed by the same mechanism.
SBOMs must be generated at build time from the reproducible environment, not retrofitted after the fact from static analysis of artifacts. A retrofitted SBOM reflects what the artifact contains. A build-time SBOM reflects what produced it. Only the latter supports provenance claims that carry operational weight against supply chain attacks.
Dependency pinning and verification must cover the entire graph, including direct dependencies, transitive dependencies, build tools, base images, and, increasingly, MCP servers called by agents operating within the pipeline. Pinning to a version without verifying a cryptographic hash provides limited protection. A version number is a pointer. It can be moved, and in documented attacks, has been.
Maintainer account security is infrastructure security. The September 2025 phishing incident and the Gluestack access token compromise demonstrate that two-factor authentication, hardware security keys, and short-lived token policies for package registry access are boundary controls on the most exploitable entry point in the software supply chain. Organizations can't mandate these controls on third-party maintainers, which is precisely why they must verify rather than trust, and why provenance attestations from maintainers who do implement them carry genuine operational weight. The pipeline is where the threat lives now, and the defenses belong there too.
