Comment by stbenjam
8 hours ago
IMHO defaults for uv, npm, etc should all have a cooldown for 24 - 48 hours by default, you should have to go out of your way to install something newer.
8 hours ago
IMHO defaults for uv, npm, etc should all have a cooldown for 24 - 48 hours by default, you should have to go out of your way to install something newer.
I use safechain for this, because there is always gonna be another package manager configured wrong. https://github.com/AikidoSec/safe-chain
We have 7d cooldown on packages on an internal pypi proxy but that blocks security updates also, which we now have to manually exclude from the cooldown.
I’m unsure how to automate this properly, maybe an LLM is the best starting point.
Are security updates immune ?
They definitely wouldn't be if attackers knew that it would then bypass cooldowns!
Ultimately, you need someone to verify releases and that probably means paying for it. I know Sonatype paid solutions utilise their own internal research to allow/block new releases.
It’s in the name. They are secure!
No, but there's a bigger tradeoff for not upgrading. In one case it's that you're potentially exposed to a known vulnerability, vs the other case where you might just be missing out on some new or slightly reworked feature.
But then an attacker marks their malicious release as a critical security update. It's really messy unfortunately.
1 reply →
Problem is, we leave ourselves open for LLM injection attacks.
I didn't realize they've all such added that, this was a change we made to our own projects last year when these first started - glad to see it's common.
Risk is ensuring enough security researchers are finding these and quarantining these before that default cooldown lapses.
Yea, I think all the tools have this now but its not a default. Install scripts should also be turned off by default and require some hassle to turn them on for the first time in a package.
I’d imagine there were probably fixes for critical CVEs that were included …. A lot of companies are on a 24 hour timeline to get them out.
The last time I looked for information, I remember seeing that the median supply chain attack was in place for multiple months to years before being discovered. Cooldowns shorter than that seem like snake oil.
If we all implement a cooldown, nobody will find the attack. This implies the cooldown length must be the cooldown length plus one month.
No, because there are malware-finding mechanisms other than "let some unlucky guy get affected first", like automated scanners. If everyone implements a cooldown, everyone will in fact be safer.
Plus some random value slow curve distribution. Basically incremental rollout from the client side. But if it's not caught at the commit time, attacker will just wait for a certain point on the curve.
You tell people that the cooldown needs to be a day, while you implement a two month cooldown.
1 reply →
I wonder if in some cases it's not so much that people are updating too quickly, but rather, their deployment pipelines do not have pinned / frozen versions attached to their builds.
Then we’ll find out about malware 24 - 48 hours later.