Awesome!
Will add it to depsguard.com this weekend.
Cooldown Support for Ruby Bundler
41–46 of 46 posts
Re: Cooldown Support for Ruby Bundler
#42Hypothesis: a big accelerant of these rapid repository compromise (from Red hat to GitHub to Amazon to small startups) might be GitHub+dependabot automatic dependency updates. So, just like COVID-19 used air travel, modern malware attacks are relying on GitHub+dependabot to speed up the spread. Even for single page website built using Vue, I would get about 5 updates a week.
So. Dependabot (and renovate) do have "cooldowns" supported, just need to set them up.
For dependabot it's as simple as
cooldown.default-days: 1
There are security researchers (that don't have cooldowns) that usually detect compromises within hours or less, and package managers almost always manage to remove the offending versions in less than 24 hours (usually much less).
So people will 24 hours cooldowns get protected.
Shameless plug: I maintain depsguard.com that tries to simplify cooldowns setup across anything that supports it, in one command (it scans from where you run it, e.g. if you run it from your user folder it will look for any local repos with dependabot / renovate and suggest a change.
Re: Cooldown Support for Ruby Bundler
#43Earlier quoted context omitted.
I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.
Yep, 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.
How many people are paying security firms to test these things during the cooldown period? Which security firms are testing which packages?
Re: Cooldown Support for Ruby Bundler
#44Earlier quoted context omitted.
Yep, 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.
How many people are paying security firms to test these things during the cooldown period? Which security firms are testing which packages?
> 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.
Re: Cooldown Support for Ruby Bundler
#45Hypothesis: a big accelerant of these rapid repository compromise (from Red hat to GitHub to Amazon to small startups) might be GitHub+dependabot automatic dependency updates. So, just like COVID-19 used air travel, modern malware attacks are relying on GitHub+dependabot to speed up the spread. Even for single page website built using Vue, I would get about 5 updates a week.
So. Dependabot (and renovate) do have "cooldowns" supported, just need to set them up. For dependabot it's as simple as cooldown.default-days: 1 There are security researchers (that don't have cooldowns) that usually detect compromises within hours or less, and package managers almost always manage to remove the offending versions in less than 24 hours (usually much less). So people will 24 hours cooldowns get protec…
> For dependabot it's as simple as
> cooldown.default-days: 1
Most people stick to default of 0. In fact, I am realizing over time that it is best to make it 7-14 days.
Re: Cooldown Support for Ruby Bundler
#46Earlier quoted context omitted.
I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.
If 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.
the we/you are different in each case. say I maintain some package, foo, and I want to publish foo-3.5 which contains a security issue. in the cooldown scenario I push the new version to the package repository (rubygems/pip/npm/whatever), and the package manager when asked to `install foo` continues reporting 3.4 as the latest version until the cooldown period has passed. this happens automatically for all packages and all end users. simultaneously, a security firm could look at the log of new package submissions and take a closer look at anything that triggers their "this is an important/widely used package" filter, and if they find something during the cooldown period the new release could be removed from the repository without anyone having installed it.
in the "find the vulnerability before release" scenario, how do I push version foo-3.5? is it my responsibility as the package author to find a security firm and have them audit it before submitting to the repository? should the org owning the repository shunt my package update to a holding pen until it can be vetted, and if so do they have to pay a designated security firm and give them special access to the holding pen, or can anyone reads the incoming packages and help vet them? and if no one has looked at a package in a while do you delay it indefinitely or so you let it time out and be released? that's basically back to the cooldown idea, only implemented on the server rather than the client, and therefore not letting individual clients tune what they believe is a good cooldown time.