The NPM Supply Chain Attack Playbook That Still Works in 2026
On March 31, 2026, the Axios NPM package, with over 100 million weekly downloads, was hijacked by a North Korean threat actor. A hidden dependency silently installed a remote access trojan across developer machines and CI/CD pipelines before the malicious versions were even publicly flagged. For anyone who lived through the Shai-Hulud NPM attacks, the pattern was instantly familiar.
The Shai-Hulud NPM supply chain attack hit in the fall of 2025, and like every other security team out there, we had one question on our minds: are we exposed?
We run a large engineering organization. Lots of applications, lots of teams, heavy reliance on open-source JavaScript packages. So when a self-replicating worm starts spreading through NPM maintainer accounts and infecting hundreds of packages, the pressure ramps up fast. Leadership wants answers. Engineering wants guidance. And your security team is in the middle trying to figure out the blast radius before it gets worse.
The Real Problem Wasn’t the Attack Itself
Look, supply chain attacks are not new. We’ve dealt with vulnerability disclosures before. But what made Shai-Hulud different was the speed and scale. New compromised packages were surfacing every few hours. The list kept growing. And the question “are we affected?” doesn’t have a simple answer when you’re managing hundreds of applications, each with its own dependency tree, maintained by different teams across the organization.
Without proper tooling, here’s what that exercise looks like: you pull up the advisory, go through individual package-lock.json files across repos, try to figure out which teams own what, and then prioritize. That’s easily a week of work. In the middle of an active incident, you don’t have a week.
What Actually Helped Us Respond
We already had SCA tooling in place that was continuously scanning our open-source dependencies. So when the compromised packages were flagged, we weren’t starting from zero. Our dependency inventory was already there. That part was solid.
Having scan data is one piece of the puzzle. The harder part is making sense of it across your entire environment, fast. That includes correlating findings from multiple tools, understanding business context, figuring out who owns what, and deciding what to fix first. That’s where things usually slow down.
We were already using ArmorCode’s Agentic AI Platform, and its Software Supply Chain Security module is what closed the gap. What would have taken us close to a week of investigation was done in hours.
It gave us immediate visibility into which open-source packages were affected across our entire landscape. We could see it all in one place. No jumping between tools, no manual spreadsheets, no chasing down application owners one by one.
The supply chain module is helping us with quick identification of open-source packages and reducing the timeline significantly. During supply chain attacks like this, we rely on it mainly for that immediate visibility to know what’s impacted and where, so we can act on it instead of spending days just trying to understand the scope.
Being Honest About Where We Are
I want to be upfront. We’re not fully integrated yet. We haven’t connected ArmorCode into our bug tracking and ticketing workflows, so there’s still some manual effort in handing off remediation to engineering teams. That’s something we’re working on.
But even without that piece, the value during a supply chain incident is clear. When you’re in the middle of a crisis, the most important thing is knowing where you stand. Are we affected? How bad is it? Where do we focus first? If you can answer those questions in hours instead of days, you’re already in a much better position.
What I’d Tell Other Security Leaders
If you’re running an application security program at any real scale, you need to know what’s in your open-source landscape before the next incident hits. Not after. My conviction has only grown stronger over the years: you cannot afford to be assembling your inventory when the breach is already underway.
The NPM attacks in 2025 demonstrated that the velocity of modern supply chain threats demands a fundamentally different operational posture. They also proved that the organizations who had unified visibility into their supply chain were the ones who responded effectively. The rest were scrambling.
We’re watching this play out again with the Axios compromise. Axios carries roughly 100 million weekly downloads and is a transitive dependency across thousands of other packages, meaning organizations are exposed even if no developer ever explicitly installed it. Organizations that had lockfiles pinning Axios to a specific version, or CI/CD policies that suppress automatic install scripts, were protected. The ones that didn’t, had a window of exposure measured in hours. The 2025 playbook applied directly. The organizations that came out of it cleanly were the ones who already knew what was in their environment.
When the next supply chain attack happens, and it will, your response time is the only thing that separates a controlled incident from a full-blown fire drill. Invest in that visibility layer now.
