Fedora, CentOS Stream and RHEL Release History: How the Pipeline Works

Red Hat Enterprise Linux is built in three stages. New work lands first in Fedora, a community distribution that ships about every six months. A RHEL major version is then branched from Fedora into CentOS Stream, which Red Hat engineers develop in public as the branch that future RHEL minor releases are cut from. RHEL itself is the supported product with a ten year life cycle.

That order has only been true since December 2020. Before then, CentOS Linux sat after RHEL as a free rebuild of each RHEL release. Red Hat moved CentOS to the middle of the pipeline, ended CentOS Linux 8 on 31 December 2021 and CentOS Linux 7 on 30 June 2024, and in June 2023 made CentOS Stream the only public home for RHEL related source code. As of this writing (23 October 2026), RHEL 8, 9 and 10 are the current major releases. RHEL 10.2 and 9.8 shipped on 19 May 2026, Fedora 43 and 44 are supported, and Fedora 45 is in final freeze.

Key takeaways

• The pipeline runs Fedora, then CentOS Stream, then RHEL. RHEL minor releases are built from CentOS Stream, which is branched from Fedora.
• Fedora ships about every six months and supports release N until four weeks after N+2, about 13 months.
• RHEL 8, 9 and 10 each get ten years of Full and Maintenance Support, then an Extended Life Phase. Paid Extended Life Cycle Premium (ELCP) stretches individual minor releases further.
• Security defaults moved each major release. RHEL 8 made system wide crypto policies the default. RHEL 9 restricted SHA-1 signatures and stopped the config file from fully disabling SELinux. RHEL 10 added post-quantum algorithms, on by default from 10.1.
• CentOS Linux is gone and the rebuilds changed course after Red Hat limited public RHEL sources to CentOS Stream in June 2023.
• Patch from advisories, not version numbers. Red Hat backports fixes and publishes CSAF and VEX files; OVAL is in maintenance mode.
• Major upgrades go one version at a time with Leapp, and UBI container images follow the same advisories as RHEL hosts.

For the other big families, see the Ubuntu release history and Ubuntu's support life cycle explained. Debian has its own support story in is Debian 11 Bullseye end of life, and the security focused distribution that builds on Debian is covered in Kali Linux quarterly releases 2020 to 2026 and how Kali Linux is built.

How code flows from Fedora to CentOS Stream to RHEL

Stage 1: Fedora Rawhide and the Fedora releases

Fedora is the community distribution sponsored by Red Hat. The Fedora release life cycle page describes two development trees. Rawhide is the constantly rolling tree where packagers land new upstream versions. No release is ever built directly from Rawhide. About ten weeks before a planned release, a Branched tree is split off Rawhide for stabilisation, and Rawhide moves on to the release after that.

Updates to a Branched or released Fedora go through the Bodhi system, passing an updates-testing repository before they reach stable, with freezes before the Beta and Final milestones.

On the Fedora 45 key tasks schedule, Rawhide began Fedora 45 development on 3 February 2026, Fedora 45 branched on 11 August, the Beta shipped on 15 September and Final Freeze started on 20 October, with a final target of 3 November 2026.

Stage 2: Fedora ELN, the RHEL shaped rehearsal

Between Rawhide and CentOS Stream sits a lesser known project. Fedora ELN takes Rawhide's sources and builds them through a separate buildroot and compose that emulates a RHEL compose. There is no separate ELN branch; it reuses the Rawhide branch in dist-git. The point is feedback. Fedora packagers can see how their change would behave in a RHEL style build, and Red Hat can try ideas such as a higher CPU baseline without disturbing normal Fedora users.

Stage 3: CentOS Stream, the midstream

The CentOS Project describes CentOS Stream as a continuously delivered distribution that tracks just ahead of RHEL development, positioned as a midstream between Fedora Linux and RHEL. When a new RHEL major release is planned, a CentOS Stream major version is created from Fedora, and from then on that Stream evolves separately from Fedora.

The CentOS Project's CentOS Stream 10 announcement from 12 December 2024 states it directly: CentOS Stream is built by RHEL engineers and is used as the major version branch that RHEL minor versions are created from. It also tells contributors that some changes should go further upstream to Fedora, so that they reach the next major version of CentOS Stream and RHEL.

Contributions are real but gated. The CentOS Stream 9 page notes that proposed contributions are evaluated by the RHEL engineering team, "since a contribution to CentOS Stream is a contribution to RHEL."

Stage 4: RHEL minor releases

RHEL minor releases (9.6, 9.7, 9.8) are cut from the CentOS Stream branch for that major version and shipped with a support commitment. Red Hat's life cycle policy says errata within a major release are applied cumulatively to the latest release and that Red Hat makes commercially reasonable efforts to keep binary compatibility for the core runtime across all minor releases and errata.

When the model changed

Before December 2020, CentOS Linux came after RHEL as a free rebuild of published RHEL source. On 8 December 2020 the CentOS Project announced in CentOS Project shifts focus to CentOS Stream that it would move from CentOS Linux, "the rebuild of Red Hat Enterprise Linux", to CentOS Stream, which "tracks just ahead of a current RHEL release." CentOS Linux 8 would end at the end of 2021, and CentOS Linux 7 would continue for the rest of the RHEL 7 life cycle.

RHEL 9 was the first major release built this way from the start. The CentOS Stream 9 timeline shows sources available on 19 February 2021, the first community contribution merged on 5 May 2021 and the distribution on mirrors on 30 September 2021. RHEL 9.0 followed in May 2022.

RHEL major releases 5 to 10: dates, kernels and support phases

Red Hat's RHEL release dates article lists every major and minor release with its general availability date and kernel version. The life cycle page, the retired life cycle dates article and the legacy extended support page give the phase end dates. Red Hat states that future dates are close approximations and subject to change.

Timeline

A few notes on that table. The RHEL 2.1 and RHEL 3 rows come from the same Red Hat article but predate the Fedora pipeline; RHEL 3 was based on Red Hat Linux 9, the last of the old boxed Red Hat Linux releases, and Fedora Core 1 followed in late 2003. Red Hat's own pages disagree by a day on a few GA dates: the release dates article gives 22 October 2003 for RHEL 3, 15 February 2005 for RHEL 4, 9 November 2010 for RHEL 6 and 17 May 2022 for RHEL 9, while the retired dates table and the product life cycle data give 23 October 2003, 14 February 2005, 10 November 2010 and 18 May 2022. Both are Red Hat sources; the difference is likely a time zone or announcement versus availability distinction. The RHEL 8 release notes describe 8.0 as "based on Fedora 28 and the upstream kernel 4.18."

Notice the kernel column. Every RHEL major release keeps one upstream kernel base for life: RHEL 9.8 in 2026 still reports 5.14, like RHEL 9.0 in 2022, because Red Hat backports fixes and hardware enablement into that base. This is why a version comparison against upstream kernel.org releases is wrong for RHEL, a point we cover in detail in checking whether a distro backported a security fix.

The RHEL 8, 9 and 10 support phases

RHEL 8, 9 and 10 share the same structure. Red Hat describes a ten year life cycle across a Full Support Phase and a Maintenance Support Phase, followed by an Extended Life Phase and optional extended support.

The standard errata criteria matter for planning. Red Hat's policy defines security errata as fixes for Critical, Important, and Moderate CVEs with a CVSS score of 7 or higher, effective 1 April 2025. In other words, a Low severity issue, or a Moderate one scored below 7, may never be fixed in a maintained RHEL release. Our post on how to read a Red Hat severity rating versus CVSS explains why Red Hat's own rating often differs from the NVD score.

Support dates for every major release

The RHEL 8, 9 and 10 dates come from Red Hat's product life cycle data and the older ones from the retired dates table. For RHEL 7, Red Hat's retired table lists 6 August 2019 as the end of full support for the ARM, POWER9 and IBM Z variants; the CentOS Project's end dates post confirms that RHEL 7 reached end of maintenance on 30 June 2024, and the legacy page says ELS for RHEL 7 started that day. We could not confirm the final RHEL 7 ELS end date on a Red Hat page we could fetch, so check the life cycle page before planning around it.

How Extended Life Cycle Premium changed minor release support

The minor release story changed in the current life cycle policy. Red Hat now sells three tiers for a minor release:

• RHEL Standard: six months per minor release. When 9.8 ships, 9.7 stops receiving fixes on the standard stream.
• RHEL Premium: two years for eligible minor releases.
• Extended Life Cycle Premium (ELCP): six years from GA for even numbered minors from RHEL 9.2 onward (9.2 to 9.10, 10.2 to 10.10), and nine years for each major version's final .10 release.

ELCP replaces the older EUS, Enhanced EUS and E4S offerings, and replaces Extended Life-cycle Support (ELS) beginning with RHEL 8.10 on 1 June 2029. After ELCP, renewable one year Long-Life terms continue errata; if a customer stops renewing, content stays in a retired channel with no new fixes.

For security teams this means two servers both reporting "RHEL 9" can be on different patch streams: one on 9.4 with ELCP still gets fixes, while one on 9.5 without an extension stopped getting them when 9.6 shipped.

Security features by major release

Each major release moved a security default. The table summarises the changes that affect day to day operations; the sections that follow give the detail and the source for each.

SELinux: enforcing by default, and harder to switch off in RHEL 9

SELinux has been part of RHEL for many major releases, and the Red Hat family treats it as a baseline control rather than an optional extra. The biggest recent change came in RHEL 9. The RHEL 9.0 release notes say support for disabling SELinux through the SELINUX=disabled option in /etc/selinux/config was removed from the kernel. If you set only that option, the system boots with SELinux enabled but with no policy loaded, which is the worst of both worlds. To truly disable it you now add selinux=0 to the kernel command line.

RHEL 10 continued in the same direction. Its 10.0 release notes list SELinux userspace 3.8, new policy rules that confine more systemd services so they no longer run as unconfined_service_t, and a public c10s branch in the selinux-policy Git repository so CentOS Stream contributors can work on the RHEL 10 policy directly. That last item is the pipeline in miniature: the policy is developed in the open in the Fedora organisation and flows to RHEL. If you are tempted to switch SELinux off, read SELinux permissive versus disabled first, and how to turn SELinux back on after it was disabled if someone already did.

System wide crypto policies: from a Fedora 21 change to RHEL 8 default

System wide cryptographic policies are a good example of the pipeline. The idea started as a Fedora change proposal targeted at Fedora 21, which aimed to "unify the crypto policies used by different applications and libraries" so an administrator could set one security level for TLS libraries and gradually more applications. It matured in Fedora and became a default in RHEL 8. The RHEL 8.0 release notes say the policies cover TLS, IPsec, SSH, DNSSEC and Kerberos, are applied by default, and are managed with the new update-crypto-policies command.

The RHEL 9 security hardening guide defines the four predefined policies:

Subpolicies adjust a base policy. RHEL 9 ships a SHA1 subpolicy (applied as DEFAULT:SHA1) for systems that must verify old SHA-1 signatures, and RHEL provides a FIPS:OSPP subpolicy with the extra restrictions needed for Common Criteria certification. Red Hat warns that the FIPS policy alone does not guarantee FIPS 140 compliance.

RHEL 9: SHA-1 deprecated, fapolicyd grows up

The RHEL 9.0 release notes record that SHA-1 for cryptographic purposes was deprecated, that core crypto components no longer create signatures using SHA-1 by default, and that except for HMAC, SHA-1 is no longer allowed in TLS, DTLS, SSH, IKEv2, DNSSEC and Kerberos under the DEFAULT policy. Use the DEFAULT:SHA1 workaround only as a temporary bridge on the specific host that needs it.

RHEL 9 also shipped fapolicyd 1.1, an application allow listing framework that decides which binaries may execute. A new RPM plugin tells fapolicyd about files installed or changed during an RPM transaction, which gives it integrity checking tied to the package database.

RHEL 10: post-quantum cryptography, Sequoia and image mode

• Post-quantum readiness. In 10.0, post-quantum algorithms were a Technology Preview: crypto-policies, OpenSSL, GnuTLS, NSS and OpenSSH could work with them, and a crypto-policies-pq-preview package provided a TEST-PQ subpolicy. In 10.1, the 10.1 release notes say the system wide policies "enable post-quantum cryptography (PQC) algorithms in all policies by default." Hybrid ML-KEM key exchange and pure ML-DSA signatures are enabled in LEGACY, DEFAULT and FUTURE with the highest priority, and the FIPS policy enables them too. OpenSSL 3.5 adds ML-KEM, ML-DSA and SLH-DSA and puts the hybrid ML-KEM groups in the default TLS group list.
• Sequoia for OpenPGP. RPM verifies package signatures with the rpm-sequoia library instead of its old custom PGP parser, and librepo now uses it too for DNF repository signatures. The sq and sqv command line tools sit beside GnuPG.
• OpenSSH 9.9. Up from 8.7 in RHEL 9. ssh-keygen now creates Ed25519 keys by default, except in FIPS mode where the default stays RSA.
• FIPS at install time only. The fips-mode-setup command is removed. You enable FIPS mode by adding fips=1 to the kernel command line during installation, and the old /etc/system-fips marker file is gone. Image mode systems can be built with FIPS mode enabled. HMAC-SHA-1 in FIPS mode is deprecated.
• Attestation. Keylime 7.12 and the Rust agent 0.2.5 add IDevID and IAK device identity, TLS 1.3 by default and configurable IMA log locations, and RPM gains per-file IMA signature verification.
• Image mode. RHEL can be built and updated as a bootable container image with bootc, so the OS becomes an artifact you build, scan and sign in CI.
• A higher CPU floor. RHEL 10 requires x86-64-v3 on AMD and Intel 64-bit hardware, and GCC 14 defaults to it. RHEL 9 required x86-64-v2. Older hardware that ran RHEL 9 may not boot RHEL 10.

How Fedora's six month cadence and 13 month support work

The Fedora release life cycle says the project releases a new version about every six months and maintains each release for about 13 months. The schedule is "a hybrid of time and quality": releases are time based, but each milestone must pass the Fedora Release Criteria or it slips.

The mechanics:

• Target dates. Schedules repeat with early targets on the third Tuesday of April and October. Fedora publishes an early target and a series of later targets. Contributors aim for the early target; users should plan on Target date #1.
• Slips are weekly. A "No Go" at the Final Go/No-Go meeting moves the release one week, keeping Tuesday releases.
• Support length. Release N is supported until four weeks after release N+2. That is why the window is "about" 13 months, as the releases overview also states.
• After end of life. No updates are created, and new builds for that release are not allowed.

Recent releases show how consistent this has become. Fedora's end of life list and the per release schedules give these dates:

The release dates for Fedora 38 to 42 are derived from Fedora's own end of life table (end of life date minus the days supported it lists), so treat them as accurate to Fedora's arithmetic rather than as separately confirmed. For Fedora 43, the Fedora 43 schedule puts end of life at 9 December 2026 based on the early target, while the Fedora 45 schedule lists the Fedora 43 end of life bug closure for 16 December 2026. Both will move if Fedora 45 slips.

The life cycle page also says something candid: "If you want a distribution that moves slower, but has a longer lifecycle, CentOS Stream or Red Hat Enterprise Linux, which are downstream of Fedora might be more suitable for you." That one sentence is the whole pipeline from Fedora's side.

Fedora's end of life list goes back to Fedora Core 1, which reached end of life on 20 September 2004 after 320 days, putting its release in early November 2003. The list switches from "Fedora Core" to "Fedora Linux" at release 7.

Fedora editions, atomic desktops, spins and labs

fedoraproject.org groups its deliverables into editions, atomic desktops, spins and labs.

The atomic desktops and CoreOS treat the OS as an image replaced as a whole on update, the same idea RHEL 10 brought to the enterprise as image mode.

What happened with CentOS Linux end of life, and how the rebuilds responded

The end of CentOS Linux

The CentOS Project published three clear dates.

1. 8 December 2020: the shift to CentOS Stream was announced. CentOS Linux 8 would end at the end of 2021 instead of running to 2029 with RHEL 8. CentOS Linux 7 would continue for the rest of the RHEL 7 life cycle.
2. 31 December 2021: CentOS Linux 8 reached end of life, with a final rebuild of RHEL 8.5 and its content moved to vault.centos.org after 31 January 2022.
3. 30 June 2024: CentOS Linux 7 reached end of life alongside the end of RHEL 7 maintenance. On the same timetable, CentOS Stream 8 reached end of builds on 31 May 2024, roughly matching RHEL 8.10.

The CentOS download page lists end dates of 31 May 2027 for CentOS Stream 9 and 31 May 2030 for CentOS Stream 10, the ends of RHEL 9 and 10 Full Support. A Stream lives only while its RHEL major release takes new features.

Source availability in June 2023

On 21 June 2023, Red Hat's Mike McGrath wrote in Furthering the evolution of CentOS Stream that "CentOS Stream will now be the sole repository for public RHEL-related source code releases." Before that, Red Hat had pushed public RHEL sources to git.centos.org. Customers and partners still get RHEL sources through the customer and partner portals under their subscription agreements.

How the rebuild distributions responded

Two community rebuilds launched after the 2020 announcement, and both changed approach after 2023.

• AlmaLinux released its first stable version on 30 March 2021 as a "1:1 binary compatible drop-in replacement." On 13 July 2023 the AlmaLinux OS Foundation board decided to drop the aim to be 1:1 with RHEL. The foundation said this means it is no longer bound to bug-for-bug compatibility and can accept bug fixes outside Red Hat's release cycle.
• Rocky Linux shipped Rocky Linux 8.4 GA on 21 June 2021, describing itself as bug-for-bug compatible with the upstream Enterprise Linux standard. In Keeping Open Source Open on 29 June 2023, the Rocky Linux team wrote that it previously took sources only from the CentOS Git repository and now gathers them from CentOS Stream, pristine upstream packages and RHEL source RPMs.

The practical point: "Enterprise Linux compatible" no longer means one thing. A rebuild's errata, advisory IDs, timing and sometimes patches can differ from Red Hat's. Scan rebuild based containers and hosts against the rebuild's own security data, as we describe in scanning Rocky Linux containers, and do not assume a RHSA applies one to one.

How to read RHSA advisories and Red Hat's CSAF, VEX and OVAL data

Red Hat ships fixes as errata. There are three types: RHSA (security advisories), RHBA (bug fix advisories) and RHEA (enhancement advisories). An RHSA has an ID such as RHSA-2026:9874, a Red Hat severity (Critical, Important, Moderate or Low), the CVEs it fixes, and the exact package NEVRA (name, epoch, version, release, architecture) for each affected product and stream.

The release field is the part people misread. A package like openssl-3.0.7-27.el9 and a fixed openssl-3.0.7-29.el9_4 can share the same upstream version. The fix is in the release number and the stream suffix. That is backporting, and it is why we wrote why a version number can look vulnerable when the fix was backported. The same logic applies across the Red Hat family.

The machine readable feeds

Red Hat's Security Data page lists the feeds, all licensed CC BY 4.0:

Red Hat's note on OVAL is direct: OVAL/DS v2 files "are now in maintenance mode and will be deprecated in the future." If your scanner still depends on OVAL, ask its maintainers about their CSAF plans. Our post on Red Hat security data: CSAF, VEX, OSV and RSS, which feed for which job compares them in depth.

The per-CVE VEX file is the most useful single document because it also lists products that are not fixed, including ones Red Hat will not fix, which is exactly the case the errata criteria create for lower severity issues.

Pulling an advisory and a VEX file

# Download one CSAF advisory and list the fixed packages for RHEL 9
curl -s https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_9874.json \
  -o rhsa.json
jq -r '.document.title, .document.aggregate_severity.text' rhsa.json
jq -r '.vulnerabilities[].cve' rhsa.json

# Download the per-CVE VEX document and show product status buckets
curl -s https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-9999.json \
  -o vex.json
jq -r '.vulnerabilities[0].product_status | keys[]' vex.json
jq -r '.vulnerabilities[0].product_status.known_affected[]?' vex.json | head

# Watch the last three days of advisories
curl -s https://security.access.redhat.com/data/meta/v1/rhsa.rss | grep -o '<title>[^<]*' | head

The advisory and CVE numbers are simply the newest files in the index on the day we checked; substitute your own.

How to check versions, crypto policy and SELinux state

The walkthrough below runs on RHEL 8, 9 or 10, CentOS Stream, Fedora and most rebuilds. Every command is read only unless marked otherwise.

Step 1: identify the release and stream

cat /etc/os-release
cat /etc/redhat-release          # what Red Hat's own docs tell you to run
rpm -q redhat-release centos-stream-release fedora-release 2>/dev/null
uname -r                          # running kernel; compare the release field, not just 5.14 or 6.12
rpm -q kernel                     # installed kernels; the running one may not be the newest
sudo subscription-manager release --show   # RHEL only: shows a pinned minor release, if any

/etc/os-release gives ID, VERSION_ID and PLATFORM_ID (for example platform:el9). If subscription-manager release --show returns a minor version such as 9.4, the host is pinned to that minor release. That is normal on an ELCP or EUS stream and a problem if nobody bought the extension.

Step 2: check for outstanding security errata

sudo dnf updateinfo summary
sudo dnf updateinfo list --security
sudo dnf updateinfo list --security --sec-severity=Critical
sudo dnf updateinfo info RHSA-2026:9874          # details for one advisory
rpm -q --changelog openssl | grep -m5 CVE         # did a backport land in this build?

On Fedora, the advisory IDs are FEDORA-YYYY-xxxx from Bodhi rather than RHSA, but the same dnf updateinfo commands work.

Step 3: apply only security fixes, then confirm the reboot

sudo dnf upgrade --security                        # changes the system
sudo dnf upgrade --advisory=RHSA-2026:9874         # or one advisory
sudo dnf needs-restarting -r                       # exit code 1 means a reboot is needed

A kernel or glibc fix is not live until the host restarts. "Patched" in the package database and "patched" in the running kernel are different states.

Step 4: read the crypto policy and FIPS state

update-crypto-policies --show                      # DEFAULT, LEGACY, FUTURE, FIPS, plus any subpolicy
cat /proc/sys/crypto/fips_enabled                  # 1 means the kernel is in FIPS mode
fips-mode-setup --check                            # RHEL 8 and 9 only; removed in RHEL 10

If you see DEFAULT:SHA1 or LEGACY on a server that does not talk to an ancient peer, find out who set it and why. To change the policy (this changes the system, and on RHEL needs a reboot to take full effect):

sudo update-crypto-policies --set DEFAULT
sudo reboot

Step 5: read SELinux state properly

getenforce                                          # Enforcing, Permissive or Disabled
sestatus                                            # mode from config, current mode, loaded policy
grep -E '^SELINUX=' /etc/selinux/config
cat /proc/cmdline | tr ' ' '\n' | grep -E 'selinux|enforcing'
sudo ausearch -m AVC -ts recent | tail              # recent denials

On RHEL 9 and later, a config file that says disabled with no selinux=0 on the kernel command line means SELinux is enabled with no policy loaded. sestatus will show it. Fix the cause of denials rather than leaving the box in that state.

Step 6: a one screen audit script

#!/usr/bin/env bash
# rhel-family-audit.sh: read only snapshot of release, kernel, errata, crypto and SELinux
set -u
. /etc/os-release
echo "OS:        $PRETTY_NAME ($PLATFORM_ID)"
echo "Kernel:    $(uname -r) (installed: $(rpm -q kernel | tail -1))"
echo "Crypto:    $(update-crypto-policies --show 2>/dev/null)"
echo "FIPS:      $(cat /proc/sys/crypto/fips_enabled 2>/dev/null)"
echo "SELinux:   $(getenforce 2>/dev/null)"
echo "Sec errata pending:"
dnf -q updateinfo list --security 2>/dev/null | awk '{print $1, $2}' | sort -u | head -20
dnf -q needs-restarting -r >/dev/null 2>&1 || echo "Reboot:    required"

Run it across the estate from configuration management to see stream, crypto policy and SELinux state per host.

Major version upgrades with Leapp, and Fedora upgrades

RHEL in-place upgrades

Red Hat's supported path between major versions is the Leapp in-place upgrade. The RHEL 8 to 9 upgrade guide is clear on the limits: you cannot upgrade in place from RHEL 7 directly to RHEL 9. You upgrade to RHEL 8 first and then perform a second in-place upgrade. In the current guide, the supported source for an 8 to 9 upgrade is RHEL 8.10, with targets of RHEL 9.6 (EUS) or 9.8 for standard systems, and specific paths for SAP NetWeaver and SAP HANA. The guide notes that the published paths are guaranteed for systems using Red Hat Subscription Manager; for pay as you go cloud images on Red Hat Update Infrastructure, only the latest path is supported.

Before you run any of this, take a full backup or snapshot and confirm you can restore it. An in-place upgrade replaces the operating system.

# On a RHEL 8.10 system, fully updated and rebooted
sudo dnf install leapp-upgrade

# Assess only. Writes a report; does not change the OS.
sudo leapp preupgrade --target-version 9.8
less /var/log/leapp/leapp-report.txt
cat /var/log/leapp/answerfile          # answer any true/false questions it asks

# After every inhibitor is resolved and a snapshot exists:
sudo leapp upgrade --target-version 9.8   # changes the system
sudo reboot

Red Hat also says to disable client-server configuration management such as Puppet, Salt or Chef before leapp preupgrade until the upgrade finishes, and to read the whole report even when it shows no inhibitors. Remember too that the RHEL 9 SHA-1 restriction and the RHEL 10 CPU baseline and FIPS install rule can change how an upgraded host behaves.

For teams already running containers or image based hosts, rebuilding on the new major release is often safer than an in-place upgrade: you get a clean system that matches your build definitions instead of years of drift.

Fedora upgrades

Fedora upgrades are routine because they happen every six to 13 months. The standard path uses the DNF system upgrade plugin:

sudo dnf upgrade --refresh
sudo dnf system-upgrade download --releasever=44
sudo dnf system-upgrade reboot          # changes the system and reboots into the upgrade

Because Fedora supports only two releases at a time, a machine that misses two upgrade windows is out of support: fine for a laptop, poor for a server nobody touches.

Container base images: UBI and the RHEL patch clock

Red Hat's Universal Base Images are container images built from RHEL content. Their properties matter for supply chain work:

• Freely redistributable. UBI images and the UBI repositories (a subset of RHEL packages) need no subscription.
• Two registries. Authenticated registry.redhat.io and unauthenticated registry.access.redhat.com.
• Variants. Standard UBI images include a package manager; the UBI article notes yum is not available in the minimal and micro images.
• Same advisories. UBI packages are RHEL packages, so RHSA, CSAF and backporting rules apply directly.

Check what a running or built image really is:

podman run --rm registry.access.redhat.com/ubi9/ubi cat /etc/os-release
podman run --rm registry.access.redhat.com/ubi9/ubi rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort | head
podman run --rm registry.access.redhat.com/ubi9/ubi dnf -q updateinfo list --security
podman image inspect registry.access.redhat.com/ubi9/ubi --format '{{.Created}}'

The Created timestamp is the honest one. A base image is a snapshot. If your build pulled ubi9/ubi six months ago and nobody rebuilt since, your image carries six months of unapplied errata no matter what the host is running. Rebuild on a schedule, pin by digest so rebuilds are deliberate, and scan the result. The same thinking for Debian based images is in Debian 12 Bookworm base images after regular support ended.

Common mistakes

1. Comparing RHEL kernel versions to upstream. RHEL 9.8 reports 5.14, but that kernel contains years of backported fixes. Match on the full release string and the advisory, not on the upstream version.
2. Assuming "RHEL 9" means patched. Without an ELCP or Premium extension, a non current minor release stops getting fixes when the next minor ships. Check subscription-manager release --show and your entitlements.
3. Treating CentOS Stream as free RHEL. It is upstream of RHEL, and its support ends with RHEL Full Support.
4. Leaving CentOS Linux 7 or 8 running. Both are out of support with no updates.
5. Setting SELINUX=disabled on RHEL 9 and thinking it is off. It boots enabled with no policy loaded. Either fix the denials or use the documented kernel parameter.
6. Setting LEGACY or DEFAULT:SHA1 estate wide. Apply weaker policies only to the hosts that need them and record why.
7. Planning to enable FIPS after install on RHEL 10. fips-mode-setup is gone; FIPS mode is an install time decision.
8. Relying on OVAL alone. It is in maintenance mode; move to CSAF and VEX.
9. Forgetting that base images age. A UBI image built last year is last year's RHEL. Rebuild, then rescan.

Where Safeguard fits, honestly

Safeguard does not patch operating systems, manage hosts or replace Red Hat's errata. The RHEL kernel, glibc and OpenSSL on a server get fixed by Red Hat and applied by your patching process. Where Safeguard helps is the software you build on top of this family. The Safeguard CLI can scan a repository (safeguard scan --dir .), a container image (safeguard scan --image <name>) or an SBOM file (safeguard scan --sbom <file>), match the components it finds against vulnerability databases and write the results as JSON under ./output. The platform shows which projects contain a given component and version, so when an advisory lands for a library in your UBI based images you can see where it lives. Reachability analysis helps rank which application level findings to fix first, and policies and gates can stop a build that brings a known vulnerable dependency back.

FAQ

What is the difference between Fedora, CentOS Stream and RHEL?

Fedora is the fast moving community distribution where new code lands first. CentOS Stream is the public development branch for upcoming RHEL minor releases. RHEL is the supported product with a ten year life cycle.

Is CentOS Stream upstream or downstream of RHEL?

Upstream. Since December 2020 CentOS Stream tracks just ahead of RHEL, and RHEL minor releases are created from it. CentOS Linux used to be downstream, as a rebuild, and that model ended with CentOS Linux 8 at the end of 2021 and CentOS Linux 7 on 30 June 2024.

How long is RHEL supported?

RHEL 8, 9 and 10 have ten years across Full Support and Maintenance Support, then an Extended Life Phase without fixes. RHEL 10 Full Support ends on 31 May 2030 and Maintenance on 31 May 2035, with a paid extension to 31 May 2039. Individual minor releases can get six or nine years through Extended Life Cycle Premium.

When does Fedora 43 reach end of life?

Fedora 43 stays supported until four weeks after Fedora 45 ships. With Fedora 45 targeted for 3 November 2026, the schedules put Fedora 43's end of life in early to mid December 2026. A slip of Fedora 45 moves it.

Is RHEL 7 still supported?

Only through the paid Extended Life-cycle Support add-on, which began on 30 June 2024 when Maintenance Support ended. ELS covers x86 64-bit and IBM Z, delivers fixes per the standard criteria for the last minor release, 7.9, and is only available on Standard or Premium RHEL Server subscriptions.

Does RHEL 10 support post-quantum cryptography?

Yes. RHEL 10.0 shipped post-quantum algorithms as a Technology Preview through a TEST-PQ subpolicy. RHEL 10.1 enabled hybrid ML-KEM and ML-DSA in all predefined crypto policies by default, including FIPS, with OpenSSL 3.5 supporting ML-KEM, ML-DSA and SLH-DSA.

How do I check if a CVE is fixed on my RHEL server?

Use dnf updateinfo with its security filter to see pending advisories, check the per-CVE VEX file on security.access.redhat.com for your product's status, and search the package changelog from rpm for the CVE number. Do not compare the upstream version, because Red Hat backports fixes into older versions.

Can I upgrade from CentOS 7 to RHEL 9 or CentOS Stream 9 in place?

Not in one step. Red Hat does not support an in-place jump from RHEL 7 to 9; the path is 7 to 8, then 8.10 to 9. For CentOS Linux 7, rebuilding on RHEL 9 or 10 is usually the cleaner route.

A RHEL, CentOS Stream or Fedora host gets its operating system fixes from the distribution, but the applications you deploy on it, and the containers you build on UBI or Fedora images, also pull in language packages and libraries that no distribution errata will ever touch. That application layer is where the steps below apply; the host packages themselves still follow Red Hat's or Fedora's advisories.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a Node or Python service you deploy on a RHEL 9 host or a UBI image: the OS packages come from Red Hat's errata, while the application dependency fix goes through a reviewed change like this one.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That is the shape you want on a Fedora workstation or a RHEL build host, where scans of your repositories and the images you build run locally before anything ships.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. If your team already uses Claude to triage findings, this keeps the security data in the same conversation as the advisory you are reading, with the tool permissions you set.

Click through it at your own pace, or open it full screen.

You can download Safeguard or read the CLI documentation to try it on your own repositories.

Quick check

Sources

• Red Hat: Red Hat Enterprise Linux Life Cycle
• Red Hat: Red Hat Enterprise Linux Release Dates
• Red Hat: Retired life cycle dates for RHEL
• Red Hat: Legacy extended support offerings (EUS, E4S, ELS)
• Red Hat: Product life cycle data API for RHEL
• Red Hat: RHEL 10.0 release notes
• Red Hat: RHEL 10.1 release notes
• Red Hat: Considerations in adopting RHEL 10
• Red Hat: RHEL 9.0 release notes
• Red Hat: RHEL 8.0 release notes
• Red Hat: RHEL 9 security hardening (system wide crypto policies, FIPS)
• Red Hat: Upgrading from RHEL 8 to RHEL 9
• Red Hat: Security Data (CSAF, VEX, OSV, SBOM, OVAL)
• Red Hat: CSAF advisories directory
• Red Hat: Universal Base Images, repositories, packages and source code
• Red Hat blog: Furthering the evolution of CentOS Stream (21 June 2023)
• Fedora Docs: Fedora Linux release life cycle
• Fedora Docs: Fedora Linux releases
• Fedora Docs: End of life releases
• Fedora Docs: Fedora ELN
• Fedora: Fedora Linux 43 key tasks schedule
• Fedora: Fedora Linux 44 key tasks schedule
• Fedora: Fedora Linux 45 key tasks schedule
• Fedora Wiki: System-wide crypto policy change (Fedora 21)
• Fedora Docs: Packaging guidelines for crypto policies
• fedoraproject.org: editions, atomic desktops, spins and labs
• CentOS Project: CentOS Stream
• CentOS Project: CentOS Stream 9 timeline
• CentOS Project: Download page with Stream end dates
• CentOS Project: CentOS Linux EOL
• CentOS blog: CentOS Project shifts focus to CentOS Stream (8 December 2020)
• CentOS blog: End dates are coming for CentOS Stream 8 and CentOS Linux 7 (11 April 2023)
• CentOS blog: Introducing CentOS Stream 10 (12 December 2024)
• AlmaLinux: AlmaLinux OS stable release is live (30 March 2021)
• AlmaLinux: The future of AlmaLinux is bright (13 July 2023)
• Rocky Linux: Rocky Linux 8.4 GA (21 June 2021)
• Rocky Linux: Keeping open source open (29 June 2023)

Last reviewed: 23 October 2026. Red Hat says future life cycle dates are approximate and subject to change, and Fedora dates move when a release slips; check the linked life cycle pages before planning an upgrade.