NPM's release cooldown is security theater

2026/7/21 · #tech · ~2.5k words · Views:...Due to many ecosystem attack incidents, package managers (and packagers, and managers) are apparently falling in love with cooldowns these days (npm, pnpm, yarn and so on). As a result, their upstream registry is time-gated for some 7 days or 24 hours.Sounds sweet as honey. Except that it is not going to work. I'll say it's not honey, but a honeypot that traps.Waiting for security, or Godot Some are waiting for the community to "vet" the package before installing it. However, people don't know what's the appropriate cooldown time (e.g. 7 days for yarn, 3 days for pnpm). Also, a spoiler: people have no idea who would vet, either.The implicit assumption is that someone out there (in the community) will:install every package early (because they are warmhearted)notice something wrong (because they are smart)and raise the alarm before the crowd gets to it (because they have the best cyber loudspeaker)all for free!But the reality isn't that generous. If everyone sets a cooldown, there will be no early adopter. Everyone is waiting for everyone else to be the canary, and the canary does not exist.So they are waiting for Godot, and... Godot is not coming.Leaning on CI/CD, which is either useless or too late Some others use a pipeline or some CI/CD (yes, not necessarily human) that pulls the latest package through some dependabot PR.When there is malicious code, one of the two results will happen (depending on whether the CI is exploitable/valuable):the exploit either gets unnoticedor succeedsAnd the PR gets merged and devs hit npm install without a second thought. Since nobody and nothing looks at the still-untrusted code (reading package-lock.json does not count!), people and machines are unaware of the issue before installing, and malicious code is only found when the impact starts to show. Needless to say it would be too late.So, I'd say DYOR matters indeed In a word, waiting without taking action doesn't work. But what to do instead? I would suggest "Do Your Own Research":Treat vendored code like some random Windows EXE downloaded from the Internet. Bring the static analysis tools. Bring SASTs. Bring the sandboxes. Bring your hips HIPS.Run LLM-assisted audit on vendored code.Of course, before the dependabot PRs get merged or devs install them on their boxes.Stop cooling down or laying flat. Instead, start active scanning, so it's no longer a movie in the security theater.