npm's Cooldown Works Because You Never Vetted Anything
The security-theater critique misreads who actually catches registry malware — but it's right about what attackers do next.
A post arguing that npm's new release cooldown is "security theater" hit the Hacker News front page this week, and its central argument deserves a serious answer: if everyone delays installing new package versions, who's left to discover the malware during the delay? Cooldowns, the argument goes, are a herd-immunity scheme where everyone quietly defects from being the herd. If every consumer waits seven days, day seven is just day zero with extra steps.
It's a clean argument. It's also wrong about how malware actually gets caught on the registry — though it's right, in a way worth dwelling on, about where this arms race goes next.
What actually shipped
Cooldowns went from niche config to table stakes in under a year. pnpm shipped minimumReleaseAge in v10.16 in September 2025, days after the Shai-Hulud worm chewed through hundreds of packages; pnpm 11 now defaults to a 24-hour cooldown. Yarn 4.10 added npmMinimalAgeGate, Bun 1.3 added its own knob, and GitHub gave Dependabot version updates a default cooldown. npm itself was last to the party: min-release-age landed in the CLI in v11.10.0 this February, alongside bulk OIDC configuration for trusted publishing.
The logic is empirical, not theoretical. Compromised versions of popular packages tend to get yanked within hours, so an install-time delay of even one day filters out almost every incident before it reaches you.
The vetting nobody was doing anyway
The theater critique rests on a picture of detection that hasn't been true for years: eager early adopters pulling fresh releases, reading the diff, and raising the alarm. In that picture, cooldowns are self-defeating — remove the early adopters and nobody's left to vet.
But ordinary users installing packages were never the detection layer. Nobody reviews the transitive dependency graph of a package-lock.json update; the author of the theater post is completely right about that, and it's precisely why the argument fails. Detection is professionalized. Socket, Datadog, Snyk, StepSecurity, and a pile of independent researchers continuously pull every new release from the registry and run it through sandboxes and static analysis, because catching malware is their product. The registry's own takedown pipeline sits behind them. None of these systems observe your cooldown, so the equilibrium never collapses. The canary isn't a volunteer — it's a fleet of scanners with a commercial incentive to stay fast.
The prisoner's dilemma dissolves once you notice the players aren't symmetric. Consumers can all wait; the scanners can't, and won't.
Three hours
The strongest evidence arrived after npm shipped the feature. On March 31, 2026, compromised versions of axios — 1.14.1 and 0.30.4, a package with roughly 100 million weekly downloads — were published carrying a fake dependency, plain-crypto-js, whose only job was an install script that pulled a cross-platform remote access trojan. Microsoft attributed the operation to Sapphire Sleet, a North Korean state actor. The malicious versions were live for about three hours.
Three hours. The s1ngularity attack in 2025: live around four hours, plus one more to revoke attacker access. The chalk/debug phishing wave that hit two-billion-downloads-a-week worth of packages in September 2025: caught the same day. Against this attack class — stolen maintainer credentials, noisy install-script payload, fast monetization — a 24-hour cooldown has a measured, repeatedly demonstrated win rate approaching 100%. Controls that demonstrably block real attacks are the opposite of theater.
Where the critique lands anyway
But notice what the win rate is conditioned on: attackers staying noisy. Install-script credential stealers get caught in hours because they execute at install time, which is exactly where every scanner looks first. A patient actor — and Sapphire Sleet is a state actor, not a smash-and-grab crew — can publish a payload that stays dormant, skips install scripts entirely, and triggers at runtime weeks later. Code that doesn't execute on install takes far longer to discover, and a seven-day gate does nothing against a fourteen-day fuse. Datadog's own security team, among the loudest cooldown advocates, concedes this openly. As cooldown adoption rises, the incentive to go dormant rises with it. Cooldowns don't end the game; they force the next move.
There's a second, more immediate cost: cooldowns delay fixes exactly as effectively as they delay malware. Here npm's implementation is genuinely behind. pnpm has minimumReleaseAgeExclude, Yarn has npmPreapprovedPackages, Bun has minimumReleaseAgeExcludes — npm's min-release-age has no exclusion mechanism at all, just an open issue asking for one. If a critical patch for an actively exploited vulnerability ships tomorrow, your npm cooldown holds it at the door with everything else, and your only options are lowering the global setting or pinning the version by hand.
What to actually configure
Turn it on — it's cheap and it works today. But size it to the evidence: takedowns happen in hours, so one to three days captures essentially every observed incident. Seven days buys little additional safety while maximizing patch delay.
# .npmrc — npm 11.10.0+, value in days
min-release-age=2
# pnpm-workspace.yaml — value in MINUTES
minimumReleaseAge: 2880
minimumReleaseAgeExclude:
- "@yourorg/*"
Mind the units: npm counts days, pnpm and Yarn count minutes, Bun counts seconds. That inconsistency is exactly the kind of thing that turns a two-day policy into a two-minute one during a copy-paste.
Then remember what the axios incident actually teaches: the payload ran because install scripts run by default. ignore-scripts=true would have made the whole attack a no-op, and npm v12 — expected later this year, per current signals from the CLI team, though not yet shipped — plans to make blocked install scripts the default. That, plus trusted publishing killing long-lived tokens, is the structural fix. Cooldowns are the seatbelt you wear while the ecosystem gets around to building the crumple zone. Wear the seatbelt. Just don't confuse it for one.
Sources & further reading
- NPM's release cooldown is security theater — blog.outv.im
- NPM's release cooldown is security theater — discussion — news.ycombinator.com
- npm Introduces minimumReleaseAge and Bulk OIDC Configuration — socket.dev
- The case for dependency cooldowns in a post-axios world — securitylabs.datadoghq.com
- Mitigating the Axios npm supply chain compromise — microsoft.com
- Locking down dependency installs across npm, pnpm, yarn, and bun — craigory.dev
Emeka has spent over a decade tracking threat actors, vulnerability disclosures, and the evolving landscape of application security, bringing a sharp continent-spanning perspective to his reporting. He's known for translating dense CVE advisories into clear, actionable context that developers and security teams alike actually read.
Discussion 0
No comments yet
Be the first to weigh in.