> zero day is going to bite you in the ass

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.

▲

jcalvinowens 9 hours ago | parent [-]

My codebase runs on top of the same millions of lines of decades old system code that yours does. You don't seem to appreciate that :)

	▲	smaudet 9 hours ago \| parent [-]
		If you mean operating system code, that is generally opaque, and not quite what the article is talking about (you don't use a dependency manager to install code that you have reviewed to perform operating system updates - you can, and that is fantastic for you, but not I imagine what you mean). 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.