This happens all the time on systems that are running hundreds of thousands of apps across hundreds of customers.

The worst one I know: for a while basically all Cloud Foundry installations were stuck behind a patch release because the routing component upgraded their Go version and that Go version included an allegedly non-breaking-change that caused it to reject requests with certain kinds of malformed headers.

The Spring example app has a header with the specific problem impacted. And the vast majority of Cloud Foundry apps are Spring apps, many of which got started by copying the Spring example app.

So upgrading CF past this patch release required a code change to the apps running on the platform. Which the people running Cloud Foundry generally can’t get — there’s usually a team of like 12 people running them and then 1000s of app devs.

Yes, I have an example in mind - https://askubuntu.com/questions/1376118/ubuntu-20-04-lts-una...

Yes, it's Ubuntu, but doesn't matter - sometimes security fixes require a breaking change and there's nothing that can be done to avoid it.

OpenSSL isn't necessarily the best at LTS, but 1.0.1 released a series of changes to how they handled ephemeral diffie hellman generation, which could be hooked in earlier releases, but not in later releases.

For the things I was doing on the hooks, it became clear that I needed to make changes and get them added upstream, rather than doing it in hooks, but that meant we were running OpenSSL with local patches in the interim of upstream accepting and releasing my changes. If you're not willing to run a locally patched security critical dependency, it puts you between a rock and a hard place.