Ubuntu 10.10 to 17.10: The Unity Years, systemd, Snaps and GNOME

Ubuntu shipped twelve interim releases between 10.10 "Maverick Meerkat" (10 October 2010, Linux 2.6.35) and 17.10 "Artful Aardvark" (19 October 2017, Linux 4.13). Across them Unity became the default desktop in 11.04, interim support was cut from 18 months to 9 in 13.04, systemd replaced Upstart in 15.04, and 17.10 returned to GNOME on Wayland. Every one of these releases is now end of life with no security updates.

This post covers each interim release of the "Unity years": its facts, what changed from the release before, and the security defaults that moved. Every fact comes from Canonical's release notes on documentation.ubuntu.com, the Ubuntu release cycle page, the old-releases archive, or archived copies of official wiki pages retrieved through the Wayback Machine, all fetched on 23 October 2026. Where a page does not state something, we say so. For the full list of every Ubuntu release, see the hub: every Ubuntu release, codename, kernel and support date.

Key takeaways

• Twelve interim releases, all end of life. 10.10, 11.04, 11.10, 12.10, 13.04, 13.10, 14.10, 15.04, 15.10, 16.10, 17.04 and 17.10. None of them has ESM, Ubuntu Pro or Legacy coverage. The release cycle page describes interim releases as getting "only 9 months of updates".
• Unity arrived in two steps. 10.10 made Unity the default in Ubuntu Netbook Edition only. 11.04 made it "the default Ubuntu desktop session" for desktops, laptops and netbooks.
• LightDM replaced GDM in 11.10, and GDM came back in 17.10.
• 12.10 was the first Ubuntu release to support UEFI Secure Boot, and it also shipped the Unity Shopping Lens that delivered commercial results to the Dash, together with a new privacy setting to stop the Dash making network connections. Online searches in the Dash were not disabled by default until the 16.04 LTS release.
• 13.04 cut interim support from 18 months to 9 months. The 13.04 notes say so directly.
• 15.04 replaced Upstart with systemd "as the standard boot and service manager on all Ubuntu flavors except Touch", and 16.10 moved user sessions to systemd as well.
• 16.10 turned on position independent executables by default in GCC on amd64 and ppc64el.
• 17.10 switched the desktop to GNOME 3.26, made Wayland the default "on supported systems", replaced LightDM with GDM, and stopped producing 32-bit desktop installer images.
• If you find one of these releases today, it needs a rebuild on a supported LTS, not a patch. Check with lsb_release -a, cat /etc/os-release and uname -r.

What were the Ubuntu interim releases from 10.10 to 17.10? The facts table

How to read the columns. Released and End of life come from the "End of Life" table on the archived Ubuntu Releases wiki page, as captured by the Wayback Machine on 3 June 2019 (the live page now only shows the latest release). Kernel is the version the release notes name. Desktop is the default Ubuntu desktop session the notes describe. Support is the window the release's own notes state.

A few notes on the gaps and the sources.

• The 12.10 notes are split. The 12.10 page on documentation.ubuntu.com is a short overview that links to per edition wiki pages. Those pages now return 404. We retrieved the original Ubuntu Desktop and Ubuntu Server pages (https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuDesktop and .../UbuntuServer) from Wayback Machine captures of January 2013. Those archived pages state the 3.5.0-17.28 kernel and an "18 months" support period. Our hub table, which used only live pages, marked the 12.10 kernel as not stated; this post fills that in from the archived official page.
• The 10.10, 11.04 and 11.10 notes do not state a support period. The 18 months figure for them comes from the 13.04 and 13.10 notes, which say "Previous non-LTS releases were supported for 18 months", and from the archived 12.10 notes.
• The end of life dates do not always match the stated window. 11.10 ran to 9 May 2013 and 12.10 to 16 May 2014, both a little over 18 months. 15.04 ran to 4 February 2016, a little over 9 months. The release notes give the policy; the archived Releases page gives the date support actually stopped. We used the Releases page for the "End of life" column.
• Desktop versions are only as precise as the notes. 11.04 gives no GNOME platform version for the default image, and 13.10 and 14.10 name no Unity version.
• The old-releases archive lists all twelve. old-releases.ubuntu.com/releases shows a directory for each codename from Maverick to Artful. That is the only place to get these images now.

What changed from one release to the next?

This is the mandatory "what changed" table: one row per release, comparing it with the release before.

How did Unity become the default desktop?

10.10: Unity on netbooks first

The 10.10 release notes list Unity under Ubuntu Netbook Edition, not the desktop: "The new Unity interface ... is now the default in Ubuntu Netbook Edition." It brought a launcher, a global menu bar, places for applications and files, and search through Zeitgeist. The regular Ubuntu Desktop Edition stayed on GNOME, updated to 2.32 "including the new dconf and gsettings API". So on 10.10, a desktop install and a netbook install looked different.

11.04: Unity for everyone

The 11.04 release notes say "Unity is now the default Ubuntu desktop session", and that the release "supersedes Ubuntu Netbook Edition for all PC netbooks." The notes also list many Unity known issues, including freezes from "a bad interaction between Unity, the GL driver and the kernel" on some systems and limited input method support in search. For machines without 3D support the notes point users to the "Ubuntu Classic" session.

Flavours did not follow. The same notes say Edubuntu shipped "the classical Gnome desktop by default" and that Ubuntu Studio "does not currently use Unity".

11.10: GNOME 3 underneath, LightDM in front

The 11.10 release notes describe the biggest plumbing change of the era. GNOME 3.2 replaced GNOME 2.32, "a major upgrade", and GNOME Classic was no longer installed by default. Unity 2D was promoted "to the primary fallback shell", so machines without 3D acceleration still got a Unity session. "Places" were renamed "Lenses", with a new music lens. And the login screen changed: "Ubuntu now uses the LightDM login manager with the Unity greeter." Xubuntu, Mythbuntu and Ubuntu Studio switched to LightDM in the same release.

If you audit an 11.10 to 17.04 machine, expect LightDM, with its own configuration files and security history, unless someone changed it.

12.10 to 16.10: Unity matures

12.10 shipped Unity 6.8, 13.04 shipped Unity 7 with "a lot of performance improvements, reduced memory consumption", and 15.04 shipped Unity 7.3 with an option to show menus at all times. Each of 14.10, 15.04 and 15.10 says "Unity has had many bugs fixed". Meanwhile, Unity 8 grew up on the phone side: 13.10 shipped the first Ubuntu for phones images with Mir and Unity 8, the 16.10 notes list Unity 8 session known issues, and 17.04 says "Unity 8 is available as an alternative session".

What was the Amazon and Shopping Lens privacy change?

This is the part of the Unity years people still ask about, so here is exactly what the official notes say.

The archived 12.10 Ubuntu Desktop release notes (original URL: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuDesktop) list these Unity 6.8 changes:

• the addition of a "More Suggestions" category "which delivers commercial content to the Dash via the 'Unity Shopping Lens'";
• an "Option to prevent any network connection from the dash in the privacy gnome control center panel";
• webapps in the launcher by default, "including Amazon & Ubuntu One Music stores";
• previews in the video lens that "now show details for remote Amazon videos".

So the 12.10 notes confirm a commercial search lens and Amazon content in the Dash, and they confirm the opt-out switch. They do not use the phrase "Amazon search lens", and they do not say who supplied the Shopping Lens results; we leave that out rather than fill it from memory.

The default changed later, in an LTS rather than an interim. The 16.04 release notes say: "Online searches in the dash are now disabled by default." None of the interim notes between 12.10 and 15.10 that we fetched states a change to that default. 17.10, with Unity gone, notes only that "The Amazon app now loads in the default web browser." Our 16.04 LTS post covers the rest of that release.

A search box that sends keystrokes to a remote service is a data flow, and the default matters more than the option.

When was interim support cut from 18 to 9 months?

In 13.04. The 13.04 release notes state: "Ubuntu 13.04 will only be supported for 9 months. Previous non-LTS releases were supported for 18 months." The 13.10 notes repeat it: "Non-LTS releases prior to Ubuntu 13.04 were supported for 18 months." From 14.10 onward, each set of notes says the release "will be supported for 9 months for Ubuntu Desktop, Ubuntu Server, Ubuntu Core, Kubuntu, Ubuntu Kylin along with all other flavours."

The change had a practical effect that is easy to miss. Under the 18 month rule, someone could skip an interim and still stay supported. Under the 9 month rule, an interim user has about three months after the next release to upgrade before support ends. The server guide still makes the same point today: "We recommend running a Long Term Support (LTS) release as it provides 5 years of standard support and security updates, whereas interim releases are only supported for nine months."

The dates bear this out. 13.04 was released on 25 April 2013 and reached end of life on 27 January 2014. 12.10, released six months earlier under the old rule, outlived it and stayed supported until 16 May 2014. For the full support model see the Ubuntu release support lifecycle explained.

When did systemd replace Upstart?

In 15.04, after five releases of Upstart growth.

The Upstart years are visible in the notes. 10.10 still warns that "Upstart jobs cannot be run in a chroot". 11.04 updated Upstart to 0.9.7 and made it "chroot-aware". 11.10 shipped Upstart 1.3 "with support for displaying boot-time status on servers and more reliable handling of legacy sysvinit scripts". 13.04 shipped Upstart 1.8 with upstart-file-bridge and a technology preview of Upstart User Sessions, "disabled by default". 13.10 shipped Upstart 1.10, turned User Sessions on by default and added "Native AppArmor support in Upstart".

Then the 15.04 release notes say "systemd has replaced Upstart as the standard boot and service manager on all Ubuntu flavors except Touch." The same section says "Upstart continues to control user sessions", gives a GRUB menu path to boot once with Upstart, and says the upstart-sysv package switches back permanently. Custom Upstart jobs needed "a corresponding systemd service file or SysV init.d script".

The last step came in 16.10. The 16.10 notes say "systemd is now used for user sessions. System sessions had already been provided by systemd in previous Ubuntu releases." 17.04 then made systemd-resolved the default DNS resolver, and 17.10 replaced ifupdown with netplan driving systemd-networkd or NetworkManager.

Hardening written for Upstart job files does not apply to systemd units. If an old host's configuration management still writes to /etc/init, it targets the pre 15.04 world.

What did 17.10 change: GNOME Shell, Wayland and the end of 32-bit desktop images

The 17.10 release notes list the return to GNOME as plain statements:

• "The Ubuntu Desktop now uses GNOME instead of Unity."
• "On supported systems, Wayland is now the default display server." The Xorg session stays available as "Ubuntu on Xorg" from the login screen.
• "GDM has replaced LightDM as the default display manager." The login screen moved to virtual terminal 1.
• "32-bit installer images are no longer provided for Ubuntu Desktop."
• "Window control buttons are back on the right for the first time since 2010."
• GNOME apps moved to 3.26, Python 2 was no longer installed by default, Python 3 moved to 3.6, and the Ubuntu GNOME flavour was discontinued, with its users upgraded to Ubuntu.

So all three items in the question are confirmed by the official notes, with one precision: what 17.10 dropped was 32-bit installer images for Ubuntu Desktop. The notes do not say the i386 architecture was dropped from the archive, and the 17.10 download list still includes flavour images.

Wayland matters for security because it changes which programs can read other windows and inject input. The 17.10 known issues reflect that: some admin utilities "will not work with GNOME on Wayland" because they had not been adapted to PolicyKit, and screenshot, screencast and remote desktop server apps "do not currently work". That was the cost of a session that does not let every client watch every other client.

17.10 also carried a hardware warning that is worth knowing if you ever boot an old 17.10 image: the notes describe a bug in the Linux 4.13 kernel that "can leave users unable to update any of their BIOS settings" on certain Lenovo and Acer systems, and they told users with affected systems not to upgrade or boot the installer until it was resolved. We could not confirm from the pages we fetched whether, or when, replacement 17.10 images were published, so treat any 17.10 installer image you find with care.

What were the security changes release by release?

These are the changes the notes themselves describe as security relevant, plus the defaults the brief asks about. Where a topic is not mentioned in a release's notes (ufw, TPM, unattended-upgrades and phased updates are not mentioned in any of these twelve), we say so rather than guess.

10.10: ptrace restricted by default

The 10.10 notes describe "the change to the default behavior of PTRACE": only child processes can be traced, "due to the default value of '1' in /proc/sys/kernel/ptrace_scope". That stops one compromised process under your account from attaching a debugger to another and reading its memory. The notes tell developers they can set it to 0 and point to /etc/sysctl.d/10-ptrace.conf. The kernel also carried fixes for CVE-2010-3081 and CVE-2010-3301. On the server side, libvirt "runs kvm with limited rights", and libvirt stopped probing disk image formats and defaulted to raw, which the notes call a fix for something "considered a security problem in most deployments".

11.04 and 11.10: AppArmor upstream, /run, multiarch

The 11.04 kernel notes list "upstream acceptance of AppArmor" among the highlights. 11.10 moved runtime state from /var/run, /var/lock and /dev/shm to /run, and its notes warn that while shipped AppArmor policy was adjusted, "custom policy may need to be updated". 11.10 also introduced multiarch, so 32-bit libraries on amd64 came from the same packages as on i386 and got security updates the same way. And the UEC components, including Eucalyptus, were removed from "the security-supported main component of the archive", which is a reminder that the archive component decides who patches a package. Our post on whether Ubuntu patches universe packages explains how that works today.

12.10: UEFI Secure Boot and signed kernels

The archived 12.10 notes say "Ubuntu 12.10 is the first Ubuntu release to support UEFI Secure Boot", but "only some flavors" would install and boot on Secure Boot hardware at release: Ubuntu desktop, Ubuntu server and Edubuntu, with other flavours expected in 13.04. The kernel notes list "Packaging updates for signed kernels". 12.10 also put LVM and full disk encryption on the consolidated 800MB desktop image, where previously they needed the alternate CD. For the background, see Secure Boot, trusted boot and measured boot.

13.04 and 13.10: shorter support, AppArmor DBus mediation

13.04's most important security fact is the support cut itself. 13.10 added AppArmor "fine-grained DBus mediation for bus, binding name, object path, interface and member/method", native AppArmor support in Upstart, and better policy generation tooling. The notes warn that local policy may need adjusting, "especially for named AF_UNIX sockets". 13.10 also promoted LXC to main, where it "will benefit from the attention of the Ubuntu Security team".

14.10: kernel ASLR and socket mediation

The 14.10 notes say: "On the security front we see full Kernel Address Space Layout Randomisation applied to the kernel and its modules, plus the closure of a number of information leaks in /proc." AppArmor added mediation of unix abstract and anonymous sockets, and containers launched with libvirt-lxc "can now be apparmor-protected".

15.04: seccomp, signed kexec, systemd

The 15.04 kernel notes mention "a slew of improvements in Apparmor as well as improved seccomp support including support for cross thread protection", and "support for signed kexec a key gap in secure boot support". Without signed kexec, a booted kernel could load an unsigned one and step around Secure Boot. 15.04 also introduced LXD ("secure by default", per the notes, though shipped as 0.7 and "not ready for production workloads") and snappy Ubuntu Core with transactional updates. For how snaps confine applications, see snap store and flatpak security models.

15.10: F2FS encryption, golang rebuild caveat

Linux 4.2 added F2FS file system encryption. The notes also carry a supply chain point that still applies: with golang 1.5 statically linked, "3rd party developers desiring bug and security fixes from Ubuntu's updated golang packages will need to rebuild their software with these updates." A distro security update to a Go library does nothing for a binary built before it.

16.10: PIE by default and AppArmor stacking

16.10 changed the toolchain: "We have modified GCC to by-default compile programs with position independent executable support, on the amd64 and ppc64el architectures, to improve the security benefits provided by Address Space Layout Randomization." The same notes warn that because the kernel changed how executables are run, AppArmor profiles from older kernels "may require modification", and they show the file_mmap denial to look for. LXD 2.4.1 added "Support for AppArmor profile stacking", letting containers load their own profiles. The gpg binary moved to gnupg2. Our post on AppArmor complain or enforce on Ubuntu covers working with denials today.

17.04 and 17.10: resolver, Wayland, netplan, DNSSEC root key

17.04 made systemd-resolved the default resolver. 17.10's server notes add a DNSSEC item: bind9 gained the new root Key Signing Key ahead of the 11 October 2017 rollover. Wayland is the main desktop change, covered above.

What is not stated

None of the twelve sets of notes we fetched mentions ufw availability or its default state, TPM, unattended-upgrades, phased updates, Livepatch or ESM. Livepatch and ESM did not apply to interim releases. Do not assume a firewall was on by default on any of these releases; check the host. For today's defaults see our posts on ufw on an Ubuntu laptop and unattended upgrades.

How do you check which release, kernel and support status a machine is on?

These commands come from Canonical's own documentation. They work on these old releases as well as current ones, though some files and tools differ on very old systems.

Step 1: Read the release and codename

The lsb_release manual page documents -a as "Show all of the above information", meaning distributor, description, release and codename.

lsb_release -a

Minimal images may not include lsb_release. The os-release manual page documents the identification file and its fields such as VERSION_ID and VERSION_CODENAME:

cat /etc/os-release

If the codename is maverick, natty, oneiric, quantal, raring, saucy, utopic, vivid, wily, yakkety, zesty or artful, the system is on one of the releases in this post and is past end of life.

Step 2: Check the running kernel

The 18.04 release notes use uname -r to check the running kernel:

uname -r

Compare it with the kernel column in the table. A 4.13 kernel, for example, points to 17.10. Inside a container this prints the host kernel, not anything from the image, so it says nothing about the container's own release.

Step 3: Check whether it can get security updates

There is no pro coverage for interim releases, and none of these releases is listed on the release cycle page at all; its LTS rows start at 14.04. On a supported LTS, the Ubuntu Pro client basic commands tutorial shows how to confirm coverage:

pro status

On a 10.10 to 17.10 system there is no answer that makes it supported. The only fix is to move it.

Step 4: Move to a supported release

Canonical's server guide, How to upgrade your Ubuntu release, recommends do-release-upgrade on servers and cloud images and says the system "is not considered upgraded until" the final reboot:

sudo do-release-upgrade

The same guide says LTS releases can only upgrade "to the next sequential LTS release" and you "cannot skip releases". For an interim from this era, the upgrade chain to anything supported today is long: a 17.10 machine would have to go through 18.04 LTS, 20.04 LTS and 22.04 LTS at least, and every step before 22.04 lands on a release that is itself out of standard support. The guide's procedure assumes a release whose repositories are still served from the normal mirrors, which is no longer true for these twelve: their packages live only under old-releases.ubuntu.com. The official guide we fetched does not document upgrading from an end of life interim, so we do not give commands for it here.

In practice, for a server, reinstall on a current LTS (22.04, 24.04 or 26.04) and migrate the data and configuration. For a container, change the base image tag and rebuild. Our guides on what to do with end of life software and how to check whether a base image OS is end of life cover the decision and the inventory work.

Step 5: Get old images only from Canonical

If you need an image for forensic or compatibility work, use old-releases.ubuntu.com, which lists every release from this era by version and codename. Do not attach such a system to a network you care about.

Why these releases still matter for security today

These releases still turn up in old container base images that were never rebuilt, in appliances and embedded systems, in build hosts pinned to an old toolchain, and in VMs kept for reference. In each case there are no USNs any more and no paid tier changes that. The fastest way to find them is an inventory that records the OS release inside each image, not just the application dependencies. Our post on using SBOMs to find affected products fast shows how that inventory pays off during an incident.

Common mistakes

• Assuming interim releases got 9 months from the start. Before 13.04 they got 18 months. 12.10 outlived 13.04.
• Treating 10.10 as a Unity release. On the desktop it was GNOME 2.32; Unity was the default only on Netbook Edition. Unity became the desktop default in 11.04.
• Treating 15.04 as fully systemd. System services moved in 15.04, but "Upstart continues to control user sessions" until 16.10.
• Reading "32-bit dropped" too broadly in 17.10. The notes say 32-bit installer images stopped for Ubuntu Desktop. They do not say the architecture left the archive in that release.
• Expecting Wayland on every 17.10 machine. The notes say "On supported systems". Machines with unsupported graphics fell back to Xorg.
• Using uname -r to identify a container's release. It reports the host kernel. Read /etc/os-release inside the container.
• Looking for ESM for an interim release. There is none. Only LTS releases get ESM and the Legacy add-on.
• Downloading old ISOs from third party mirrors. Use old-releases.ubuntu.com only.
• Assuming a distro update fixed statically linked binaries. The 15.10 golang note is explicit: you must rebuild.

FAQ

Is Ubuntu 17.10 still supported?

No. The 17.10 release notes say it "was supported for 9 months until July 2018", and the archived Releases page gives 19 July 2018 as end of life. It has no ESM. Move to a current LTS.

What kernel does Ubuntu 17.10 use?

Linux 4.13. The notes say "Ubuntu 17.10 is based on the Linux release series 4.13."

When did Ubuntu switch from Unity to GNOME?

In 17.10, released 19 October 2017. The notes say "The Ubuntu Desktop now uses GNOME instead of Unity." Unity had been the default desktop session since 11.04.

When did Ubuntu start using systemd?

In 15.04 "Vivid Vervet", released 23 April 2015, for the boot and service manager. User sessions followed in 16.10.

How long were Ubuntu interim releases supported?

18 months up to and including 12.10, and 9 months from 13.04 onward, per the 13.04 and 13.10 release notes.

What was the Ubuntu Amazon lens?

The 12.10 notes describe a "More Suggestions" category delivering "commercial content to the Dash via the 'Unity Shopping Lens'", Amazon webapps in the launcher, and Amazon video details in the video lens, plus a privacy option to stop the Dash making network connections. Online searches in the Dash became disabled by default in 16.04 LTS.

Which Ubuntu release was the first to support Secure Boot?

12.10 "Quantal Quetzal". Its archived desktop notes say it "is the first Ubuntu release to support UEFI Secure Boot", initially for Ubuntu desktop, Ubuntu server and Edubuntu.

When did Ubuntu replace LightDM with GDM?

LightDM became the login manager in 11.10, and 17.10 notes "GDM has replaced LightDM as the default display manager."

Did Ubuntu 17.10 drop 32-bit support?

It dropped 32-bit installer images for Ubuntu Desktop: "32-bit installer images are no longer provided for Ubuntu Desktop." The notes do not say more than that.

Where can I download Ubuntu 12.10 or other old releases?

From old-releases.ubuntu.com/releases, Canonical's archive for end of life releases. Use them offline only.

Fix it without waiting for upstream

For the twelve releases in this post, upstream has already stopped: there will be no further USNs for any package on 10.10 to 17.10. The operating system itself has to be replaced with a supported release, and nothing below changes that. What you can fix right away is the application layer you build on top of it, which on an old image is often just as stale.

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 makes an end of life Ubuntu release supported again, and none replaces Canonical's updates on a supported one. They show how to find what is inside the images and repositories you build, and how to move the dependencies you control 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 produces an SBOM that lists the operating system packages and versions alongside the application components, which is how an image still built on 16.10 or 17.04 shows up in an inventory instead of hiding behind its tag.

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

In this session you install the Safeguard 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. When you rebuild an old service on a current LTS base, the same flow handles the application dependencies that came along with it.

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 the question to answer first when you suspect old Ubuntu userlands are still in your estate.

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.

Quick check

Sources

• Ubuntu release notes: 10.10
• Ubuntu release notes: 11.04
• Ubuntu release notes: 11.10
• Ubuntu release notes: 12.10 (overview)
• Ubuntu 12.10 Ubuntu Desktop release notes, archived (original: wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuDesktop)
• Ubuntu 12.10 Ubuntu Server release notes, archived (original: wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuServer)
• Ubuntu release notes: 13.04
• Ubuntu release notes: 13.10
• Ubuntu release notes: 14.10
• Ubuntu release notes: 15.04
• Ubuntu release notes: 15.10
• Ubuntu release notes: 16.04 LTS
• Ubuntu release notes: 16.10
• Ubuntu release notes: 17.04
• Ubuntu release notes: 17.10
• Ubuntu Releases wiki page, archived 3 June 2019 (original: wiki.ubuntu.com/Releases)
• Ubuntu: Release cycle
• Ubuntu old releases archive
• Ubuntu Server documentation: How to upgrade your Ubuntu release
• Ubuntu Pro Client documentation: basic commands
• Ubuntu manpages: lsb_release(1)
• Ubuntu manpages: os-release(5)

Related posts in this series: Ubuntu 10.04 LTS Lucid Lynx, Ubuntu 12.04 LTS Precise Pangolin, Ubuntu 14.04 LTS Trusty Tahr, Ubuntu 16.04 LTS Xenial Xerus, Ubuntu 18.04 LTS Bionic Beaver, Ubuntu interim releases 4.10 to 9.10 and Ubuntu interim releases 18.10 to 23.10.

Last reviewed: 23 October 2026.