openSUSE and SUSE Linux Enterprise Release History and Support Dates

The SUSE family has three branches. SUSE Linux Enterprise Server (SLES) is the paid enterprise product: SLES 16.0 shipped on 4 November 2025, with SLES 16 supported to 2038. openSUSE Leap is the free release built from the same SLE sources and binaries, with 24 months per point release. Tumbleweed is the openQA tested rolling release.

As of this writing (24 October 2026), the supported enterprise releases are SLES 16.0 (general support to 30 November 2027) and SLES 15 SP7 (general support to 31 July 2031), with older service packs of SLES 15 and SLES 12 SP5 covered only under paid Long Term Service Pack Support. On the community side, Leap 15.6 reached end of life on 30 April 2026, Leap 16.0 is the current Leap release, and Leap 16.1 is in its release candidate phase with general availability planned for November 2026, on the same day as SLES 16.1.

Key takeaways

• SUSE dates back to 1992 and openSUSE to 2005. SUSE's own history page gives 1992 as its founding year. openSUSE was announced by Novell on 9 August 2005, and the first release under the openSUSE name was 10.2.
• SLES majors are long lived. SLES 15 runs to 31 July 2031 in general support and 31 July 2034 under LTSS for its last service pack. SLES 16 runs to 30 November 2035 in general support and 30 November 2038 under long term support, with an LTS Core phase listed to 30 November 2041.
• SLES 16 changed the model. Instead of service packs it uses numbered minor releases (16.0, 16.1 and so on), one each November, each with 24 months of general support.
• Leap tracks SLE directly. Leap 15 and Leap 16 share source and binaries with the matching SLE release. Leap 16 gives each point release 24 months of community support, with 16.6 planned for autumn 2031.
• Tumbleweed is rolling but gated. Changes flow through Factory, staging projects and openQA before a snapshot is published. You update with zypper dup and can roll back with snapper.
• Slowroll exists, but read it as experimental. openSUSE described it in January 2024 as an experimental, slower rolling variant of Tumbleweed; openQA still runs a Slowroll job group today.
• Patch by advisory, not by version string. SUSE publishes advisories, per CVE pages, OVAL and CSAF (including VEX) data. On the machine, zypper list-patches and zypper patch work in units of patches tied to CVEs and bug numbers.
• Btrfs and snapper are your undo button. Default installs take snapshots before and after zypper transactions, and snapper rollback makes an older snapshot the boot default.

If you run more than one Linux family, the sibling posts cover the others in the same format: the Fedora, CentOS Stream and RHEL pipeline, the Debian release history, the Ubuntu release history and the Alpine Linux release history. How distributions sign what they ship is covered in depth in Linux distribution package signing.

Where SUSE started and how openSUSE emerged

SUSE, 1992

SUSE's company history page says it was founded in 1992 and describes itself as the first provider of an enterprise Linux distribution. That is the vendor's own framing, but the founding year matters for one practical reason: SUSE has been shipping a Linux distribution with a commercial support promise for longer than almost anyone else, and many of the conventions you still see in SLES today (YaST until SLES 16, RPM packaging, the service pack model) come from that long history.

The ownership story is long too. According to the openSUSE Project's own anniversary post, SUSE joined Novell in 2003. Novell was later acquired by The Attachmate Group, SUSE was integrated into Micro Focus in 2014, the investment firm EQT bought SUSE in 2018, and SUSE listed on the Frankfurt Stock Exchange in 2021. For an operator, ownership changes matter mainly when they change support terms. The lifecycle page, not the press release, is the document you plan against.

openSUSE, 2005

openSUSE was announced on 9 August 2005 at the LinuxWorld Conference and Expo in San Francisco, according to the openSUSE News anniversary post. Novell launched it as the community side of SUSE Linux, in the same spirit as Red Hat's Fedora. The project's journey started with beta versions of SUSE Linux 10.0 under the openSUSE.org banner. The first official release under the openSUSE name was openSUSE 10.2.

For many years openSUSE shipped numbered releases on its own schedule. The project later split into two distinct products: Leap, a fixed release that tracks SUSE Linux Enterprise, and Tumbleweed, a rolling release. The openSUSE release tooling still carries traces of the earlier Leap 42 series in its documentation (for example a staging example that targets an openSUSE:Leap:42.3 project), but the line you will meet in production today starts with Leap 15.0, released on 25 May 2018 as a community build on top of SUSE Linux Enterprise 15.

How the pieces relate today

Think of the family as one source tree with three release cadences:

1. Factory is the development project in the Open Build Service where packages are submitted. Tumbleweed is published from Factory after testing.
2. SUSE Linux Enterprise takes a slower, curated selection of that work, adds certification and long support, and releases it as SLES and its siblings (SLES for SAP applications, SLE Micro, SLE High Performance Computing and others).
3. Leap rebuilds on top of the SLE release, sharing its core binaries, and adds community packages from Package Hub and Backports.

That is why Leap is often described as the free way to run "SLES without the subscription". The description is close but not exact: Leap has a shorter support window, no certifications, no paid LTSS, and some packages that SUSE does not ship. The openSUSE Release Team describes Leap 16 as bringing "source and binary identicality" with SLES 16 and says users can migrate from Leap 16 to SLES 16.

SUSE Linux Enterprise Server releases from 10 to 16

SUSE's product lifecycle page lists every SLES release still covered by its current life cycle documentation, starting with SLES 10. Earlier enterprise releases exist but are outside that table, so they are left out here rather than dated from secondary sources.

Two terms matter before you read the dates:

• FCS (first customer shipment) is SUSE's term for the release date.
• General support is the standard subscription. LTSS (Long Term Service Pack Support) is a paid add on that extends security and critical fixes for a specific service pack after its general support ends. The lifecycle page also lists an LTSS Core end date for some releases, a further phase beyond LTSS. For SLES 16, SUSE renamed the columns to LTS and LTS Core.

SLES major releases at a glance

All dates are from SUSE's lifecycle page as fetched on 24 October 2026. Dates in the future are SUSE's published plans; recheck a date in 2031 every year rather than treating it as a guarantee.

SLES 10 service packs

SLES 10 set the pattern SUSE followed for fifteen years: a major release, then a service pack roughly every year or two, with each service pack getting general support until some months after the next one ships, and LTSS available for customers who could not move in time.

SLES 11 service packs

SLES 11 SP4 is the reason some auditors still see SLES 11 in asset inventories. Its regular LTSS ended in March 2022, but the lifecycle page lists an LTSS Core phase to 31 March 2028. If you find SLES 11 in your estate, treat the LTSS Core date as the hard edge and check your contract for exactly what that phase covers. Do not assume it covers every package.

SLES 12 service packs

SLES 12 general support ended on 31 October 2024. Anything still on SLES 12 SP5 today gets fixes only if it has an LTSS subscription, and that runs to 31 October 2027. SLES 12 also introduced the module concept: sets of packages grouped into their own repositories and updated on their own schedule. The lifecycle page shows, for example, that the Web and Scripting Module updates about every 18 months, the Public Cloud and Containers modules release frequently, and the Legacy Module has no update cadence at all. Modules matter for security because a module's support can end before the base product's does.

SLES 15 service packs

The SLES 15 table has one row that surprises people. Every earlier service pack lost general support about six months after the next one shipped, but SP7, the final service pack, keeps general support until 31 July 2031 and LTSS until 31 July 2034. If you are on SP4, SP5 or SP6 without LTSS, you are already unsupported; the cheapest fix is usually a service pack migration to SP7, not a jump to SLES 16.

SLES 15 is also where SUSE moved to the modular product layout. The lifecycle page notes that from SLES 15 onward products consist of a set of modules, refreshed with each service pack.

SLES 16: minor releases instead of service packs

SLES 16.0 shipped on 4 November 2025. The lifecycle page lists the planned minor releases through 16.6:

The pattern is easy to remember: a minor release every November, 24 months of general support for each one, three more years of LTS on top, and a longer tail for the final 16.6 release. The openSUSE Release Team's September 2025 post notes that SUSE Linux Enterprise is "extending its general support to 24 months", which is what lets Leap promise the same.

The SLES 16.0 release notes list several changes with direct security consequences:

• SELinux replaces AppArmor and is enforcing by default (permissive by default for SLES for SAP applications). Minimal VM images include the core SELinux packages and policies and label files during the image build.
• Post quantum key exchange is on by default for SSH. System wide cryptographic policies now enable post quantum cryptography key exchange algorithms for SSH connections.
• 32 bit execution is disabled by default on x86-64 and AArch64 to reduce attack surface. Statically linked 32 bit binaries and 32 bit container images will not run unless you re enable it.
• SHA-1 is disabled or marked unapproved in FIPS mode, because of FIPS 140-3 requirements.
• YaST has been removed. The new Agama installer takes over installation, with JSON or Jsonnet profiles for unattended installs. Cockpit is the documented web administration tool.
• NetworkManager is the only network stack. Network teaming (teamd) is gone in favour of NetworkManager bonding.
• The CPU floor is x86-64-v2 on AMD64 and Intel 64. The kernel is Linux 6.12, and /usr/bin/python3 points to Python 3.13.

SLES 16 also published a package lifecycle model. SUSE's documentation sorts every package into one of three categories. Stable packages (such as util-linux) avoid disruptive changes for the life of the release. Balanced packages, such as the system Python, can change with upstream and customer demand but must not break things. Agile packages are kept close to upstream even when that brings change; the example given is Go, which gets a new version about every six months with versions N and N-1 supported. For security teams this is useful: it tells you whether a fix will arrive as a backport into the version you have, or as a version bump you need to test.

How openSUSE Leap relates to SLE, and Leap end of life dates

Shared sources, shared binaries

Leap exists so that a community user and an enterprise customer run nearly the same bits. The openSUSE Project's Leap 15 end of life post describes each Leap 15 release as aligned with "its twin, which is source and binary compatible". For Leap 16, the release announcement goes further and talks about source and binary identicality with SLES 16.

In practice this has three consequences:

1. Security fixes for the shared core come from SUSE's maintenance stream. The Leap 16.1 RC post explains that maintenance updates "arrive with the SLES 16.1 GA and flow directly to Leap". That is why the project decided to release Leap 16.1 on the same day as SLES 16.1: an earlier Leap release would have had a gap with no maintenance updates.
2. Packages outside the shared core are maintained by the community. Leap carries extra packages that SUSE does not ship. Their update speed depends on community maintainers, so check which repository a vulnerable package came from before assuming the SLE patch clock applies.
3. Migration paths are designed in. The openSUSE Migration tool can upgrade Leap 15 to Leap 16, or move a system to Slowroll, Tumbleweed or SLES.

Leap release and end of life dates

Exact Leap end of life dates live on the openSUSE wiki's Lifetime page, which blocked our scripted requests. The dates below come from openSUSE News posts written by the release team, which say the same thing in prose:

A few details from those posts are worth knowing:

• Leap 15 ran for almost eight years. From 15.0 in May 2018 to the end of 15.6 in April 2026. The release team says this was more than 1.5 times the typical 60 months of support offered by most long term support distributions.
• Leap 15.6 was stretched on purpose. The usual Leap life cycle was 12 months plus 6 months of overlap. 15.6 was extended by four extra months so users still had six months to move after Leap 16.0 arrived in October 2025.
• Leap 16 changes the rule to 24 months per point release. Each minor release gets a full 24 months of community support, and the overlap covers two releases.
• Leap 16 raised the hardware floor. It requires x86-64-v2, disables 32 bit (ia32) support by default, is described as 2038 safe, ships SELinux as the default security module, and uses the Agama installer. AppArmor can still be selected after installation.
• Leap Micro is folding into Leap. The Leap 16.1 RC post says Leap 16.1 adds an Immutable Mode with a read only root filesystem and transactional updates, and that there will be no Leap Micro 6.3 or 7.0.

How Tumbleweed works as a rolling release

Tumbleweed has no version numbers in the usual sense. It is identified by snapshot dates. On the day this post was written, the Tumbleweed media file on download.opensuse.org identified the current build as openSUSE-20261021-x86_64-Build6.169, which is the snapshot of 21 October 2026.

From submit request to snapshot

The path a change takes into Tumbleweed is the part that matters most for security:

The openSUSE release tools documentation describes steps 3 and 7 directly. A staging project is "a mere project linked to a subset of Factory" with some packages changed by pending requests, which the release manager uses "to evaluate the behavior and inter-compatibility of different changes working together". The ToTest manager publishes a new snapshot only after it checks that "the overall status of openQA is green" and that all the repositories in openSUSE:Factory can be published.

The get.opensuse.org Tumbleweed page sums up the effect: each new package version is tested on its own, and "different clusters of versions are tested against each other". The same page notes that you can "rollback to last week's snapshot" with a single command, which is the snapper rollback covered below.

What rolling means for security

Rolling has a security upside and a security cost:

• Upside: fixes arrive as new upstream versions quickly, often without the backporting work an enterprise release needs. You also get new kernel hardening and toolchain defaults sooner.
• Cost: every update can bring behaviour changes, and there is no separate security only channel. On Tumbleweed you take the whole snapshot with zypper dup. If you need to freeze, you freeze everything.

For servers that must stay stable for years, Tumbleweed is the wrong tool. For developer workstations, build hosts that need the newest compilers, or anyone who wants the latest kernel drivers, it is a good one.

Slowroll

Slowroll is the newest member of the family, and its status deserves care. In January 2024 the openSUSE Project called it "an experimental distribution introduced in 2023", a slower rolling variant of Tumbleweed that integrates big updates about once a month alongside continuous bug fixes and security updates. The project was explicit that Slowroll is not a replacement for Leap. In mid 2024 openSUSE News reported scheduled monthly update drops (9 July, 9 August and 9 September 2024) with dated snapshots such as 20240902T0137.

On 24 October 2026, openqa.opensuse.org still lists an "openSUSE Slowroll" job group, and the Leap 16 announcement points users with older CPUs to Slowroll or Tumbleweed. We could not fetch the Slowroll wiki page to confirm whether the project still labels it experimental. Treat it as a community project with a monthly cadence, not as a supported product, and read the current Slowroll portal page before you standardise on it.

The Open Build Service and openQA: why they matter for build integrity

Open Build Service

The Open Build Service (OBS) describes itself as "a generic system to build and distribute binary packages from sources in an automatic, consistent and reproducible way". It is free software under the GPL and is used both by openSUSE (at build.opensuse.org) and by other projects that run their own instance.

Three properties make OBS relevant to supply chain security:

1. Builds come from tracked sources. Every package in OBS has its sources and spec file in the build service, with a history of changes and requests. A binary in a Tumbleweed or Leap repository can be traced back to a project, a package and a source revision.
2. Builds run on the build service, not on a maintainer's machine. OBS builds from the sources and repositories declared in the project, in the automatic, consistent and reproducible way its project page describes. That reduces the chance that something from a developer's laptop leaks into a release.
3. Repositories and packages are signed by the project's key. Users install with zypper, which verifies signatures against keys the system already trusts. The OBS user guide also covers container image signatures.

OBS also builds images (KIWI and other formats) and containers, so the same traceability covers installation media and container base images, not only RPMs.

openQA

openQA is the automated test system that drives the gating described above. Its documentation calls it "an automated test tool that makes it possible to test the whole installation process of an operating system". Tests run in virtual machines through a backend called os-autoinst, which records a video, screenshots and a JSON result for each run. Tests compare screen regions against reference images called needles, so a test can fail if the installer or desktop looks wrong, not only if a command returns an error.

The public openqa.opensuse.org front page lists job groups for Tumbleweed on x86, AArch64, PowerPC, s390x and RISC-V, Tumbleweed kernel testing, Slowroll, Leap 16.0, Leap 16.0 updates, Leap 16.1 and Leap Micro. That last point matters: maintenance updates for a stable Leap release are tested in openQA too, not only new snapshots.

What this does and does not protect

OBS and openQA are strong controls for build integrity and regression. They help ensure that what you install was built from the sources in the build service, by the project's infrastructure, and that it boots and works. They do not, on their own, prove that the upstream source was benign. A malicious change that is committed upstream and builds and tests cleanly can still pass. That limit applies to every distribution, and it is why distribution signing is necessary but not sufficient.

How security updates flow, and how package signing works

SUSE security advisories and data feeds

SUSE's security support page is the hub. From there you can reach:

• The SUSE Update Advisories database and the SUSE Security Announcements, browsable on the web or by email via the sle-security-updates list.
• Security updates by CVE number. Each CVE page shows the overall state of the issue, which products are affected or not affected, and the released package versions per product. A note on those pages explains that service packs in the LTSS phase are only listed for issues that meet the LTSS criteria, which is one more reason to keep systems on releases in general support.
• OVAL data for scanners that consume it.
• CSAF data. SUSE publishes CSAF advisories on ftp.suse.com, each JSON file with a detached .asc signature and SHA-256 and SHA-512 checksums, and a separate CSAF VEX tree organised by year. VEX files say, per product, whether a CVE is known affected, fixed or not affected, which is what lets a scanner stop flagging a CVE that SUSE has already backported a fix for.

SUSE rates issues on a four level scale: critical, important, moderate and low. Its rating page reserves critical for flaws that a remote unauthenticated attacker could easily exploit to compromise a system without user interaction. SUSE also publishes CVSS v3.1 base scores and notes that its score can differ from other vendors' scores for the same CVE.

Backporting and version strings

Like the other enterprise distributions, SLES backports fixes into the package version it shipped rather than jumping to the newest upstream release, at least for stable and balanced packages. A SLES 16.0 package version such as one ending in 160000.2.2 carries a release tag that encodes the SLE release. The upstream version number alone does not tell you whether a fix is present. The advisory, the CVE page or the VEX file does.

Patches in zypper

Zypper has a concept that the RPM layer does not: the patch. A patch is a maintenance update with a name (such as SUSE-SLE-Product-SLES-15-2021-2689), a category (security, recommended, optional and others), a severity, the CVE and bug numbers it fixes, and flags such as whether it needs a reboot. SUSE's documentation also describes retracted patches: updates that were withdrawn because they caused problems, which zypper will not install again. You can list them with zypper lp --all and look for the retracted status.

zypper patch installs all needed patches. SUSE's documentation states that if it succeeds, no vulnerable version of a package is left installed unless you confirm an exception. The zypper man page documents exit codes that make it scriptable: zypper patch-check returns 100 if patches are available and 101 if security patches are available, and zypper needs-rebooting returns 102 when a reboot is suggested.

On Tumbleweed and Slowroll there are no patches in this sense. You update with zypper dup, and security fixes arrive with the next snapshot.

Live patching

For SLES, kernel fixes can be applied without a reboot through SUSE Linux Enterprise Live Patching. SUSE's product page says it is included by default with SLES, applies critical updates to the kernel and key user space libraries at runtime, supports each patch chain for 13 months, and delivers patches as signed RPMs that install through zypper. Live patching shrinks the reboot window; it does not remove it. You still need a planned reboot into a newer kernel before the patch chain expires.

Package and repository signing

SUSE's signing keys page lists the keys that sign SLE products:

• From mid 2023, SLE 15 based products moved to an RSA 4096 bit package signing key (fingerprint ending 3FA1 D6CE, created 19 January 2023, expiry 18 January 2027). Service packs released before the switch stay signed by the older key.
• A reserve RSA 4096 bit key (fingerprint ending D588 DC46, expiry 16 January 2033) exists for disaster recovery if the main key is lost or compromised.
• The older RSA 2048 bit key from 2013 and a 1024 bit key from 2006 are listed for earlier products.
• Separate Secure Boot signing keys sign the boot chain from shim and grub2 to the kernel and kernel modules. A dedicated 2024 key covers SLE Micro 6.0, SLES 16 and newer products, and SUSE says it has historically rotated Secure Boot signing keys about once a year when Secure Boot security issues surface.

openSUSE switched Tumbleweed's RPM and repository signing key from RSA 2048 to RSA 4096 bits in January 2023, and said Leap 15.4 and 15.5 would follow. Keys ship in the openSUSE-build-key and suse-build-key packages and in each repository's repomd.xml.key. A key expiry date on a published page is not the same as an outage: SUSE and openSUSE extend expiring keys through updates to those key packages, which is one more reason to keep them current.

For the wider picture of how distributions sign repositories and packages, and where that chain can break, see Linux distribution package signing.

Step by step: identify, patch and roll back a SUSE family system

The commands below work on SLES 15 and 16 and on Leap 15 and 16 unless noted. Tumbleweed differences are called out. Run them as root or with sudo.

Step 1: identify the release

# Distribution, version and ID
cat /etc/os-release

# Kernel actually running (not just installed)
uname -r

# On SLES only: registration and subscription status
sudo SUSEConnect --status-text

In /etc/os-release, ID is sles, opensuse-leap, opensuse-tumbleweed or opensuse-slowroll, and VERSION_ID gives the release (for example 15.7 for SLES 15 SP7, 16.0 for SLES 16.0 or Leap 16.0). Tumbleweed's VERSION_ID is the snapshot date.

Step 2: map the release to its support status

There is no local command that tells you a release's end of life date. Map ID and VERSION_ID to the tables above, then confirm against the source:

• SLES: SUSE's lifecycle page. Check the service pack or minor release row, not the product family row.
• Leap: the openSUSE Lifetime wiki page and openSUSE News announcements.
• Tumbleweed: there is no end of life, but a snapshot is only "supported" in the sense that the next snapshot fixes it. A Tumbleweed host that has not run zypper dup in months is effectively unpatched.

A small inventory script that records ID, VERSION_ID and uname -r for every host, and compares them against a table you maintain from the lifecycle page, catches most problems before an auditor does.

Step 3: refresh repositories and check signature trust

# Refresh repository metadata (verifies repo signatures)
sudo zypper refresh

# List the package signing keys RPM trusts
rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'

# Make sure the key packages themselves are current
sudo zypper update suse-build-key        # SLES
sudo zypper update openSUSE-build-key    # Leap and Tumbleweed

If zypper refresh asks you to trust a new key, stop and compare the fingerprint against the vendor's published keys page before accepting it. Never answer yes to a key prompt in an unattended script.

Step 4: list the security patches that apply (SLES and Leap)

# Exit code 100 = patches available, 101 = security patches available
zypper patch-check; echo "exit code: $?"

# Security patches that are needed on this system
zypper list-patches --category security

# Only important and critical ones
zypper list-patches --category security --severity critical,important

# Which needed patches fix which CVEs
zypper list-patches --cve

# Is a specific CVE fixed or still pending here?
zypper list-patches --all --cve=CVE-YYYY-NNNNN

# Full details of one patch
zypper patch-info SUSE-SLE-Product-SLES-15-2021-2689

Replace the CVE placeholder with a real identifier. zypper list-patches --all shows patches that are already applied too, which is how you prove to an auditor that a fix is installed rather than merely available.

Step 5: apply patches

# Patch the package manager first if zypper says the update stack needs it
sudo zypper patch --updatestack-only

# Apply all needed security patches
sudo zypper patch --category security

# Or apply every needed patch
sudo zypper patch

# Check again: exit code 0 means nothing left to apply
zypper patch-check; echo "exit code: $?"

If a patch updates zypper or libzypp itself, zypper returns exit code 103 and asks you to run the command again. Scripts should loop on 103.

On Tumbleweed and Slowroll, use a distribution upgrade instead:

sudo zypper refresh
sudo zypper dup

Step 6: restart what the update touched

# Is a reboot suggested? Exit code 102 means yes
zypper needs-rebooting; echo "exit code: $?"

# Which running processes still use deleted (old) files
sudo zypper ps -s

zypper ps -s lists processes that still have old libraries mapped and the systemd services to restart. A patched OpenSSL library does nothing for a daemon that loaded the old one last week.

Step 7: look at the snapshots that zypper created

On a default Btrfs root, the snapper-zypp-plugin takes a pre and post snapshot around each zypper transaction.

# List snapshot configurations
sudo snapper list-configs

# List pre and post snapshot pairs
sudo snapper list -t pre-post

# What changed between a pre and post pair (numbers from the list)
sudo snapper status 350..351

Step 8: roll back if an update broke the system

Warning: a rollback changes which root filesystem snapshot boots by default. Data written to the root subvolume after the target snapshot will not be in the rolled back system. Confirm you are on the right host and that the root filesystem is Btrfs before you run it.

# Check first: the root filesystem must be Btrfs, and note the current default
findmnt -no FSTYPE /
sudo snapper list

# Option A: boot into an older snapshot from the GRUB menu
# ("Start bootloader from a read-only snapshot"), check it works, then:
sudo snapper rollback

# Option B: roll back to a specific snapshot number from the running system
sudo snapper rollback 350

# Then reboot into the restored state
sudo reboot

SUSE's documentation explains that snapper rollback first creates a snapshot of the current state and then makes the target snapshot the new default subvolume for root, so you can roll forward again if the rollback was the mistake. Directories excluded from snapshots by the default subvolume layout (for example parts of /var and home directories on separate subvolumes or partitions) are not rolled back.

On Leap 16.1 in Immutable Mode and on Leap Micro, updates go through transactional-update instead, and rollback is sudo transactional-update rollback followed by a reboot, as the openSUSE release team shows in the Leap 16.1 RC announcement.

Step 9: plan the release upgrade

• SLES service pack or minor release: SUSE documents service pack migration through its registration tooling. Plan SP4, SP5 or SP6 to SP7 before LTSS lapses, and SLES 16.0 to 16.1 before November 2027.
• Leap 15 to Leap 16: the openSUSE Migration tool handles the upgrade. Check your CPU supports x86-64-v2 first, because Leap 16 will not run on older processors.
• Leap to SLES: the same tool can migrate a Leap system to the matching SLES release, which is how some teams move a proof of concept into a supported environment.

Tumbleweed, Leap and SLES compared

The quick decision rule:

• Need a vendor support contract, certifications or more than two years on one release? SLES.
• Want the SLES core for free and can upgrade every year or two? Leap.
• Want the newest kernel, compilers and desktop, and will update weekly? Tumbleweed.
• Want something in between for a desktop, and accept a community project? Slowroll.

Common mistakes

1. Reading the family row instead of the service pack row. "SLES 15 is supported to 2031" is true only for SP7. SP6 lost general support on 31 December 2025.
2. Assuming Leap end of life matches SLES. Leap 15.6 ended on 30 April 2026 while SLES 15 SP7 continues to 2031. Leap is free because its window is short.
3. Trusting upstream version numbers. SUSE backports fixes. A scanner that compares an RPM's upstream version against a CVE's affected range will raise false positives on SLES and Leap unless it uses SUSE's advisories, OVAL or VEX data.
4. Running zypper update and calling it patched. zypper update updates packages; zypper patch applies maintenance patches including those that need special handling. On SLES and Leap, prefer zypper patch and check zypper patch-check afterwards.
5. Running zypper update on Tumbleweed. Tumbleweed expects zypper dup. Partial updates can leave the system in a state no snapshot was tested in.
6. Forgetting restarts. Updated libraries stay unused until the processes that use them restart. zypper ps -s tells you which ones.
7. Leaving live patching to run forever. A kernel live patch chain is supported for a limited time. Schedule the real reboot.
8. Turning off snapshots to save disk space. Snapper cleanup settings can be tuned. Disabling snapshots removes your fastest recovery path after a bad update.
9. Accepting a new signing key prompt blindly. Compare fingerprints with the vendor's keys page first.
10. Upgrading to Leap 16 or SLES 16 on old CPUs. Both need x86-64-v2. Check before you schedule the window.
11. Forgetting container base images. A container built on a Leap or SLE base image carries that release's packages and its end of life date, no matter how current the host is.

Where Safeguard fits, honestly

Safeguard does not patch operating systems, replace zypper, or decide when your SLES subscription lapses. Those jobs belong to SUSE's tooling and your own fleet management. Where Safeguard helps is the software you build on top of these systems and ship in containers. The Safeguard CLI scans a source directory (safeguard scan --dir .), a container image (safeguard scan --image <name>) or an existing SBOM file (safeguard scan --sbom <file>), and the platform shows which projects contain a given component and version, matches components against vulnerability databases, and uses reachability analysis to rank the code paths your application actually calls. Policies and gates can stop a build that would ship a known vulnerable component, and autonomous remediation can open fix pull requests for application dependencies (it ships switched off). For OS level packages on a SUSE host, SUSE's advisories, CVE pages and VEX data stay the authority.

FAQ

What is the difference between openSUSE and SUSE Linux Enterprise?

SUSE Linux Enterprise (SLE) is SUSE's commercial product line, sold by subscription with long support, certifications and paid LTSS. openSUSE is the community project sponsored by SUSE. It produces Tumbleweed (rolling), Slowroll (slower rolling) and Leap (fixed release built from SLE sources and binaries).

Is openSUSE Leap the same as SLES?

Close but not identical. Leap 16 shares its source and core binaries with SLES 16 and can be migrated to SLES 16. It differs in support length (24 months per point release instead of SLES's general support plus LTS), has no paid support or certifications, and includes community packages that SLES does not ship.

When does SLES 15 reach end of life?

SLES 15 SP7, the last service pack, is in general support until 31 July 2031 and LTSS until 31 July 2034, with an LTSS Core date of December 2037 on SUSE's lifecycle page. Earlier service packs end sooner: SP4 LTSS ends 31 December 2026, SP5 LTSS 31 December 2027 and SP6 LTSS 31 December 2028.

When does SLES 12 reach end of life?

SLES 12 SP5 general support ended on 31 October 2024. LTSS for SP5 runs to 31 October 2027, and the lifecycle page lists LTSS Core to October 2030.

When was SLES 16 released and how long is it supported?

SLES 16.0 was released on 4 November 2025. It has general support to 30 November 2027 and LTS to 30 November 2030. The SLES 16 family runs to 30 November 2035 in general support and 30 November 2038 in long term support, with minor releases planned each November through 16.6 in 2031.

When did openSUSE Leap 15.6 reach end of life?

On 30 April 2026. The release team stretched it by four months beyond the usual 18 month window so users had six months to move to Leap 16.0, which was released on 1 October 2025.

Is openSUSE Tumbleweed stable enough for servers?

It is tested before every snapshot, through staging projects and openQA, and many people run it on workstations and build machines. For long lived production servers, a fixed release (Leap or SLES) is the safer choice, because Tumbleweed has no separate security only channel and every update can change behaviour.

What is openSUSE Slowroll?

A slower rolling variant of Tumbleweed that pulls in big updates about once a month while still taking bug and security fixes in between. openSUSE introduced it in 2023 and called it experimental in January 2024. It is not a replacement for Leap.

How do I install only security updates on SUSE?

On SLES and Leap, run zypper patch with the security category, as shown in the step by step section. Use zypper patch-check before and after; exit code 101 means security patches are still pending. On Tumbleweed and Slowroll, security fixes arrive with the next snapshot through zypper dup.

How do I roll back a bad update on openSUSE?

On a Btrfs root with snapper, boot an older read only snapshot from the GRUB menu, confirm it works, then run snapper rollback and reboot. On Immutable Mode systems, use transactional-update rollback and reboot.

A SUSE host is patched by SUSE, but almost nothing that runs on it today is only the operating system: application dependencies, language runtimes pulled by pip or npm, and container images built on Leap or SLE bases all ship open source components on their own clocks. The fit here is indirect for the OS packages themselves, and direct for the application and image layers you build and deploy on top of them.

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. It installs the CLI, opens the interactive terminal, and asks it to fix a lodash CVE in a repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to an application you deploy on a Leap or SLES host: zypper keeps the OS current, and the CLI handles the dependencies your own code pulls in.

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. If your build hosts run Tumbleweed or Leap, this is how scans of your source trees and images stay on hardware you control.

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 chooses which tools Claude can use. It is useful when you want to ask, in plain language, which of your projects carry a given component and version, while still reading SUSE's own advisories for the OS packages underneath.

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

Get the CLI at safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• SUSE Product Lifecycle
• SUSE company history
• SUSE about page
• SUSE Security support hub
• SUSE security rating overview
• SUSE signing keys
• SUSE security updates by CVE number
• SUSE CSAF advisories directory
• SUSE CSAF VEX directory
• SUSE Linux Enterprise Live Patching
• SUSE Linux Enterprise Server 16.0 release notes
• SUSE Linux Enterprise Server 16.0 documentation
• Lifecycles of SUSE Linux Enterprise 16 packages
• SLES 15 SP7: managing software with command line tools (zypper)
• SLES 15 SP7: system recovery and snapshot management with Snapper
• zypper manual page source
• openSUSE Leap 16.0 download page
• openSUSE Tumbleweed download page
• openSUSE News: Next Chapter Opens with Leap 16 Release (1 October 2025)
• openSUSE News: openSUSE Leap and Leap Micro doubles down on support (3 September 2025)
• openSUSE News: Closing Out a Roughly 8-Year Era (1 April 2026)
• openSUSE News: Leap 16.1 nears RC (24 September 2026)
• openSUSE News: Try Immutable Mode with openSUSE Leap 16.1 RC (28 September 2026)
• openSUSE News: Leap 15.5 nears end of life (19 December 2024)
• openSUSE News: Leap 15.6 announcement (6 June 2023)
• openSUSE News: Clarifying misunderstandings of Slowroll (19 January 2024)
• openSUSE News: Slowroll updates (2 September 2024)
• openSUSE News: openSUSE's 18th birthday (9 August 2023)
• openSUSE News: New 4096 bit signing key (23 January 2023)
• Open Build Service
• Open Build Service user guide
• openQA instance for openSUSE
• openQA documentation
• openSUSE release tools: staging plugin documentation
• openSUSE release tools: ToTest documentation
• Tumbleweed repository media file

Last reviewed: 24 October 2026. Future dates on SUSE's lifecycle page are plans, and openSUSE dates move when a release slips; check SUSE's lifecycle page and the openSUSE Lifetime page before planning an upgrade.