10 ms·
I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.
by grncdr 3mo ago
I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.
- woodruffw 3mo agoYep, this is the thesis behind them. I wish people engaged more fully with this argument: it’s possible to believe that security vendors won’t do a good job of upholding their side of the bargain, but I’ve yet to see anybody argue that rather than making a faulty universalization argument against cooldowns.
- mike_hock 3mo agoAnything that isn't blatantly obvious zero effort malware is gonna wait for the cooldown to expire and then gradually introduce backdoors or vulnerabilities in subsequent versions once the project has gained trust.
- woodruffw 3mo agoI think you’re talking about something different than the median case here: the kinds of malware that cooldowns are effective against are attacking already trusted projects, e.g. via repository compromise. I think it remains to be seen whether the economics of this kind of “supply chain” compromise support a stealthier actor profile: the whole reason to compromise an OSS project rather than exploit a single victim’s browser or phone is to smash-and-grab en masse. That’s a fundamentally noisy and delay-sensitive attacker profile.
- rendaw 3mo agoHow many people are paying security firms to test these things during the cooldown period? Which security firms are testing which packages?
- woodruffw 3mo ago> How many people are paying security firms to test these things during the cooldown period? More than I think should be, frankly. More than enough for a sustainable industry. As for “which firms”: if you Google any of the recent dependency compromises, you’ll see their names. My rough guess is that there are somewhere between 12 and 20 active players in the “supply chain security” space, and they generally compete for mindshare with blogspam. That’s not to say their scanning results aren’t good, though.
- weinzierl 3mo agoIf this is the idea, why don't we let the dedicated security firms and/or automated scanners find the vulnerabilities before the release? You need an early release in the "given enough eyeballs all bugs are shallow" world because you need the eyeballs, but if you count on specialists and scanners no general availability release is necessary and hence no cool down.
- john_strinlai 3mo agoi am not sure what the benefits of your proposal are compared to the "cooldown period" way. the releases will be delayed for the same time period, but you increase the amount of coordination required significantly and reduce user agency.
- weinzierl 3mo agoCurrently we release software to the public early and let people find vulnerabilities after release. A few early updaters get burned but the rest of us is saved. This cannot go on. One idea to get out of this mess is to use cooldowns. But this idea only works if what GP said is true: Vulnerabilities are mostly found by (paid) specialists and advanced tools and not the general user populations. My point is that, if that is true we do not need to release insecure software. Do the magic before the release and no one gets hurt.
- AgentME 3mo agoWe could rename "cooldown" to "pre-release period".
- nixpulvis 3mo agoBecause this isn't about guarding against general vulnerabilities. This is about guarding against a class of supply chain attack where an attacker compromises the packaging system in a way that they slip in a malicious release. It is true if everyone waits a cooldown (I don't like this name, but that's another thing) period, then it doesn't solve anything, but as others have pointed out, just because you don't build off the cooldown doesn't mean you and others aren't watching the releases. Closing the window makes the burden of hiding the exploit higher, which is I think objectively an improvement of security posture.