The Invisible Saboteur: How Open-Source Supply Chain Attacks Are Becoming the Software Industry’s Most Dangerous Blind Spot

="">

Somewhere between the moment a developer types npm install and the moment their application goes live, a universe of trust assumptions plays out — most of them unexamined. That gap between assumption and reality has become the most exploited vulnerability in modern software development, and the consequences are accelerating.

Open-source supply chain attacks have surged in both frequency and sophistication over the past two years. The pattern is now disturbingly familiar: a widely used library gets compromised — sometimes through a hijacked maintainer account, sometimes through a malicious package masquerading as a legitimate dependency — and millions of downstream applications inherit the poison. No firewall catches it. No antivirus flags it. The code arrives through the front door, invited in by the very build systems organizations rely on.

The Axios HTTP client library, downloaded tens of millions of times per month from npm and used across enterprise and consumer applications alike, represents exactly the kind of high-value target attackers have been circling. With its ubiquity in both browser and Node.js environments, a single compromised version could propagate malware to an almost incomprehensible number of systems. The attack surface isn’t theoretical. It’s a matter of when, not if.

A Pattern of Escalation: From Event-Stream to Everything

The template for these attacks was established years ago. In 2018, the event-stream npm package — downloaded roughly two million times per week — was compromised after a new maintainer was granted publishing rights by the original author, who had moved on from the project. The new maintainer injected code targeting a specific Bitcoin wallet application. It was surgical. It was patient. And it worked for weeks before anyone noticed.

That incident should have been a wake-up call. In some ways, it was. But the structural incentives of open-source development haven’t fundamentally changed since then. Maintainers still burn out. Projects still get handed off to strangers. And the npm registry, along with PyPI, RubyGems, and other package repositories, still operates largely on a trust model that assumes good faith from publishers.

Since event-stream, the pace has only quickened. Sonatype’s 2024 State of the Software Supply Chain report documented a 156% year-over-year increase in malicious packages detected across major open-source registries. That’s not a blip. That’s a trend line pointing straight up.

The attacks themselves have grown more creative. Typosquatting — publishing packages with names that closely resemble popular libraries — remains common. But attackers have also moved to dependency confusion attacks, where they publish public packages with the same names as private internal packages used by target companies. When a build system checks the public registry first, it pulls the attacker’s code instead of the company’s own. Security researcher Alex Birsan demonstrated this technique in 2021, successfully infiltrating the build systems of Apple, Microsoft, and PayPal in the process.

More recently, the xz Utils backdoor discovered in March 2024 sent shockwaves through the Linux community. A contributor named “Jia Tan” spent nearly two years building trust within the xz compression library project before inserting a sophisticated backdoor that targeted OpenSSH authentication on systemd-based Linux distributions. As reported on the oss-security mailing list by Microsoft engineer Andres Freund, who discovered the backdoor almost by accident while investigating a slight performance anomaly, the attack was state-actor-level in its patience and execution.

That’s the part that should terrify everyone. Not the script kiddies publishing typosquatted packages. The sophisticated, long-game operators who invest months or years into gaining commit access to critical infrastructure libraries.

Axios sits in that critical infrastructure category. It’s the default HTTP client for a staggering number of JavaScript applications. Its GitHub repository has over 100,000 stars. It’s embedded in corporate dashboards, fintech platforms, healthcare portals, and government systems. A compromised Axios release wouldn’t just be an incident — it would be an event.

And the attack vectors are numerous. npm accounts can be compromised through credential stuffing, phishing, or social engineering. GitHub repositories can be targeted through compromised CI/CD pipelines. Even the build process itself can be manipulated if an attacker gains access to the right automation token.

The Maintainer Problem Nobody Wants to Talk About

Here’s an uncomfortable truth the technology industry has been dancing around for years: the people maintaining the most critical pieces of open-source infrastructure are often doing it for free, in their spare time, with no institutional support.

The Axios library was created by Matt Zabriskie and has been maintained by a small group of contributors. Like many popular open-source projects, the ratio of users to active maintainers is absurdly lopsided. Millions of companies depend on the library. A handful of people keep it running.

This isn’t unique to Axios. The Open Source Security Foundation (OpenSSF), backed by the Linux Foundation and major tech companies, has been working to address this gap through initiatives like the Alpha-Omega Project, which funds security audits and maintainer support for critical open-source projects. But the scale of the problem dwarfs the resources being thrown at it.

Burnout is real. Resentment is real. And when a maintainer walks away from a project — or worse, hands the keys to someone they barely know — the downstream risk is enormous. The xz Utils attack exploited exactly this dynamic. The original maintainer, Lasse Collin, was under pressure and dealing with mental health challenges. Social pressure from sock puppet accounts pushed him toward accepting help from the very attacker who would later insert the backdoor.

So what happens when an attacker targets an Axios maintainer? Or any maintainer of a package with millions of weekly downloads? The defenses are thin. npm now supports two-factor authentication, and GitHub has mandated 2FA for active contributors. But 2FA isn’t a silver bullet. Session hijacking, token theft, and social engineering can all bypass it.

The industry’s response has been a mix of tooling and policy. Software Bills of Materials (SBOMs) are now required for software sold to U.S. federal agencies, following Executive Order 14028 signed in May 2021. Tools like Socket, Snyk, and Dependabot scan for known vulnerabilities and suspicious package behavior. Sigstore provides cryptographic signing for software artifacts, making it harder to tamper with releases undetected.

But detection still lags behind offense. A well-crafted supply chain attack — one that introduces subtle changes rather than obvious malware — can evade automated scanning for days or weeks. The xz backdoor, for example, was obfuscated through test files that appeared benign. Only a human investigating an unrelated performance issue caught it.

The JavaScript and Node.js world faces particular challenges. npm’s dependency tree model means a single application can pull in hundreds or thousands of transitive dependencies — packages that the developer never explicitly chose but that are required by packages they did choose. Each one is an attack surface. Each one is maintained by someone the developer has never met and probably never will.

What Comes Next

The trajectory is clear. Supply chain attacks on open-source software will continue to increase in both volume and sophistication. The targets will get bigger. The techniques will get more patient.

Some responses are already underway. npm has introduced provenance attestations that cryptographically link published packages to their source repositories and build processes. This makes it significantly harder for an attacker to publish a tampered version without leaving a detectable discrepancy. Google’s SLSA (Supply-chain Levels for Software Artifacts) framework provides a graduated model for build integrity, from basic source tracking to fully hermetic, reproducible builds.

But adoption of these measures remains uneven. Many organizations still don’t audit their dependency trees. Many developers still run npm install without checking what’s actually being pulled in. And many companies that profit enormously from open-source software still contribute nothing to the security of the projects they depend on.

The economics are broken. A library like Axios generates billions of dollars in value for the companies that use it. The people who maintain it don’t see a fraction of that. Until the industry finds a sustainable model for funding and securing open-source maintenance — not just through grants and foundations, but through structural accountability — the supply chain will remain the softest target in software.

There’s a phrase in security circles: “You don’t rise to the level of your aspirations; you fall to the level of your preparations.” Right now, for most organizations, the level of preparation for an open-source supply chain compromise is disturbingly low. They trust the packages they install because they’ve always trusted them. They assume someone else is watching.

Nobody is watching.

Or rather, somebody is. Just not the people you’d want.

For companies building on JavaScript, Python, or any language with a package manager — which is to say, virtually all companies — the time to audit dependency chains, enforce provenance verification, and invest in the security of upstream projects was years ago. The second-best time is now. Because the next compromised package won’t announce itself. It’ll arrive quietly, through the build pipeline, wearing the name of something everyone trusts.

Something like Axios.