Software Supply Chain Attacks in the Wild

Supply chain attacks surged 431% between 2021 and 2023, according to Cowbell Cyber. Since April 2025, the pace has averaged more than 28 attacks per month, more than double the 13 monthly attacks documented in early 2024 through March 2025. In October 2025, Cyble recorded 41 attacks in a single month, more than 30% above the previous peak. These aren't outliers. The acceleration is the baseline.

Of the 79 cyberattacks with supply chain implications documented in the first five months of 2025, 63% directly targeted IT, technology, and telecommunications companies, and 22 of the 24 sectors Cyble tracks were affected. More than 75% of organizations reported experiencing a supply chain attack within the last year, per BlackBerry's 2024 research. The 2025 Verizon Data Breach Investigations Report found that 30% of breaches now involve a third party, up from 15% previously. Only one in three organizations feels prepared to defend against supply chain threats, according to Ivanti's 2025 findings.

Each software application carries, on average, 150 dependencies, 90% of which are indirect. Every transitive dependency is a trust relationship the consuming team didn't explicitly choose and, in most cases, can't fully enumerate without dedicated tooling. IBM's 2025 Cost of a Data Breach Report puts the average supply chain breach at $4.91 million globally and $10.22 million in the United States. Cybersecurity Ventures projects global annual costs reaching $138 billion by 2031, up from $60 billion in 2025.

The attack surface isn't expanding because defenders are negligent. It's expanding because the software ecosystem is structurally additive — more dependencies, more maintainers, more pipelines, more points of exposure accumulating with every release cycle. The math doesn't favor defenders unless organizations change the architecture of trust itself.

Why Attackers Have Largely Abandoned Typosquatting in Favor of Build-Time and Account-Takeover Vectors

The early era of supply chain attacks relied on a crude but effective technique — register a package name close to a popular one, wait for developers to mistype it, and deliver malicious code. That era is largely over. Discovered malware instances dropped by more than 85% on PyPI from 2023 to 2024, and typosquatted packages across open-source platforms declined by more than 70% in the same period. Platforms tightened policies, automated detection improved, and that particular entry point mostly closed.

What replaced it is more sophisticated and considerably harder to catch.

Build-time injection, as demonstrated by SolarWinds, is one dominant vector. The artifact is clean at its source, malicious at delivery, and no downstream scanner will catch the difference because the dependency inventory looks correct. Account takeover of legitimate maintainers is another. In 2025 npm incidents, packages with hundreds of thousands of weekly downloads were compromised after maintainer accounts protected only by SMS-based MFA were taken over; the malicious version was delivered with full registry legitimacy, indistinguishable from a routine update. CI/CD pipeline compromise rounds out the picture. In the GhostAction incident in early 2025, attackers modified the workflow code of a widely-used GitHub Action to exfiltrate secrets from downstream pipelines. Because repositories had pinned the action by tag rather than commit SHA, every reference to @v1 automatically pulled the compromised version, exposing tens of thousands of repositories, many holding production deployment credentials.

There's also an emerging frontier that most security teams haven't yet turned to face — AI model poisoning. Embedded Python code can execute when a model loads, enabling malicious command execution or data exfiltration. This extends supply chain risk into the ML artifact layer, a domain that few existing scanning and provenance tools cover adequately. It won't remain an edge case.

What unites all of these vectors is assumed trust — a tag, a maintainer identity, a model file. None of them involves a technically vulnerable component in the traditional CVE sense. That distinction has real consequences for how organizations structure their defenses, and most are still structured around a threat model that no longer matches what's actually happening.

What an SBOM Actually Tells You — and What It Doesn't

A Software Bill of Materials is a machine-readable inventory of every component and dependency used to build a piece of software. It enables vulnerability scanning, license compliance auditing, and risk assessment. It's a necessary artifact. It is not a sufficient defense, and conflating the two is one of the more consequential mistakes organizations are making right now.

CISA's 2025 draft update to the Minimum Elements guidance raised the baseline, requiring component hash, license, tool name, and generation context, while clarifying existing fields like SBOM author and component version. In September 2025, CISA, the NSA, and 19 international partners released joint SBOM guidance, signaling that the expectation is now globally coordinated rather than a U.S.-specific compliance checkbox. The regulatory trajectory is clear and unlikely to reverse.

The adoption reality is messier than leadership believes. A 2023 survey found that 92% of large enterprises reported planned or implemented SBOMs per their IT directors. A more recent survey found that nearly half of security professionals believe their organizations are behind on EO 14028 and Cyber Resilience Act compliance. That gap between executive confidence and practitioner experience is a reliable warning sign. Most SBOMs currently don't achieve full compliance with even minimum data fields; few include license information, hashes, or supplier names. I've seen this pattern repeat across organizations of substantially different sizes and maturity levels.

The hard limit of an SBOM is architectural, not a quality problem that better tooling will eventually fix. In a SolarWinds-class attack, the SBOM would have listed every component as clean, because the compromise happened inside the build environment after the dependency was ingested. The bill of materials documents the ingredients; it cannot tell you what happened in the kitchen after they arrived.

VEX, the Vulnerability Exploitability eXchange format, is a useful companion. A VEX document attests whether a known vulnerability in a dependency is actually reachable in a given product, which addresses the alert fatigue problem that plagues SBOM-driven scanning programs. But VEX doesn't address provenance. The SBOM market is projected at $1.318 billion in 2025, growing at a 24% compound annual growth rate through 2033, driven primarily by regulatory mandates in healthcare, government, and finance. That investment is well-directed as far as it goes. The problem is that "as far as it goes" leaves the build environment entirely unaddressed, and that is precisely where the most consequential recent attacks have operated.

Provenance and Build Integrity: What Fills the Gap SBOMs Leave Open

Provenance answers a different question than an SBOM. Not "what components are in this artifact" but "where did this artifact come from, who built it, from what source commit, and using what process." The distinction is the difference between a receipt and a chain of custody. One tells you what you bought; the other documents where it's been and who touched it between origin and delivery.

The SLSA framework, Supply-chain Levels for Software Artifacts, developed at Google, defines progressively stronger build integrity guarantees across three levels. SLSA v1.2, released in November 2025, added a Source Track alongside the existing Build Track, making it the first version to cover source code provenance as well as build provenance. This matters directly because the XZ Utils attack exploited the source layer; the malicious contribution was introduced before any build system could observe it. SLSA v1.2 is the first version of the framework with meaningful purchase on that attack surface.

Sigstore's keyless signing model has materially reduced the friction of artifact signing. Publishers authenticate via OIDC, typically through a CI provider identity such as GitHub Actions, receive a short-lived certificate from Fulcio, sign the artifact, and the signature is recorded in the Rekor transparency log. Consumers verify against the log without managing a key set. The infrastructure is in production use and the operational burden is low. There's no longer a credible argument that artifact signing is too complex to require.

npm's provenance implementation applies this model to package publishing. The --provenance flag generates an attestation that includes the source repository URI, the commit hash, and the build instructions used. It directly addresses the account-takeover vector by tying a package release to the specific build pipeline that produced it, not merely to the account that published it.

The GhostAction incident provides the sharpest practical lesson here. Tag-based pinning provides no integrity guarantee. Commit SHA pinning means a repository will only execute the exact code that was reviewed at a specific point in time. This is the single most actionable hardening step available to most CI/CD pipelines today, requiring no new tooling, no procurement cycle.

Reaching SLSA Level 2 for most artifact types is achievable in weeks using GitHub's built-in attestation support, cosign, and the slsa-github-generator project. Policy as code closes the enforcement loop. Kubernetes Admission Controllers, OPA/Gatekeeper, and Kyverno can all be configured to reject deployments where the image lacks verifiable provenance matching the declared build source. This turns provenance from an audit artifact into a deployment gate, which is the only version of provenance that actually changes attacker economics.

How Build Environment Integrity Connects to Supply Chain Security

SolarWinds illustrated the point as clearly as any incident could. The build environment was the attack surface, not a dependency. Attackers injected Sunburst into the Orion build pipeline before the artifact was signed; the resulting software was legitimate by every outward measure, signed with Orion's own certificate. Most security checklists still treat the build environment as infrastructure rather than as a trust boundary requiring the same rigor as the software it produces. That discrepancy is not a minor oversight.

Environment drift is the mechanism by which this trust boundary erodes quietly. When development, CI, and production environments use different tool versions, different transitive library versions, or different compiler flags, the organization loses the ability to reason about what actually ran during any given build. Manual configuration files, READMEs, and requirements.txt equivalents describe intent, not actual state. The environment running in CI may not match what any developer has on their laptop, and absent a mechanism to verify that, any discrepancy is invisible until it produces something nobody can explain.

The Nix functional package model addresses this structurally. Nix pins every dependency to a cryptographic hash; the environment definition is itself a provenance artifact. Two developers or two CI runners executing the same Nix environment definition get bit-for-bit identical toolchains. This eliminates the class of ambiguity that masks subtle compromises and produces the "worked in my environment" explanations that precede incidents that nobody fully reconstructs afterward. Deviations become visible, which is what makes reproducibility a security property rather than a development convenience.

Flox, built on Nix, extends this model into a practical workflow tool. A developer or CI runner can be onboarded with a single command and receive the same pinned, hash-verified environment across laptops, CI nodes, and production systems. The security property is that environment consistency becomes a supply chain control — an attacker who modifies a build tool or injects a step into the environment leaves a verifiable trace against the known hash. That's a materially different regime from what most organizations operate in today.

Why CI/CD Pipelines Are Now a Primary Target and How to Harden Them

CI/CD pipelines concentrate risk in a way that few other components of the software delivery system do. They hold repository secrets, deployment credentials, cloud provider tokens, and signing keys. They execute arbitrary third-party code, in the form of Actions, orbs, and plugins, with broad permissions, at a cadence that matches or exceeds the pace of development. They are, in practical terms, the most powerful systems in most engineering organizations, and they're routinely under-governed relative to that power.

GhostAction is the canonical case. The compromised action had millions of weekly uses across tens of thousands of repositories. Because it was pinned by tag, every downstream pipeline pulled the malicious version automatically, with no developer decision required. The exposure was a function of a convention that most teams adopted for convenience and never re-examined, because nothing had gone wrong yet. In this domain, that reasoning is a liability at scale.

The hardening controls that address the actual attack vectors documented in the wild are specific. Pin all third-party Actions and dependencies to commit SHA rather than tags or floating version references; this single change would have neutralized the GhostAction attack for any repository that had done it. Enforce least-privilege secrets scoping — a build job that doesn't deploy to production shouldn't hold production credentials, and most pipelines aren't structured this way by default. Treat the CI runner environment as a supply chain artifact in its own right, pin it, hash it, and audit changes to it on the same cadence as application dependencies.

When the CI environment is defined as code, via a tool like Flox or a Nix-derived toolchain, every run is verifiably identical and the expected environment hash is known. Secrets exfiltration via environment mutation becomes detectable because the mutation produces an observable deviation from that hash. This is an operational property, available to any team willing to treat the build environment with the same seriousness they apply to the application it produces.

The Organizational Gap: Why Knowing About Supply Chain Risk Has Not Translated Into Preparedness

The gap between IT director confidence and security practitioner experience on SBOM compliance isn't anomalous. It's a proxy for a broader and more persistent pattern — security investment is announced at the program level and incomplete at the workflow level. Organizations have, in many cases, purchased the right tools, written the right policies, and briefed the right executives. The controls exist on paper. They don't exist in the daily workflow where developers actually build software.

Onboarding is a concrete illustration of where this breaks down. When you're spinning up a new developer and it requires a 16-step README with caveats and environment-specific instructions, each step is a place where the resulting environment can deviate from the secure baseline. The longer and more manual the process, the more likely the environment drifts from what security reviewed and approved. That drift isn't a developer failure; it's a systems design failure, and it reproduces itself across every new hire, every contractor, every environment stood up under deadline pressure. I've watched security teams produce genuinely good policy documents and then have those documents sit unread in a wiki while developers bootstrapped their environments from memory.

Platform engineering is the organizational answer. Internal developer platforms that bake security controls, signed artifacts, pinned environments, and SBOM generation into the default developer workflow remove the burden of individual compliance. A developer who can't ship an artifact without provenance metadata doesn't need to remember to generate it. The control is structural, not behavioral, and structural controls are the only ones that hold when timelines compress.

AI coding agents represent an exposure that most organizations haven't yet accounted for. Agents that execute in development environments, consume packages, and make commits are now first-class actors in the software lifecycle. They inherit all the supply chain risks of the environments they run in and the trust assumptions embedded in those environments. Most organizations are applying less environment rigor to agent workflows than they apply to human developer workflows. Attackers will notice that asymmetry before most security programs do.

The Concrete Practices That Address Each Layer of the Attack Anatomy

The incidents discussed throughout this piece expose three distinct layers. The practices map to those layers without ambiguity.

Dependency Layer

The 90% indirect dependency problem and the npm account-takeover incidents both operate here. The controls are continuous dependency scanning with CVE and license tracking; SBOM generation at build time, not as a retroactive exercise, attached to every release artifact; and VEX attestations to separate reachable vulnerabilities from theoretical ones, reducing the noise that causes security teams to deprioritize genuine alerts. The tooling exists. Every team that has tried to enforce consistent adoption across an organization has found that the workflow integration, not the tool selection, is where programs fall short.

Build Layer

SolarWinds and GhostAction both operated here. The controls are SLSA Level 2 provenance for build artifacts, achievable today with available open-source tooling; commit SHA pinning for all third-party CI actions without exception; artifact signing with Sigstore; and reproducible, hash-pinned build environments so that any deviation from the expected environment state is observable. The build environment must be treated as a trust boundary. It is one, whether or not the organization has chosen to treat it that way.

Trust and Identity Layer

XZ Utils and the maintainer account-takeover incidents operated here. The controls are hardware security keys rather than SMS-based MFA on all package registry accounts, as a non-negotiable baseline; code review policies requiring multiple reviewers for changes to build configuration, dependency pinning, and CI workflow files, not only application code; vetting processes for new contributors to critical open-source projects commensurate with the access being granted; and, where organizations depend on solo-maintained open-source packages, active engagement through funding, co-maintenance, or coordinated succession planning.

The attacks that have occurred in the wild exploited gaps that were known, named, and accepted as normal. The defenses exist at every layer. What doesn't exist yet, in most organizations, is the integration of those defenses into the places where software is actually built.