Do you upgrade all your dependencies every day? If not, then there’s no real difference in upgrading as if it were 7 days ago.
Of course we talk about OS security upgrades here, not library dependencies. But the attack vector is similar.
If upgrading like that scares you, your automated testing isn't good enough.
On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs since.
Maybe your codebase is truly filled with code that is that riddled with flaws, but:
1) If so, updating will not save you from zero days, only from whatever bugs the developers have found.
2) Most updates are not zero day patches. They are as likely to (unintentionally) introduce zero days as they are to patch them.
3) In the case where a real issue is found, I can't imagine it isn't hard to use the aforementioned security vendors, and use their recommendations to force updates outside of a cooldown period.
Although, even for Operating Systems, cooldown periods on patches are not only a good thing, but something that e.g. a large org that can't afford downtime will employ (managing windows or linux software patches, e.g.). The reasoning is the same - updates have just as much chance to introduce bugs as fix them, and although you hope your OS vendor does adequate testing, especially in the case where you cannot audit their code, you have to wait so that either some 3rd party security vendor can assess system safety, or you are able to perform adequate testing yourself.
Some of these can be short-lived, existing only on a minor patch and fixed on the next one promptly but you’ll get it if you upgrade constantly on the latest blindly.
There is always risks either way but latest version doesn’t mean the “best” version, mistakes, errors happens, performance degradation, etc.
I think you're using a different definition of zero day than what is standard. Any zero day vulnerability is not going to have a patch you can get with an update.
Yes. I'm saying that's wrong.
The default should always be to upgrade to new upstream releases immediately. Only in exceptional cases should things be held back.
> this is clearly a straw man, as no one is saying you'd wait seven days to deploy THAT patch...
The policy being proposed is that upgrades are delayed. So in a company where that policy was enforced, I would be required to request an exception to the policy for your hypothetical patch.
That's unacceptable for me. That's requiring me to do extra work for a nebulous poorly quantified security "benefit". It's a waste of my time and energy.
I'm saying the whole policy is unjustified and should never be applied by default. At all. It's stupid. Its harmful for zero demonstrable benefit.
I'm being blunt because you seem determined to somehow misconstrue what I'm saying as a nitpicky argument. I'm saying the whole policy is terrible and stupid. If it were forced on me by an employer, I would quit. Seriously.
You will not know how long it takes to get a zero day fixed, because zero in "zero day" ends when the vendor is informed:
> "A zero day vulnerability refers to an exploitable bug in software that is unknown to the vendor."
Realistically, no one does full side-by-side tests with and without lockfiles, but it's a good idea to at least do a smoke test or two that way.