On the last day of March 2026, one compromised maintainer account turned axios, one of the most widely used JavaScript libraries in the world, into a malware delivery system. The package ships roughly 100 million downloads a week and sits underneath more than 174,000 dependent packages, and for about three hours anyone who ran a fresh install pulled a cross-platform remote access trojan straight into their build, an attack later attributed to a nation-state actor (Shattered, 2026).
That is the software supply chain, and it is now the part of security that should worry teams most. Modern applications are mostly assembled from code nobody on the team wrote: 97 per cent of commercial codebases contain open-source components, and the average codebase pulls in around 911 of them, with 90 per cent including components more than four years out of date (AppSec Santa, 2026). The industry has noticed: software supply chain failures are now their own category in the OWASP Top 10 (OWASP via Authgear, 2026).
This post is the plain version: what the software supply chain is, why the perimeter no longer protects it, how a single compromised link cascades to thousands, and what actually helps. No code, just the shape of the problem.
Your software is mostly other people's code
The first thing to accept is how little of a modern application a team actually writes. Almost every commercial codebase, 97 per cent of them, is built on open-source components, and across the ecosystem there were 9.8 trillion package downloads in 2025 alone (AppSec Santa, 2026). Your product is a thin layer of your own code sitting on a deep stack of other people's.
And that stack is neither small nor fresh. The average codebase contains around 911 open-source components, 86 per cent of codebases contain at least one open-source vulnerability, and 90 per cent include components more than four years out of date (AppSec Santa, 2026). The supply chain is every one of those components, plus the tools that build them and the vendors that deliver them.
The nuance is that this is not a mistake to be corrected. Reusing open source is the right call, it is what makes modern software fast to build, and no team should hand-write a logging library. The point is not to stop depending on other people's code, it is to stop depending on it blindly.
The perimeter does not help when the threat arrives as a trusted update
Traditional security spends most of its effort on the perimeter, keeping attackers out. A supply chain attack simply walks in through the front door, because attackers do not need to break the perimeter when a trusted vendor or dependency has already connected to it (Swif, 2026). The malicious code arrives as a routine update, wearing the credentials of software you already trust.
That is why a single compromise scales so brutally. By compromising one software provider, an attacker can simultaneously infect thousands of downstream customers who implicitly trust the updates they receive, bypassing the strong perimeter defences of every one of them (DeepStrike, 2025). The trend is already in the breach data: 30 per cent of breaches now involve a third party, double the 15 per cent reported a year earlier (DeepStrike, 2025).
One compromised link, thousands of victims
The axios incident was not an outlier. In September 2025, the widely used npm packages chalk and debug, along with more than sixteen others that collectively see over two billion downloads a week, were compromised after a maintainer fell for a phishing attack, letting attackers embed a cryptocurrency-theft payload into some of the most pervasive libraries in the JavaScript world (Sonatype, 2025).
It is not only open-source packages. The PowerSchool breach, classified as a third-party software supply chain event, exposed personal data on roughly 62.4 million students and 9.5 million teachers across thousands of school districts, a single software vendor compromise sweeping across an entire sector (Swif, 2026).
The threat industrialised, and started moving on its own
What changed in 2025 is that this stopped being occasional. Across the year, more than 454,600 new malicious open-source packages were identified, a 75 per cent jump on the year before (Sonatype, 2026). The people behind them changed too, escalating from lone crypto-skimmers to organised criminal crews to nation-state actors, with the axios compromise attributed to the latter (Shattered, 2026).
The most unsettling development is that the attacks learned to spread themselves. The Shai-Hulud campaign in September 2025 was the first known self-replicating npm malware, stealing a maintainer's credentials, publishing poisoned updates, and propagating to other packages automatically, compromising more than 500 packages in days without a human pushing each one (Sonatype, 2026). A supply chain worm turns isolated incidents into chain reactions.
The nuance is that scale cuts both ways. The same registries that let malware spread also let defenders track it, and the reason these numbers exist at all is that the ecosystem is now watching closely, blocking, and cataloguing. The threat is industrialised, but so is the response.
What actually helps, at a high level
The defences are not exotic, and none of them require abandoning open source. The foundation is simply knowing what is in your software, an inventory of every component and version, so that when a package is compromised you can answer whether you use it in minutes rather than days. On top of that, scanning dependencies continuously and pinning them to specific, verified versions rather than automatically pulling the latest closes the door that malicious updates walk through, and getting packages only from trusted, curated sources guards against lookalike names (OWASP via Authgear, 2026).
The other half is guarding the way software is built and published. Because most of these attacks begin with a hijacked maintainer account or build system, the highest-leverage controls are the boring ones: least-privilege access, multi-factor authentication, rotating credentials, and restricting which upstream sources a build is even allowed to pull from (AWS, 2026). A stolen token should not be enough to poison what everyone downstream installs.
The nuance is that none of this is a one-time project. Dependencies update, vendors change, and new packages are added constantly, so supply chain security is a standing practice of inventory, monitoring, and least privilege, not a box to tick once and forget.
The part worth sitting with
The hard shift in thinking is this: the code most likely to compromise a product is not the code its team wrote, it is the code the team trusted. A modern application is a thin sliver of original work resting on hundreds of components maintained by strangers, delivered through vendors and build systems, any one of which becoming compromised can carry an attacker past every perimeter defence in a single trusted update. That is not an argument against open source, which remains the right way to build, it is an argument for treating the supply chain as something to be inventoried, monitored, and locked down rather than assumed safe. The teams that will weather the next axios, the next Shai-Hulud, the next hijacked vendor, are the ones that already know exactly what they depend on and have made a single stolen credential far from sufficient to poison it. Trust is still the foundation of the supply chain. The change is that it now has to be verified rather than assumed.
Author note
I am Manjunaathaa, an Associate DevOps Engineer at Frigga Cloud Labs. I work across AWS, GCP, and Azure daily, with GitHub Actions as my deployment backbone. My focus is Proactive Resilience, and the supply chain is where that focus matters most, because resilience here means assuming a dependency will be compromised one day and being ready for it, rather than hoping none of them ever are. Every practice in this post is something I actually run in production, not something I read about. What made it real for me was a week spent tracing whether a compromised package had reached anything I owned, and realising the answer should have been instant. Now I inventory what I depend on, pin and watch it instead of trusting it, and keep the build locked down tightly enough that one stolen token is not the end of the story. I would rather do that quiet work before the next big compromise than scramble through it during one. Connect with me on LinkedIn → Manjunaathaa.
DevOps, Security, Software Supply Chain, Open Source, Dependencies, npm, SBOM, DevSecOps, Cybersecurity, Third-Party Risk