Your Best npm Defense Is Waiting 24 Hours

Amazon's threat intel team dropped a bombshell this week: the npm attacks that defined the last year — the September 2025 chalk and debug compromise, and the March 2026 hijack of axios — weren't the work of opportunistic crimeware crews. Amazon attributes them, with medium confidence, to Sapphire Sleet (aka BlueNoroff/Stardust Chollima), a North Korean state-sponsored group, tracing a deliberate arc from a throwaway test run on typo-crypto in March 2025 through to axios, a package with roughly 100 million weekly downloads.

The attribution is genuinely important. But if you're deciding what to do about it on Monday, the more useful number is buried in the incident timelines: the chalk/debug payload reached an estimated 10% of cloud environments within two hours. The malicious axios releases — 1.14.1 and 0.30.4, which pulled in a phantom plain-crypto-js dependency that dropped a cross-platform RAT via a postinstall hook — were live for under three hours before being yanked.

Two hours. Three hours. Every headline npm compromise of the past year has had a live window measured in hours, because registry scanners, researchers, and angry GitHub issues catch these things fast. Which means the single highest-leverage defense available to you costs nothing and requires no new vendor: stop installing packages the moment they're published.

Cooldowns go from blog-post advice to default behavior

The idea — only resolve versions that have been public for N days — has been circulating as hard-won folk wisdom since the first big npm worm incidents. What's changed is that it's now shipping as first-class tooling.

pnpm moved first, adding a minimumReleaseAge setting in 10.16 and then flipping it on by default in pnpm 11: out of the box, pnpm now refuses to resolve any version less than 24 hours old. That makes it the first major package manager where the safe behavior is the default rather than a flag you have to know about. Renovate has offered the same concept for update PRs (minimumReleaseAge, formerly stabilityDays) for years, and npm-check-updates and similar tools are growing equivalent options.

The pattern has even reached the editor. tinyNpm, a brand-new VS Code extension from an indie developer, applies a configurable buffer (three days by default) to the version hints it shows in package.json, strips the ^ caret so you pin exact versions, and surfaces dependency counts and download stats on hover. It's tiny — barely any installs yet — and I wouldn't build an org's security posture on an editor plugin, because the resolver and CI are where enforcement has to live; anything that only changes what a human sees in a hover tooltip is advisory. But it's a telling artifact: when solo developers start independently reinventing cooldowns in their side projects, the mental model has won. The npm culture of "always latest, floating ranges everywhere" is dying in real time, and it deserves to.

If you do nothing else this quarter, do this:

# pnpm-workspace.yaml
minimumReleaseAge: 4320   # minutes — three days
minimumReleaseAgeExclude:
  - "@yourorg/*"          # don't gate your own packages

npm itself has no native equivalent yet, so npm shops should enforce the delay one layer up, in Renovate or whatever bot opens your update PRs — plus --ignore-scripts in CI installs. That last one isn't optional anymore: the axios payload, like most of these attacks, detonated from a postinstall hook. Disabling lifecycle scripts breaks a handful of packages (you re-enable per-package), and it would have neutered this attack outright.

What cooldowns don't buy you

Here's where Amazon's attribution stops being trivia and starts changing the math. The report describes how DPRK operators are evolving: splitting malicious behavior across multiple innocuous-looking packages — one carries an encrypted payload, another the decryption logic, a third the execution path — spending months publishing legitimate updates to build trust before turning a package hostile, and pre-registering package names that AI assistants hallucinate ("slopsquatting").

None of that is stopped by a 72-hour cooldown. A state actor with a salary and a five-year mandate will happily wait out your buffer; the whole point of the trust-building phase is that the malicious version doesn't look different from the forty benign ones before it. Cooldowns are a filter for smash-and-grab attacks — compromised maintainer account, malicious publish, detection within hours. That happens to describe every incident that actually mattered at scale this year, which is why cooldowns are the right first move. But they're a mitigation for the current meta, not a solution, and the adversary has already told us their next move.

So the honest posture is layered and boring: a cooldown at the resolver, lockfiles committed and installs run with --frozen-lockfile, lifecycle scripts off by default, provenance/trusted publishing verified where available, and dependency review that treats a new transitive package as a bigger event than a version bump. Amazon, for its part, is putting $12.5M into an initiative called Akrites with the Linux Foundation and OpenSSF partners aimed at AI-driven supply chain threats — welcome, but registry-side defenses have consistently lagged attacker tempo, and I wouldn't wait for them.

The uncomfortable trade-off

Cooldowns have a real cost that advocates tend to mumble past: security patches are also new releases. When the next axios CVE drops with a fix in a version published forty minutes ago, your three-day gate is now protecting you from the patch. That's what the exclusion lists and manual overrides are for, and it means cooldowns don't eliminate judgment — they just move it from "every install" to "the rare urgent exception," which is a trade any security team should take.

The bigger shift is cultural. For fifteen years the npm ecosystem optimized for freshness: caret ranges, daily dependency bumps, badges shaming you for being two minors behind. It took a state-sponsored actor compromising the plumbing of the entire JavaScript world to make "wait a few days" respectable. Better late than never — turn the cooldown on.