Founders

Your App Is Mostly Other People's Code

The npm attacks of 2026 hit code most founders never knew they shipped. Here is what that code is, why it matters, and the questions to ask whoever builds your product.

Hari Gopal Sharma · 2026-09-04 · 5 min read

supply chain security npm dependencies founders

On August 4, a maintainer's GitHub account behind a small, popular caching library called keyv was taken over. Shortly after, a new version carrying credential-stealing malware was on npm, and that same day Wiz reported the worm had spread to over 400 distinct packages. If you run a software business, there is a fair chance you had never heard of keyv. There is also a fair chance your product depended on it, or on something that did.

That is the uncomfortable part I want founders to sit with. Most of what runs inside your app was not written by your team. It was written by strangers, maintained by volunteers or small companies, and pulled in automatically.

What actually happened this year

Two incidents are worth knowing by name.

On March 31, attackers took over a maintainer account for Axios, one of the most widely used JavaScript libraries for making web requests, and published two malicious versions (1.14.1 and 0.30.4). Microsoft attributed the attack to a North Korean state actor it calls Sapphire Sleet. The Axios code itself wasn't changed. Instead, the bad versions quietly added a new dependency whose install script downloaded a remote access trojan for macOS, Windows or Linux. Microsoft also noted that projects using common version ranges such as `^1.14.0` could pull the malicious release automatically.

Then came August. The keyv compromise was a descendant of the "Mini" Shai-Hulud worm family, which steals developer and cloud credentials and uses them to publish poisoned versions of other packages. Sonatype was tracking more than 2,200 affected component versions a day later. Singapore's Cyber Security Agency issued advisory AD-2026-009 on August 6, counting over 1,300 compromised versions on npm with a combined reach of about 2 billion monthly downloads. The counts differ because each team measured at a different moment, which tells you how fast it moved.

Why a library you've never heard of can hurt you

Modern software is assembled more than it is written. Black Duck's 2026 Open Source Security and Risk Analysis found open source in 98 percent of the commercial codebases it audited, with a mean of 1,180 open source components per application. Your developers chose a few dozen of those. The rest came along as dependencies of dependencies.

This is normal, and mostly good. Nobody should rewrite encryption, date handling or payment SDKs from scratch. It's a big part of why custom software development is affordable at all.

But every one of those components is a door. In both attacks this year, the malicious code ran at install time, on developer laptops and in build servers. That is exactly where your cloud keys, GitHub tokens and deployment secrets live. Wiz's advice for the keyv wave was blunt: treat affected systems as compromised, rebuild them, and rotate cloud, GitHub, SSH, Kubernetes and Terraform credentials.

One detail stuck with me. Sonatype noted that npm 12 blocks unapproved install scripts by default, but older npm versions, or setups configured to allow scripts, would still run the payload. The defences exist. Whether they're switched on depends on choices someone on your team made, or didn't make.

You don't need to read code. You need to ask better questions

I won't pretend there's a setting that makes this risk go away. There isn't. A release that comes from the official maintainer's account can still be malicious if an attacker controls that account. What you can control is how quickly your team notices, how little a single bad package can reach, and whether anyone actually owns the problem.

That's a management question as much as a technical one. Unowned dependencies are a form of technical debt: invisible until the day they aren't, and expensive to pay down in a hurry.

The checklist: questions for your development partner

Ask these of whoever builds or maintains your product, whether that's an in-house team, a freelancer or an agency. Good answers are short and specific. Vague answers are the finding.

Choosing

Pinning

Updating

Scanning and limiting damage

Owning

If the answer to the last question is "we'd figure it out," that's worth fixing before the next wave, not during it.

What good looks like, honestly

A sensible setup is not exotic. Lockfiles committed and enforced. A short delay on new releases. Automated scanning with alerts that reach a named person. Build environments that can't see production secrets they don't need. A practiced routine for rotating credentials. None of this guarantees you'll never install a bad package. It means that if you do, the blast radius is small and the response is measured in hours.

I'd also push back on the idea that this is only a concern for big companies. Attackers in these campaigns harvested whatever credentials they found. A seed-stage startup's AWS keys are just as useful to them as anyone else's.

Where this leaves you

You don't have to become a security engineer to run a software company. You do need to know that most of your product is borrowed, and that someone on your side is watching what gets borrowed and what happens when it goes bad.

If you'd like a second opinion on how your current product handles this, or you're planning a new build and want these practices in from day one, that's the kind of conversation we have every week. You can see how we work on our services page, or book a call below.

Sources

Keep reading

← Back to Insights