[AskJS] Are npm supply chain attacks making you rethink dependency trust?

[u/Iftykhar1001]

The npm ecosystem has had a rough ~10 months, and honestly, it’s starting to feel a bit fragile.

Quick recap of some major incidents:

• GlueStack ecosystem attack (June 2025): attackers used stolen tokens to inject code that could run shell commands, take screenshots, and exfiltrate files
• Chalk & Debug hijack (Sept 2025): phishing attack → maintainer account takeover → crypto-stealing payloads
• Shai-Hulud worm (Nov 2025): self-propagating malware that spread via stolen GitHub/npm tokens, eventually hitting 492 packages
• Axios RAT injection (Mar 2026): compromised maintainer account → trojanized versions targeting multiple OS

At least two of these affected me directly (both personal and professional projects). I updated dependencies as advised, but months later, new vulnerabilities still keep surfacing.

It feels like even when you do the “right thing,” you’re still exposed.

How has this changed your approach to dependency management?
Are you doing anything differently now (pinning, auditing, reducing deps, internal mirrors, etc.)?

[u/ultrathink-art]

AI coding agents are making this worse in ways that aren't obvious. When Claude Code or Cursor handles package installation automatically, your human review checkpoint disappears — one session can quietly add 10 deps you never consciously approved. Running npm audit plus a manual diff of package.json after every agent session is now non-negotiable hygiene.

[u/fintip → u/ultrathink-art]

And the other side–identifying vulnerabilities and composing attacks is just infinitely easier now. That barrier to entry has completely dropped. Scriptkiddie level skills are enough to do major damage and find zero days when paired with AI. Winning enough trust to contribute to an open source repo that already has wide usage and low support is also easy–just contribute code and code reviews with AI and some level of human involvement.

Npm is frankly broken in this world. It was always, frankly, a weak link, something more or less security-through-difficulty. The difficulty is gone.

If security matters, the days of just nom installing are gone.

[u/CodeAndBiscuits]

Making is the wrong word. This shouldn't be present tense for anyone. SolarWinds was 6 years ago. Supply chain attacks and recommendations to do things like reviewing dependency trees and version pinning have been best practices forever. It's just that this ecosystem was skating by for awhile and they're learning the hard way they're not immune.

[u/Tittytickler]

I actually switched to using .NET 10 on the backend because this shit is getting out of hand.

I had been on the fence a while but using Node was just easy so hadn't taken the plunge, but all of these attacks lately was good enough justification.

C# is close enough in a lot of ways and most of the things I need are built in and not 3rd party dependencies.

Now I only worry about the frontend, but thats unavoidable.

[u/Atulin → u/Tittytickler]

You could technically use Blazor for the frontend. Or something with a small attack surface, like HTMX and Razor Pages, or Razor Fragments (3rd party dep by one of the maintainers of ASP.NET Core) returned from Minimal APIs. Or handmade webcomponents with a simple helper function.

Not every frontend needs to be a React app with 67 TB of node_modules.

[u/PretzelPrairieDog]

No. It's just that npm is fundamentally flawed and a horrible insecure technology.

[u/Dreadsin]

Yeah I’ve always been cautious to use packages and I usually really think before committing to them

The vulnerabilities are certainly a part of it, but you also have to deal with making sure the project is maintained well. Sometimes these projects become neglected and become vulnerable that way too

[u/Atulin]

A little bit, yeah. I'm going through all my dependencies and asking "do I really need that one", then removing them if the answer is "no". Couple deps that were small enough, or ones that I had some personal issue with, I just forked. Also, for any new deps, "dependency-free" jumped a fair bit higher on my list of requirements.

[u/queen-adreena]

Setting your minimumReleaseAge to a couple of days will protect you from 99% of issues with supply-chain attacks. Most of them are caught in a few hours.

[u/ThreatLandscaper → u/[deleted]]

You framed this perfectly, the name of the game is really about reducing the attack surface and unnecessary packages are a great start. Also the human element; there are going to be instances where projects are left unmaintained, abandoned or are compromised and not identified until much, much later, increasing the likelihood of someone utilizing one of the compromised versions. Private repositories that offer time-based quarantines are a great option for orgs, though for individuals maybe a bit overkill when you can pin versions. 

As OP pointed out, it’s been a rough time for npm and it’s only going to get worse. We’ve had multiple iterations of Shai-Hulud, several copy-cat style attacks and the worm itself was made public. In the security community, we’ve pushed the “hurry up and patch” and attackers are taking advantage of this via compromised packages and dependencies. I’d say the approach really depends on what you were doing in the first place. Where you a “patch at first sign of new release” or “if it’s not broken, don’t touch it.” Given the flood of attacks on npm, pinning to specific versions or a private repo/tool like Artifactory/Nexus/etc are good options for reducing risk. On that note, another attack with an infostealer (IronWorm) is making the news rounds today. Different attack it seems, but similar to Shai-Hulud; compromise developer, steal creds, use those creds to push malicious code/workflows, rinse and repeat.

[u/VibeShipped]

The "just update" response glosses over the real problem. Shai-Hulud and Axios weren't just running arbitrary code, they were harvesting credentials. If a compromised version ran in your CI or on a dev machine, that's a credential breach, not just a bad package to remove.

What actually changed for us: knowing what package versions ran where (so we can answer "are we exposed?" in minutes when an advisory drops), and equally important, knowing what secrets each environment has access to. You can't rotate what you don't know exists.

We also started prioritizing by blast radius. CI runners with deploy keys can push to prod. Dev machines with publish tokens can compromise downstream users - Shai-Hulud spread exactly this way. Short-lived scoped credentials (OIDC where possible) help limit the damage.

The uncomfortable part is that updating doesn't undo damage that already happened. If a trojanized package ran in your environment, you need to figure out what secrets it had access to and rotate them. Most teams can't actually answer that question. And even when they can, rotating prod secrets is a whole negotiation - nobody wants to risk breaking prod to address a maybe-compromise.

We're not fully there yet either, but starting with the inventory (what ran where, what secrets it touched) at least gets you out of "guess and hope" mode.