Software Supply Chain Security’s Acceleration Problem
A look at the accelerating pace of software supply chain attacks in 2026, and how practitioners can a handle on visibility and governance
Throughout my career in cybersecurity, working across public and private sector environments, few problems have stuck with me the way software supply chain security has.
I have spent years writing and speaking on it, and back in 2023 I co-authored a book titled “Software Transparency: Supply Chain Security in an Era of a Software-Driven Society” because it was becoming impossible to ignore that modern software is assembled far more than it is written, and that we had almost no visibility into what we were actually assembling.
That said, if you had told me back then that the pace of attacks would look the way it does in the first half of 2026, I am not sure I would have believed you. We spent years talking about software supply chain risk as a accelerating problem, something we needed to get ahead of. It is no longer looming, it is here, it is industrialized, and the growth curves are steepening in a way that should reshape how practitioners think about their environments.
In this article, I want to level set on how we got here, walk through what the attack data actually shows in 2026, and then dig into a discussion and demo I recently had with Resilient Cyber’s partner at Kusari, whose approach to this problem I find promising.
So, let’s start unpacking the problem space.
Years in the Making
None of this is new, and that is part of what makes the current moment so frustrating.
We have known for years that commercial and open source software alike are built on a sprawling web of dependencies that almost no one fully understands. Synopsys’ 2026 OSSRA report found that 97% of audited commercial codebases contain open source components, that the average application contains 911 open source components, and that 90% of audited codebases contain components more than four years out of date.
The average codebase carried 581 open source vulnerabilities. Those are not the numbers of a niche problem, that is the the underlying critical infrastructure the entire digital economy runs on. These are problems myself and others have been highlighting for several years at this point.
The incidents that made this real for most people are by now part of the security folklore. SolarWinds showed us what happens when an attacker compromises the build pipeline itself of a widely used commercial software provider. Log4Shell showed us that a single ubiquitous open source component could put the entire internet into an emergency remediation cycle overnight, and that most organizations could not even answer the basic question of whether they were affected.
Those events generated executive orders, SBOM mandates, a wave of frameworks, and a genuine surge of attention. For a while it felt like we were finally starting to build the muscle memory this problem demands.
The problem is that the attackers were paying attention too, and they have adapted far faster than most defenders have and the introduction of agentic development as the breakout use case has complicated the problem at a pace and scale that makes the problems of the past pale in comparison.
Velocity, Volume, and Malicious Packages
The numbers coming out of 2025 and the first half of 2026 are hard to overstate, so I will let them speak for themselves. Sonatype’s 2026 State of the Software Supply Chain report identified 454,600 new malicious packages in 2025 alone, bringing the cumulative total they have tracked to over 1.233 million across npm, PyPI, Maven Central, NuGet, and Hugging Face. Over 99% of that open source malware in 2025 landed on npm, the beating heart of the JavaScript ecosystem.
To put the raw exposure into perspective, Sonatype notes developers downloaded open source components 9.8 trillion times across the major ecosystems in 2025.
What changed in 2026 was not just the volume but the tempo. Research from Phoenix Security tracking malicious package campaigns found that the first half of 2026 alone produced 2.6 times the campaign count and 4.5 times the malicious package volume of all of 2025. May of 2026 was the single busiest month on record in their findings, with 14 distinct campaigns and 346 indexed packages in 31 days, and a single self-replicating worm accounting for 226 of them. That is not a steady climb, it is an testament to how this threat is scaling.
Much of that acceleration traces to a shift from one-off malicious uploads to self-replicating worms and coordinated campaigns. The Shai-Hulud worm that hit npm in September 2025 compromised more than 500 packages in a matter of days, spreading on its own by harvesting credentials from each compromised maintainer and using them to poison the next set of packages.
A related compromise that same month reached widely depended-upon packages like chalk and debug, which together account for billions of weekly downloads across the ecosystem. A second wave dubbed Shai-Hulud 2.0 arrived in November 2025, and researchers tracked over a thousand backdoored package versions across hundreds of packages, along with tens of thousands of attacker-created repositories used to exfiltrate stolen secrets. CISA issued guidance on the campaign, demonstrating how significant it had become.
The GitHub Actions and CI/CD ecosystem has been hit just as hard. The tj-actions/changed-files compromise in March 2025 saw an attacker exploit a leaked personal access token to push malicious commits and redirect version tags, and it sat undetected for four months.
In March 2026 a campaign tracked as TeamPCP poisoned 75 of 76 version tags across the widely used trivy-action and other tooling in a single coordinated push. By May 2026 the same class of actor was pushing thousands of malicious workflow commits across thousands of repositories in a matter of hours, and in March 2026 the Axios package, with over 300 million weekly downloads, was compromised when an attacker hijacked a maintainer’s npm account and published a remote access Trojan that bypassed GitHub Actions entirely.
I could keep going, but the pattern matters more than an exhaustive catalog of incidents. If you want the deeper dive on how AI is compressing both the discovery and exploitation timelines on top of all of this, I wrote about it recently in “Vulnpocalypse” and “The Attack Surface Exponential”.
Attacking Trust, Not Just Code
The most important thread running through all of these incidents is that attackers are no longer just targeting the code. They are targeting the people, the credentials, and the CI/CD workflows that we all implicitly trust. A maintainer’s npm token, a leaked PAT in a build log, a poisoned GitHub Action, these are the new front line, and they are devastatingly effective precisely because the entire model of open source consumption is built on trust and convenience, which is ironic given the last several years of security leaders touting concepts such as “Zero Trust”.
There is one detail from the Phoenix analysis that stands out as well. Across the 59 campaigns they tracked, the CVE count during active exploitation was zero. The tooling, the processes, and the mental models most organizations have built for managing software risk are oriented around CVEs, around a known vulnerability with an identifier that shows up in a scanner. Malicious package campaigns do not play by those rules, there is no CVE to alert on while the attack is live. By the time anything shows up in the systems most teams rely on, the credentials are already gone. This is due the speed and complexity, as well as the reality that institutions such as NVD are collapsing under the load being driven by AI with coding and vulnerability discovery.
This is the uncomfortable reality of where we are. The volume is exponential, the tempo is accelerating, the attack surface has expanded from the code itself to the entire development ecosystem around it, and our detection models are looking in the wrong place.
Meanwhile, the rise of AI-assisted and increasingly agentic development is pouring more code, more dependencies, and more velocity into environments that most organizations already could not keep pace with prior to AI’s widespread impact on development, vulnerability discovery and exploitation.
The Visibility Problem Nobody Solved
Underneath all of this sits a problem that predates the current attack wave and has never really been solved, which is visibility. When Log4Shell hit, the single hardest question for most organizations was not how to patch, it was where the vulnerable component even lived across their environment. Years and many frameworks later, most organizations still cannot answer that question quickly, despite things such as software asset inventory being a critical control for years and even decades.
This came up almost immediately when I sat down with the Kusari team, and it lined up with everything I have seen in practice. As their team framed it, the primary struggle for their customers is a lack of visibility, frequently expressed as an inability to answer a deceptively basic question, “Do I have this package, and where is it?” In the current environment that question becomes “Do I have Shai-Hulud, or the compromised version of Axios, and if so, what is the blast radius?”
Most organizations cannot answer it in any reasonable timeframe, and in an era where a worm can traverse hundreds of packages in days, the time it takes to answer is the whole ballgame.
That is the gap I want to spend the rest of this piece on, because it is where I think we need to solve the problem from a first principles perspective before we get into any fancy discussions of known exploitation, exploitability, reachability and other concepts I often discuss.
Where Kusari Fits In
Kusari is a software supply chain security company that came out of the open source world rather than bolting onto it after the fact.
Its founders created and helped shepherd the open source GUAC project, short for Graph for Understanding Artifact Composition, which joined the OpenSSF as an incubating project in 2024.
GUAC is built around the idea of mapping the software supply chain as a graph, identifying the most-used components in an environment, exposing risky dependencies, and calculating the blast radius of a given vulnerability.
What I appreciated in the demo and discussion is that the platform starts from the visibility problem rather than the alert problem. The integration point is typically a GitHub app installed at the organizational level, from which the platform tracks information across the various CI/CD systems and build pipelines, analyzes build metadata and software artifacts, and maintains a continuously updated graph of the organization’s environment.
That graph updates as pull requests and changes flow through, so it reflects the actual current state rather than a snapshot in time from the last time someone ran a scan. As a byproduct of maintaining that graph, the platform tracks versioned, time-stamped records of software including SBOMs, supporting both CycloneDX and SPDX, along with metadata and VEX documents, without an organization having to stand up a separate SBOM management effort, avoiding yet another tool in the security stack.
On top of that graph the platform layers risk. Kusari generates a score from 0 to 10 for a given software component, and I found the inputs valuable and relevant for truly mitigating organizational risks.
The score factors in whether a component carries vulnerabilities on CISA’s Known Exploited Vulnerabilities (KEV) list, the breadth of vulnerabilities across the environment, and how deeply a component is rooted in the supply chain. That last input is the one most tools miss. A vulnerability buried five layers deep in a transitive dependency that half your services pull in is a very different problem than the same vulnerability used once, and the score is explicitly trying to communicate blast radius and remediation complexity rather than just severity in isolation, which is common for a lot of security tools that lack organizational context.
The platform also leans on reachability analysis, using graph analysis to determine whether a vulnerability actually has impact in a given context rather than dumping the full undifferentiated backlog on a development team.
Anyone who has watched developers tune out security tooling because 90% of what it surfaces is noise understands why this matters. To avoid the whack-a-mole cycle where a fixed component quietly gets reintroduced, the platform uses dependency cooldowns and analyzes every change coming through, which is a nice acknowledgment that remediation is not a one-time event but an ongoing fight and shows an evolution of how we should think about reachability in the context of vulnerabilities as well.
Remediation, Not Just Findings
Where the conversation got most interesting for me was on remediation, because finding problems has never really been the hard part in this space, and that’s a point I’ve been making a lot lately.
The platform includes an Autofix capability built around a set of purpose-specific agents. As the team walked me through it, a security architect agent builds a remediation plan, an inspector agent reviews that plan for newly introduced vulnerabilities or compliance issues, and a developer execution agent implements the fix.
Organizations can dial the level of required human intervention up or down based on their own maturity and how much they trust the platform’s suggestions, which to me is the right approach given where most teams are on the trust curve with agentic tooling, especially around production remediation.
The Inspector agent stood on its own as the piece I would probably get the most day-to-day value from. It operates directly in the developer workflow and provides immediate feedback on pull requests, functioning as a security reviewer that gives a thumbs up or thumbs down on whether a change introduces a malicious package, a license compliance violation, or a broader supply chain risk.
Developers get that signal without having to context switch into a separate platform, which is exactly where security tooling tends to die due to breaking the flow of developers or becoming frustrating to use. Meeting developers where they already work, rather than dragging them into yet another console, is one of those lessons our industry keeps having to relearn, despite countless examples demonstrating why its the wrong approach.
There is also a beta conversational interface that lets a user ask natural language questions against the underlying graph, the “Do I have Shai-Hulud or not?” a query I mentioned earlier, and get an instant answer. It sounds simple, and that is the point. That is the question organizations were desperate to answer during Log4Shell and every incident since, and being able to answer it in seconds against a live graph of your environment that accounts for not just presence but blast radius is a meaningfully different posture than what most teams have today.
For organizations with sensitivity around data separation, the team noted that customer infrastructure is single-tenant as well.
Why the SDLC Focus Matters
One point of differentiation the team was passionate about, is the decision to anchor in the software development lifecycle and source control rather than the runtime environment. Their argument is that a great deal of supply chain risk manifests inside developer tooling, build systems, and test suites, and never touches the runtime environment at all.
The Shai-Hulud worm harvesting credentials during a package install is a perfect example. That happens on a developer’s machine or in a CI runner, long before anything reaches production. A runtime-oriented tool is looking in the wrong place for that class of attack, but that said, I do hold the view that coupling this with something with runtime visibility and capability is key as well.
The other place the SDLC-anchored, graph-based approach earns its keep is in large, complex, non-uniform environments. Enterprises rarely run on a single tidy GitHub org. They have multiple disparate instances of GitHub and GitLab, acquisitions with their own stacks, and years of accumulated sprawl.
The ability to enumerate software and assess risk across all of that without forcing a massive migration or platform consolidation first is a genuine differentiator, and it maps to the reality practitioners actually live in and environments I often see rather than the clean environment a tool wishes they had.
Closing Thoughts
This is far from an exhaustive discussion, and I have deliberately left the deeper AI angle to my prior writing.
That said, what the first half of 2026 makes clear is that software supply chain security has crossed from a problem we talked about getting ahead of into one that is actively outrunning most organizations’ ability to respond. The volume is exponential, the campaigns are self-replicating, the attackers have moved upstream to the trust and identity layer, and the CVE-shaped tooling most of us built our programs around does not see any of it while it is happening.
I have been beating this drum for years, going back to my book “Software Transparency”, and the through line has not changed. You cannot secure, prioritize, or remediate what you cannot see. The organizations that come through this next wave in decent shape will be the ones that finally solve for visibility and remediation velocity as first-order problems, rather than treating them as something they will get to after the next audit.
It remains to be seen whether the industry actually embraces this approach at scale before the next widespread software supply chain event, but the tooling and the approaches to actually do something about it are here, and that is a more hopeful place to be than we were a few years ago.