npm's release cooldown is security theater

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 unnoticed
• or succeeds

And 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.

Idea update after a discussion with HN #

I submitted this post to Hacker News and got many insightful feedbacks and counter-opinions.

• Thanks to the market's invisible hand, security companies and researchers will always exist to scan the packages for free because they profit from this (e.g. advertising for their products and earning fame).
  • This is the most popular opinion in comments, although I don't think this is persuasive enough. It's okay to store pensions in ETFs like QQQ/VOO because companies are eventually making money in the market, but I don't think people should think the same when it comes to security. Also, whether the scope of these researchers would cover all dependencies people use is an issue.
• Although the benefit from a long-time cooldown may be limited compared to a short-time cooldown, a short-time cooldown does have some great benefits compared to no cooldown: it gives maintainers time to realize and announce incidents (e.g. account hacked).
  • This did convince me that cooldown is useful and is not 100% security theater. This would help in one scenario where malicious packages are posted due to stolen account credentials. Maybe npm should enforce some PRMFA^[1].
• There will always be people using a new package first. Just let them be the testbench.
  • This is a take on game theory. Different people have different preferences towards risk.