Live data from Hacker News

NPM's release cooldown is security theater

blog.outv.im

21–30 of 78 posts

Re: NPM's release cooldown is security theater

#21

> 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. Except there are researchers chomping at the bit to download every new release of packages in search of vulnerabilities they can exchange for fiat, reputational credit, or both.

*champing at the bit

Re: NPM's release cooldown is security theater

#22

Earlier quoted context omitted.

I do appreciate these security companies a lot (for example, Snyk), but I feel it hard to believe this is sustainable. Especially in the current world where LLM is devaluing security researchers' work. If they cannot get enough fiat or credit, this will eventually turn to some incident like OpenSSL heartbleed or so.

It's bold to call something that has prevented real-world attacks "security theater", with the justification that one day the world might change enough that it's less likely to prevent future attacks. Was the printing press worthless, just because we have laser printers nowadays? Anyhow, If you believe LLMs will kill security research, then surely you must also believe a cooldown of 1 week would be enough time for yo…

I think it's great if people actually use LLM for the analysis. I did mention it in the solution part in the post:

> Run LLM-assisted audit on vendored code.

Re: NPM's release cooldown is security theater

#23

> 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. Except there are researchers chomping at the bit to download every new release of packages in search of vulnerabilities they can exchange for fiat, reputational credit, or both.

I do appreciate these security companies a lot (for example, Snyk), but I feel it hard to believe this is sustainable. Especially in the current world where LLM is devaluing security researchers' work. If they cannot get enough fiat or credit, this will eventually turn to some incident like OpenSSL heartbleed or so.

LLM is only devaluing security work by competition. As in, it's making dependency scanning so easy and cheap that researchers don't have much left to do on that front. The end result is very easy and cheap dependency scanning available to everyone. It makes the next heartbleed less likely, not more (though actually the class of bugs it protects against is closer to log4shell).

Re: NPM's release cooldown is security theater

#25
post #7

The archaic model where every tool gets full access to your home directory was never designed for the scenario where a single npm install will install and execute 100s of packages written by various authors. One should sandbox all npm command executions. https://github.com/ashishb/amazing-sandbox

Switch to another user, idealy called 'npm'.

        su -l npm
Then, just in case, run it under bubblewrap so it just can use $HOME and nothing more.

Re: NPM's release cooldown is security theater

#26
Even setting aside that there are, in fact, many human and robot eyes staring hard at the firehose of published packages on popular registries, the whole argument feels like a false dichotomy.

If you're going to "DYOR" or whatever, having your automated dependency management on a cooldown timer seems like a snazzy way to smoothly provide a window for all your fancy dependency validation to happen.

Re: NPM's release cooldown is security theater

#27
I wonder if the author has ever worked in IT. The idea of not moving quickly to new software versions has been around for decades.

There are always early adopters and researchers looking at new, publicly available software. Critical industries have long waited for software releases to be stable and "recommended" by the vendor before upgrading, letting those early adopters who can afford some availability risk take time with it.

The observation that "if everyone in production has a cooldown, the benefit is gone" is an absolutist opinion.

I have seen this occur in some fashion - my company's product has a software version that's been out for almost six months and we still tell customers in critical industries to stay on the older version out of an abundance of caution and with the understanding of what upgrades require for them. Stability > features.

Re: NPM's release cooldown is security theater

#28

Earlier quoted context omitted.

It's bold to call something that has prevented real-world attacks "security theater", with the justification that one day the world might change enough that it's less likely to prevent future attacks. Was the printing press worthless, just because we have laser printers nowadays? Anyhow, If you believe LLMs will kill security research, then surely you must also believe a cooldown of 1 week would be enough time for yo…

I think it's great if people actually use LLM for the analysis. I did mention it in the solution part in the post: > Run LLM-assisted audit on vendored code.

What do you call the time period between "new package is released" and "automated security scanners have analyzed the package"? That sure sounds like a release cooldown to me.

Re: NPM's release cooldown is security theater

#30

> 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. Except there are researchers chomping at the bit to download every new release of packages in search of vulnerabilities they can exchange for fiat, reputational credit, or both.

That's better than nothing, but if you're expecting people to be looking at something before you use it, you should be waiting for a thumbs up from them, not waiting some arbitrary timespan for the absence of a thumbs down.

You should probably also be paying them directly.

Post reply on HN