It's important to understand that you can't go by major version numbers in most fixed-release, long term support Linux Operating Systems, like RHEL, Debian, or Ubuntu. There is often deeper investigation needed.

https://access.redhat.com/security/updates/backporting

https://www.redhat.com/en/blog/what-backporting-and-how-does...

Red Hat's business model is that they ship a defined set of components and patch those components as needed for years without breaking compatibility.

Red Hat explicitly will not ship a component unless they can build it from source and update it, and have confidence that they can continue to do so for the life of the OS version.

That's what being a responsible "enterprise" operating system vendor means.

Older releases aren't the problem as long as they're maintained, which RH devs are good doing so.

Taking a 4+ year old release and not applying any patches even if upstream did their due diligence with informing users about a lot of fixed stuff and then shipping that by default is rather unacceptable by the OS distro vendor though.

At least RedHat backports security patches.

The core value proposition of suse, red hat, ubuntu lts is binary compatible drop in replacements to a froze version. Which has been created and received tons of back ported bug fixes during it's 3-9 months curing process aka beta program. So security updates keep coming and are fixed, while your application does not need to be forward ported, and has a rock solid foundation underneath.

So the components are deliberately old. And bug fixed. And security maintained.