I think that once such systems are set up and have reached parity with the most recent releases of dependencies, the business of keeping up is much easier, whic

I think that once such systems are set up and have reached parity with the most recent releases of dependencies, the business of keeping up is much easier, which makes it more likely to happen. We've all been in the situation where we fell behind some dependency and, upon trying to upgrade, found that we were so far behind that everything was broken in this-will-take-weeks-to-fix ways. That kind of work tends to get shunted into the too hard pile, where it generally only gets harder. Eventually the codebase ossifies around a very particular dependency set that can't be upgraded without stopping feature development. The fact that it may be carrying a stew of published vulnerabilities tends not to be enough to trigger a change: work to upgrade is concrete, immediate and costly. Exploited vulnerabilities are probabilistic, sometime in the future and not taken from the current budget. In practice stuff is kept up to date by rigid process discipline or by automation. Of the two, automation is more likely to be successful and sustained.