Linux Kernel Security Done Right (Google Security Blog)

You don't even need to seek bureaucracy to see such problems in field. Even at the engineer's level it's extremely common to see people not interested in providing updates, just in the same stable branch. Look at the previous thread right here about stable kernels where it's easy to find cases such as "been hit by a regression once, no thanks". The whole chain from the engineer to the CEO needs to be convinced that regular updates are a necessity. But for this it's also important to make them understand that "regular" or "frequent" updates does not require systematically upgrading to the latest one each time one is out, but that every time there is an opportunity for an update, it ought to be evaluated and performed. Also one must not think in terms of "what could this update bring me" but "do I have a really good and compelling reason for not applying it". This involves better tooling to perform automatic fetches, updates, rebase, oldconfig, builds, regtests etc from latest kernels, but we must pass the message that this is mandatory, it's not an option.

Right now the benefit of updating it often not perceived, hence is often balanced against the risk of rergression and that's what must change. Updating is not a benefit, it's a necessity. The exception should be not updating for a good reason.