Ubuntu Release Lifecycle Explained: LTS, Interim, ESM, Legacy and HWE

Ubuntu ships a new release every six months and a Long Term Support (LTS) release every two years. Interim releases get 9 months of updates. An LTS gets 5 years of standard security maintenance for the Main repository, 10 years for Main and Universe with Expanded Security Maintenance (ESM) through Ubuntu Pro, and 15 years with the paid Legacy add-on. Hardware Enablement (HWE) kernels, flavours and Ubuntu Core each follow their own rules on top of that.

Below: each layer of that model, the upgrade rules, and a planning table for 20.04, 22.04, 24.04 and 26.04 out to 2041. Every date comes from ubuntu.com or documentation.ubuntu.com pages fetched on 23 October 2026. Where two official pages disagree, we show both and say which we used.

Key takeaways

• Two cadences. A new Ubuntu release every six months, versioned by year and month (26.10 shipped in October 2026). Every two years, the April release is an LTS.
• Interim releases get 9 months. Ubuntu 26.10 "Stonking Stingray" was released on 15 October 2026 and is supported until July 2027. Ubuntu Pro is not available for interim releases.
• LTS standard support is 5 years, for Main only. Canonical patches CVEs in the Main repository for five years at no cost. Universe is outside that free commitment.
• Ubuntu Pro ESM takes an LTS to 10 years and adds Universe. The esm-infra stream covers Main after year five; esm-apps covers Universe for ten years from release. Pro is free for personal use on up to five machines.
• The Legacy add-on takes an LTS to 15 years. It is bought on top of Pro. 26.04 LTS is listed to May 2041.
• HWE kernels roll forward on an LTS. Each point release from .2 to .5 can bring a newer kernel from the latest interim release. Only the GA kernel and the final HWE kernel (from the .5 point release) carry the full LTS life; intermediate HWE kernels end when their interim release does.
• Flavours and Ubuntu Core have their own windows. Xubuntu 26.04 and Ubuntu Budgie 26.04 state three years. Ubuntu Core states 10 years plus 5 with Legacy.
• Upgrades are sequential. LTS to the next LTS, interim to the next interim, no skipping. LTS to LTS upgrades are offered only after the first point release, for example 26.04.1 on 27 August 2026.

How often does Ubuntu release, and how are versions numbered?

Canonical's release cycle page is the reference for the whole model. It says Ubuntu "releases a new version every six months," that each release gets a development codename, and that releases are "versioned by the year and month of delivery." So 26.04 means April 2026 and 26.10 means October 2026. The codename comes in two words with the same first letter: 26.04 is "Resolute Raccoon," 26.10 is "Stonking Stingray," and the release notes index lists 27.04 "Tenacious T-Rex" as the release currently in development.

LTS releases "are released every two years," always in April of an even year. Between two LTS releases sit three interim releases: the October after an LTS, the following April and the following October. 24.04 LTS was followed by 24.10, 25.04 and 25.10, then 26.04 LTS. The current cycle runs 26.04 LTS, 26.10, 27.04, 27.10, then 28.04 LTS, which already appears under "Future releases" on the release notes index.

The release notes index also records a release day rule: a critical priority CVE announced on release day blocks the Server, Desktop and Cloud images until new ones are built, while a high priority CVE is decided per product.

For the full list of every version, codename and date since 4.10, see our companion post, Ubuntu release history: every version, codename, kernel and support date.

What is the difference between an interim release and an LTS?

Interim releases: 9 months, no Pro

The release cycle page describes interim releases as built for "users and teams who move fast and need access to the latest kernels, languages, and toolchains," with "only 9 months of updates." The 26.10 release notes put the current one in concrete terms: released on 15 October 2026, "supported for 9 months, until July 2027."

Nine months against a six month cadence leaves a three month overlap in which to upgrade.

Ubuntu Pro does not extend an interim release. The Ubuntu Pro Client documentation on interpreting pro security-status shows the output on an interim machine ending with "Ubuntu Pro is not available for non-LTS releases," and says Main and Restricted packages on an interim release "are supported for 9 months from the release date." On the release cycle page, the 26.10 row shows "Not applicable" for ESM, break and bug support and the Legacy add-on. When an interim release reaches its end date, the only supported path is to upgrade.

LTS releases: 5 years standard

The release cycle page says LTS releases "receive 5 years of standard security maintenance" and are "security maintained for 5 years with CVE patches for packages in the Main repository." The page recommends them "for production environments, enterprises, and long-term projects."

The ESM page frames the standard term as a commitment Canonical makes "with no subscription required," and adds that Canonical's security team "actively backports these crucial fixes to all supported Ubuntu LTS releases." Backporting is the key idea: you keep the same package version across the life of the release, and the fix is applied to that version. A version string on an Ubuntu LTS therefore does not tell you on its own whether a CVE is fixed. Our post on whether Ubuntu patches universe packages works through what that means for scanners and version checks.

Which should you run?

Our post on whether to adopt a new LTS right away covers the timing question for teams moving between LTS releases.

What do Main, Restricted, Universe and Multiverse mean for security support?

The four components

The release cycle page groups Ubuntu packages into four categories: "'Main' and 'Restricted' (the base system), and 'Universe' and 'Multiverse' (community and extra packages)." Main and Universe are open source. Restricted and Multiverse "contain some non-open source software."

The ESM page explains why the split exists. Main "is the set of packages that we identified as our focus when we launched Ubuntu," packages "either installed on every machine, or very widely used." There "were initially about 1,000 packages in 'Main', and today that number has grown to about 2,300 per Ubuntu release." Universe "holds all of the other open source packages in Ubuntu, from Debian and the Ubuntu community," including toolchains and libraries for Java, PHP, Go and Python.

What "security maintained" covers in each

The Restricted and Multiverse rows come from how the Pro Client reports coverage: pro security-status counts "packages from Ubuntu Main/Restricted repository" and "packages from Ubuntu Universe/Multiverse repository," and its sample output says Main/Restricted packages receive updates with esm-infra and Universe/Multiverse packages with esm-apps. The release cycle and ESM pages themselves only describe Main and Universe, so treat the Restricted and Multiverse grouping as the Pro Client's reporting view rather than a separate written commitment.

The Pro Client's About ESM page is frank about Universe's history: "Historically those packages came with no security maintenance commitment from Canonical. Nevertheless, Canonical and the Ubuntu community provided best-effort maintenance." With Ubuntu Pro, "all of the packages of Ubuntu 'universe' get the same security maintenance commitment from Canonical as packages in Ubuntu 'main'."

Two official pages give different sizes for Universe. The ESM page says "over 36,000 packages per release (as of Ubuntu 24.04 LTS)." The Pro Client's About ESM page says "over 23,000 packages per release." Neither number changes the rule; we quote both because they disagree.

Why this matters for a scan

A typical server or container image mixes Main and Universe packages, so part of it sits outside Canonical's free commitment from day one of an LTS, not just after year five. Our post on Ubuntu CVE statuses in a container scan covers how that shows up in practice.

How do ESM and Ubuntu Pro extend an LTS?

From Extended to Expanded Security Maintenance

Per the Pro Client documentation, ESM "used to be known as Extended Security Maintenance," five extra years for Main only, an offering that "has since become known as esm-infra." When Pro "went into General Availability in early 2023," it became Expanded Security Maintenance and added Universe. On 14.04 the Trusty Legacy how-to still calls Pro "Ubuntu Advantage" (ua).

esm-infra and esm-apps

The ESM page defines the two streams:

• esm-apps "covers all 'Universe' packages for ten years from the release of the LTS."
• esm-infra "covers 'Main' packages for the period after the standard five year security maintenance of 'Main' packages ends."

There is also a "lower-cost Ubuntu Pro (infra-only) subscription if you only want the infra components, which equates to our original ESM offering."

ESM is scoped by severity. The Ubuntu Pro page says it fixes "critical, high and selected medium vulnerabilities across the whole Ubuntu archive, as defined by Ubuntu Priority," which can differ from CVSS; see Ubuntu priority levels versus CVSS.

How ESM updates reach a machine

Per the Ubuntu security documentation page on Expanded Security Maintenance, ESM updates arrive through APT like any other package, from "special-purpose Archive pockets" at esm.ubuntu.com: "The Infra pockets cover packages in the Main component, while the Apps pockets cover packages in the Universe component." The Pro Client writes those APT sources itself, ESM fixes are announced in the normal Ubuntu Security Notices and marked as Pro only, and the client pins ESM packages to priority 510, slightly above the default 500. The Pro Client docs say that pin guarantees "that no automatically installed updates will ever revert a previously applied security patch."

What else Ubuntu Pro includes

The release cycle page lists Pro as "up to 15 years of security coverage (ESM and Legacy add-on), Kernel Livepatch," centralised estate management, "FIPS 140-3 certified packages, and CIS hardening, and optional enterprise-grade support." On price, the release cycle page and Desktop docs say Pro is free for personal use "on up to five machines," while the Pro page says "up to 5 physical machines, or 50 machines for official Ubuntu Community members." We use the Pro page's more specific wording. The ESM page lists Kernel Livepatch under ESM on amd64 for 14.04 to 20.04, and on amd64 and s390x for 22.04 and 24.04; our post on kernel Livepatch covers what still needs a reboot.

What is the Legacy add-on?

The release cycle page says: "At the end of the 10 year ESM period, the Legacy add-on can be purchased to cover additional 5 years of the lifetime of Ubuntu LTS, giving a total of 15 years security maintenance and support for LTS releases." The Pro page puts it the same way: with the Legacy add-on, the 10 year commitment "is extended an additional 5 years, giving you a 15 year security maintenance and support commitment."

So the full LTS life has three phases, which the release cycle page lays out as years 1 to 5, 6 to 10 and 11 to 15:

On 14.04 the Legacy add-on is a separate Pro Client service, esm-infra-legacy. The Trusty how-to describes it as granting "an additional two years of extended security coverage," which disagrees with the release cycle page's 14.04 Legacy end of May 2029, five years after ESM ended. The how-to dates from the 2024 offer; we use the release cycle page.

One more nuance on the release cycle page: for 16.04 and 14.04, the ESM and break and bug support columns read "With legacy add-on." Both releases are past their tenth year, and the only coverage still running for them is Legacy, to May 2031 for 16.04 and May 2029 for 14.04.

LTS support dates: the full table

These are the dates on the release cycle page as fetched on 23 October 2026. The ESM page shows the same standard, Pro and Legacy end dates in its own schedule table, with codenames.

Break and bug support dates on the page match the ESM end dates for every LTS. The release cycle page starts its LTS rows at 14.04, so this table does too.

Where official pages disagree on 26.04. The 26.04 release notes say 26.04 LTS "will be supported until April 2031," and that "With an Ubuntu Pro subscription, access to ESM (Expanded Security Maintenance) updates will be available for ten years." The release cycle page and the kernel lifecycle page say May 2031. The kernel documentation's HWE kernels reference gives the 26.04 GA kernel an EOL of April 2031 and ESM of March 2036. We use the release cycle page's month throughout, because it is the page Canonical links from the release notes for support details. If your contract or audit depends on the exact month, plan to the earlier date.

The ESM page's separate "What is covered?" table ends Main and Universe coverage on the Legacy dates (May 2029 for 14.04 through May 2039 for 24.04), so it appears to include Legacy; it lists 14.04 Universe as "n/a."

Our existing posts go deeper on the two releases most teams are planning around now: is Ubuntu 20.04 end of life and is Ubuntu 22.04 end of life. For container base images on 22.04 specifically, see Ubuntu 22.04 container base images and the support window through May 2027.

What are HWE kernels and point releases?

Point releases .1 to .5

An LTS is not frozen on day one. Canonical ships point releases on a published schedule. The 26.04 release schedule lists the final release on Thursday 23 April 2026, then:

A point release refreshes the installation media. The 26.04.1 notes say it "includes all security updates from the Ubuntu Security Notice affecting Ubuntu 26.04.1 LTS that were released up to and including August 25, 2026"; the 24.04.5 notes do the same up to 10 September 2026. Installed machines get the same packages through normal updates. The first point release also unlocks LTS to LTS upgrades, covered below.

HWE: newer kernels on an LTS

The kernel lifecycle and enablement stack page defines the HWE stack as providing "newer kernel and X11 display support for existing Ubuntu LTS releases." It "can be enabled manually, but may also be pre-enabled with an Ubuntu LTS release," and can be used on desktop, server, cloud and virtual images.

The kernel documentation's HWE reference states the rule that drives the whole model: HWE kernels "are only enabled on Ubuntu long-term support (LTS) releases, and have similar life cycles as their newer Ubuntu kernel counterparts. They will typically get rolled off to the next HWE kernel once a new Ubuntu series is released (until the next LTS)." The lifecycle page calls this the Rolling Update Model for every LTS from 16.04 on.

In practice that means each new interim kernel is offered to the LTS at the next point release, and the HWE kernel from an interim release lives as long as that interim release does. Only the final HWE kernel, the one that arrives with the .5 point release from the next LTS's kernel, carries the rest of the LTS life.

Default kernel by edition

The lifecycle page is explicit about defaults, and they differ between desktop and server:

• 20.04, 22.04 and 24.04 Desktop "default to tracking the HWE stack."
• Server installations "will default to the GA kernel and provide the enablement kernel as optional."
• 16.04 and 18.04 Desktop got the HWE kernel and X stack by default from the .2 point release onward.

Some desktops follow a third track. The lifecycle page says "certain desktop machines may be on a separate 'OEM' track," and that if ubuntu-drivers list-oem returns anything, "the machine is running the OEM cadence instead of HWE."

Edge HWE variants such as linux-generic-hwe-24.04-edge "are not supported" and "should not be used in a production environment," per the HWE reference.

The kernel schedule, by LTS

The kernel lifecycle page gives a kernel release schedule with its own support end dates. Here are the rows for the four LTS releases in the planning window:

The 6.17 rows show the Rolling Update Model in one line: the 24.04.4 HWE kernel ended in July 2026, the same month as 25.10, the interim release it came from. A 24.04 desktop that stayed on 6.17 after July 2026 was on an unsupported kernel until it moved to 7.0. The release cycle page's kernel list matches the GA kernels: 3.13 for 14.04, 4.4 for 16.04, 4.15 for 18.04, 5.4 for 20.04, 5.15 for 22.04, 6.8 for 24.04, 7.0 for 26.04 and 7.3 for 26.10.

Where official pages disagree on kernel dates. The HWE reference gives the 24.04.5 HWE 7.0 kernel an August 2026 release and the 24.04.4 HWE 6.17 kernel a February 2026 release, against July and January on the lifecycle page, and uses April and March end dates where the lifecycle page uses May. We used the lifecycle page.

How kernel updates reach you

The kernel documentation on the stable release update (SRU) cycle says each kernel goes through -proposed for testing and signoff before it is "promoted to -updates," and also to -security when the security team's signoff requires it. The running kernel only changes after a reboot or a live patch.

Do flavours and Ubuntu Core follow the same lifecycle?

Flavours

Not necessarily. The release cycle page says "The release cycle for flavours may differ" and points to each flavour's own site. The Desktop upgrade guide says "flavors aren't supported by Canonical," while the flavours page says they are "backed by the full Ubuntu archive for packages and updates."

The 26.04 flavour release notes we fetched state their own windows:

Other flavour announcements linked from the 26.04 release notes either refused our request or returned 404 at the time of writing, so we do not list their periods here. Check each flavour's own announcement, linked from the 26.04 release notes, for the current statement.

What these pages do not spell out is how a flavour's three year window interacts with the five year standard maintenance of the Main packages it shares with Ubuntu. Rather than guess, run pro security-status on the flavour machine (shown in the walkthrough below). It reports, per package bucket, the year until which that machine receives security patching.

Ubuntu Core

Ubuntu Core is the all-snap edition for appliances and IoT. Its support duration page says it "follows our Long Term Support (LTS) model. Each release includes 10 years of security maintenance," with a Legacy add-on for "an additional 5 years," for 15 in total. The covered components are SnapD, the kernel snap and the base.

The page's own table does not match its "10 years" sentence for two releases: Core 18 is listed from January 2019 to January 2028 (nine years) and Core 20 from February 2021 to February 2030 (nine years). We report the table as published. Note also that Ubuntu Core's 10 years is labelled "standard security maintenance," unlike classic Ubuntu, where years 6 to 10 need Pro.

How do upgrade paths work, and when does do-release-upgrade offer them?

Sequential only

The Ubuntu Server guide, How to upgrade your Ubuntu release, says: "You can only upgrade from one LTS release directly to the next sequential LTS release." You "cannot skip releases (e.g. jump from 16.04 LTS to 20.04 LTS)," and have to go in stages. The Desktop guide says the same for both tracks: Ubuntu "only supports sequential upgrades: from one Long Term Support (LTS) release to the next, or from one interim release to the next."

So a 20.04 machine reaches 26.04 in three hops: 22.04, 24.04, 26.04. The release cycle page's "Upgrade path" column agrees for LTS rows: 20.04 to 22.04 LTS, 22.04 to 24.04 LTS. For 24.04 it lists "24.10, 26.04 LTS" and for 26.04 it lists "26.10," which reflects the interim option too. 24.10 has already reached its end, so for 24.04 the only supported target today is 26.04.

When the upgrade is offered

The Server guide says LTS to LTS upgrades "are only available after the first point release," 26.04.1 on 27 August 2026 in this cycle; forcing earlier with -d "is not recommended for production environments." Interim upgrades "become available a few days after the official release date," per the Desktop guide.

One current exception: the 26.10 release notes say systems running TPM-backed full disk encryption "will not be able to upgrade from Ubuntu 26.04 LTS to Ubuntu 26.10 on release," with that path expected to open during the 26.10 lifecycle.

LTS prompt or every release

Which upgrades do-release-upgrade offers depends on /etc/update-manager/release-upgrades. The Desktop guide on switching between an LTS and interim release says to set Prompt=normal to follow interim releases, or Prompt=lts to only be offered LTS releases. You can switch an interim machine to LTS only "When you're using an interim release that directly precedes an LTS release" or right after upgrading to an LTS. The 26.04.1 notes list a change that sets "Prompt=lts for resolute," so a 26.04 install stays on the LTS track unless you change it.

What the upgrader does to third party sources

The Server guide warns that PPAs and third party repositories "are disabled during the release upgrade," and that phased packages "may also block the release upgrade" (see Ubuntu phased updates).

Planning table: 20.04, 22.04, 24.04 and 26.04 from 2026 to 2041

Status at the start of each year, using the release cycle page's month for each transition (all transitions fall in May). "Standard" means free security maintenance for Main; "ESM" means Ubuntu Pro; "Legacy" means the Legacy add-on; "Ended" means no security coverage of any kind.

The dates to diary: May 2027, when 22.04 leaves free standard maintenance; May 2029, when 24.04 does; and May 2030, when 20.04 leaves ESM for Legacy only. Container images inherit their base's window; see how to check whether your base image OS is end of life and base image support dates side by side.

How to check a machine's release, kernel and support status

Every command below comes from the Ubuntu documentation page cited next to it.

Step 1: Identify the release

From the Desktop guide on switching between LTS and interim releases:

lsb_release --description
# Description: Ubuntu 26.04 LTS

"LTS" in the description tells you which track you are on. Compare the version with the table above.

Step 2: Check the kernel's support status

From the kernel lifecycle page:

hwe-support-status --verbose

This reports whether the installed kernel and enablement stack are still supported, which is the check that catches a desktop left on an intermediate HWE kernel. If you are on a desktop, also check whether the machine is on the OEM track:

ubuntu-drivers list-oem

A non-empty result means the machine follows the OEM kernel cadence instead of HWE.

Step 3: Check security coverage per package bucket

From the Pro Client page on interpreting security-status:

pro security-status

It reports the year until which each bucket is patched, or "This machine is NOT receiving security patches because the LTS period has ended and esm-infra is not enabled." The counts at the top also show packages from third parties and those "no longer available for download," which no Ubuntu window covers.

Step 4: See which Pro services are enabled

From the Pro Client basic commands tutorial and the guide to managing ESM services:

sudo apt update && sudo apt install ubuntu-pro-client
pro status

Step 5: Attach and enable ESM if you need it

From the same Pro Client pages:

sudo pro attach
sudo pro enable esm-infra
sudo pro enable esm-apps
sudo apt upgrade

Both streams are enabled automatically on attach for LTS releases, so enable is only needed if you turned them off. On 14.04, the Trusty how-to uses sudo ua status and sudo ua enable esm-infra-legacy instead.

Step 6: Prepare and run a release upgrade

From the Server guide, How to upgrade your Ubuntu release:

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

Reboot if the file /run/reboot-required exists, confirm free disk space and backups, then:

sudo do-release-upgrade

The upgrader summarises the changes, asks about modified configuration files and ends with a reboot; "The system is not considered upgraded until this reboot occurs." If nothing is offered, check the Prompt setting and whether the target LTS has reached its first point release.

Common mistakes

• Treating "LTS" as "everything patched for five years." Standard maintenance covers Main. Universe packages, often your language runtimes and libraries, need esm-apps from day one if you want a Canonical commitment.
• Staying on an interim release past its 9 months. There is no Pro option for interim releases. A 25.10 machine stopped receiving updates in July 2026.
• Leaving a desktop on an intermediate HWE kernel. On 24.04, the 6.17 HWE kernel ended in July 2026. Run hwe-support-status --verbose and let the HWE metapackage move you to 7.0.
• Trying to jump two LTS releases at once. 20.04 to 24.04 is two upgrades. The Server guide says you cannot skip.
• Expecting the 26.04 upgrade on release day. LTS to LTS upgrades open at the .1 point release. Forcing it with -d is for evaluation, not production.
• Assuming a flavour gets Ubuntu's five years. Xubuntu 26.04 and Ubuntu Budgie 26.04 state three years. Check the flavour's own announcement.
• Forgetting containers. An image built from an old Ubuntu base inherits its end date, and most images never run the Pro Client. Track base images separately from hosts.
• Reading version numbers as fix status. Ubuntu backports fixes into the same version. Use the USN or the CVE tracker, not upstream version ranges. See how to check a distro backported security fix.

FAQ

How long is an Ubuntu LTS supported?

Five years standard for Main, 10 with Ubuntu Pro ESM for Main and Universe, 15 with the Legacy add-on: May 2031, May 2036 and May 2041 for 26.04 (the release notes say April 2031).

How long are Ubuntu interim releases supported?

Nine months. Ubuntu 26.10, released on 15 October 2026, is supported until July 2027. Ubuntu Pro is not available for interim releases.

Is Ubuntu 20.04 still supported?

Only through Ubuntu Pro. Standard security maintenance ended in May 2025. ESM runs to May 2030 and the Legacy add-on to May 2035. See our post on whether Ubuntu 20.04 is end of life.

When does Ubuntu 22.04 reach end of standard support?

May 2027, per the release cycle page. ESM continues to May 2032 and Legacy to May 2037. See is Ubuntu 22.04 end of life.

What is the difference between ESM and the Legacy add-on?

ESM is part of Ubuntu Pro and runs to year 10. The Legacy add-on is bought separately and adds years 11 to 15.

What is an HWE kernel in Ubuntu?

A newer kernel, taken from a later interim release, offered on an LTS through the point releases. Desktops on 20.04, 22.04 and 24.04 track HWE by default; servers default to the original GA kernel. Intermediate HWE kernels end when their interim release does; the last one, from the .5 point release, lasts for the rest of the LTS.

What kernel does Ubuntu 24.04 use?

The GA kernel is 6.8. The HWE kernels were 6.17 with 24.04.4 (supported until July 2026) and 7.0 with 24.04.5, which the kernel lifecycle page lists to May 2029 standard, May 2034 ESM and May 2039 Legacy.

Can I upgrade directly from Ubuntu 20.04 to 24.04?

No. The Server guide says you cannot skip LTS releases. Upgrade 20.04 to 22.04, then 22.04 to 24.04.

Why does do-release-upgrade say no new release is found?

Usually the next LTS has not reached its first point release yet, or Prompt=lts is set while you expect an interim release.

Fix it without waiting for upstream

Ubuntu's lifecycle decides how long Canonical patches the operating system packages on a release. It does not decide how fast the libraries your application bundles on top of that release get fixed, and on an end of life release, or a Universe package with no Pro attached, the operating system side stops receiving USNs altogether. The steps below are about closing that application side gap.

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

None of these demos extends an Ubuntu release or patches a host kernel; ESM, Livepatch and the Legacy add-on stay with Canonical. What they show is how to see which Ubuntu bases and packages your projects actually carry, so the dates in the planning table turn into a list of things to move, and how to get application dependencies to fixed versions with a person approving each step.

This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. Scanning a container image built on an Ubuntu base, for example with safeguard scan --image, produces an SBOM that shows which OS packages and versions the image contains, which is how you find the images still on 20.04 or 22.04 before their next transition date.

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

In this Safeguard CLI session you install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. 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 covers the application layer of a service running on any Ubuntu LTS: Canonical patches the OS packages for as long as the release is covered, and this is how the dependencies you ship on top get to fixed versions.

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

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects contain a given component and version, which is a quick way to list every project still built on a base that leaves standard maintenance in May 2027. Our post on using SBOMs to find affected products fast works through the same question.

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

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli. Related reading: Ubuntu vs Kali vs Debian, Ubuntu 26.04 LTS Resolute Raccoon and upgrade, extend, isolate or retire end of life software.

Quick check

Sources

• Ubuntu: Release cycle
• Ubuntu: Kernel lifecycle and enablement stack
• Ubuntu: Ubuntu Pro
• Ubuntu: Expanded Security Maintenance
• Ubuntu: Flavours
• Ubuntu release notes (index and release policy)
• Ubuntu release notes: Ubuntu 26.04 LTS
• Ubuntu release notes: Resolute Raccoon release schedule
• Ubuntu release notes: Changes in 26.04.1
• Ubuntu release notes: Changes in 24.04.5
• Ubuntu release notes: Ubuntu 26.10
• Ubuntu security documentation: Expanded Security Maintenance (ESM)
• Ubuntu kernel documentation: HWE kernels
• Ubuntu kernel documentation: About kernel stable release updates (SRU)
• Ubuntu kernel documentation: Ubuntu kernel variants and branches
• Ubuntu Pro Client: Get started with Ubuntu Pro Client
• Ubuntu Pro Client: About ESM, esm-apps and esm-infra
• Ubuntu Pro Client: How to manage ESM services
• Ubuntu Pro Client: How to enable esm-infra-legacy on Trusty
• Ubuntu Pro Client: What does security-status do?
• Ubuntu Pro documentation
• Ubuntu Server documentation: How to upgrade your Ubuntu release
• Ubuntu Desktop documentation: Upgrade Ubuntu Desktop
• Ubuntu Desktop documentation: Switch between an LTS and interim release
• Ubuntu Core documentation: Support duration
• Xubuntu 26.04 release notes
• Ubuntu Budgie 26.04 LTS release notes
• Kubuntu 26.04 LTS release announcement

Last reviewed: 23 October 2026.