Ubuntu vs Kali vs Debian: Differences and Who Should Use Which

Debian is the base: a volunteer distribution whose stable release gets three years of security team support plus two years of LTS. Ubuntu takes packages from Debian unstable each cycle and ships a release every six months, with an LTS every two years and five years of standard security maintenance. Kali is built on Debian testing as a rolling distribution for authorised security testing. Use Debian stable or Ubuntu LTS for servers, Ubuntu or a flavour for desktops, and Kali only for testing systems you own or have written permission to test.

Below: how the three relate, how each ships releases and security fixes, which defaults differ, and which fits servers, laptops, containers and testing work. Every fact comes from ubuntu.com, documentation.ubuntu.com, debian.org or kali.org, fetched on 23 October 2026 and linked in the sources. Where those pages disagree, or say nothing, we say so.

Key takeaways

• Debian is upstream of both. Ubuntu imports new package versions from Debian's unstable branch until each cycle's Debian Import Freeze. Kali is based on Debian testing and imports most packages as is.
• BackTrack was Ubuntu based; Kali is not. Kali's own history page lists BackTrack 4 on Ubuntu 8.10 and BackTrack 5 on Ubuntu 10.04, then Kali 1.0 in 2013 on Debian 7.
• Three release models. Debian has stable, testing and unstable, with a new stable roughly every two years and a five year life cycle. Ubuntu ships every six months, with an LTS every two years. Kali rolls continuously and cuts a versioned image about four times a year.
• Three security support models. Debian publishes Debian Security Advisories (DSAs) for stable. Ubuntu publishes Ubuntu Security Notices (USNs), with Expanded Security Maintenance (ESM) through Ubuntu Pro for up to 15 years in total on LTS releases. Kali publishes no fixed release support window; you stay current by tracking kali-rolling.
• Defaults differ in ways that matter. Ubuntu locks the root account and uses sudo, ships ufw disabled, follows a "No Open Ports" policy and enables automatic security updates. Debian's installer disables root only if you leave its password blank. Kali uses a non-root user by default since 2020.1 and disables network services from persisting across reboots.
• Kali is not a daily driver. Kali's own documentation says it is not recommended as a general purpose desktop or for people new to Linux.
• Authorised use only. Kali's tools are for penetration testing, forensics and research on systems you own or are allowed in writing to test.

How are Ubuntu, Kali and Debian related?

All three are Debian family distributions. They share the .deb package format and the APT package manager, and a lot of the same source packages. What differs is which Debian branch each one starts from, who maintains the changes on top, and how fixes reach you.

Debian is the root

Debian's releases page says the project "always has at least three releases in active maintenance": stable, testing and unstable. Stable is "the production release of Debian, the one which we primarily recommend using." Testing holds packages "that haven't been accepted into a stable release yet, but they are in the queue for that." Unstable is "where active development of Debian occurs" and is always called sid.

As of the page we fetched, the current stable is Debian 13 "trixie", first released as 13.0 on 9 August 2025, with its latest point release, 13.7, on 12 September 2026. The current testing distribution is forky (Debian 14), and Debian 15 has the codename duke, with no release date set.

Ubuntu is built from Debian unstable

Ubuntu's governance page on Debian puts it plainly: "Debian is the rock on which Ubuntu is built." Ubuntu "builds on the Debian architecture and infrastructure and collaborates widely with Debian developers," but has a different user interface, a separate developer community and a different release process.

The mechanics are in the Ubuntu project documentation. Before each cycle's Debian Import Freeze, "new versions of packages are automatically imported from Debian's unstable branch," as long as Ubuntu has not customised them. A sync is "the automatic copying of new packages from Debian unstable (code name 'Sid') to the Ubuntu Archive." Where Ubuntu carries its own patches (a delta), a developer merges the new Debian version by hand. So every Ubuntu release is a snapshot of Debian unstable at a point in time, plus Ubuntu's changes, then stabilised and supported by Canonical.

Kali is built from Debian testing

Kali's policy page on its relationship with Debian says: "The Kali Linux distribution is based on Debian Testing." Most Kali packages are "imported, as-is, from the Debian repositories." In some cases newer packages come from Debian unstable or Debian experimental, to improve the user experience or pick up bug fixes.

Kali forks a small number of packages to add its own features. Each forked package lives in a Git repository with a "debian" branch, so the Kali team can merge new Debian versions with a simple git merge. Kali also adds many packages specific to penetration testing and security auditing, and says it intends to contribute those back to Debian.

Kali's branches page shows the pipeline: Debian testing is mirrored into Kali's build system, combined with Kali specific packages and selected picks from Debian unstable and experimental to form kali-dev, and packages are copied to kali-rolling only once a tool has checked they are installable. Kali notes that check does not include functional testing. Kali "has used this branch as a starter for kali-rolling since January 2016."

BackTrack was Ubuntu based, Kali is not

This trips people up. Kali's history page traces the project from Whoppix (2004, on Knoppix) and WHAX (2005, on Slax), through BackTrack 1 to 3 on Slackware, then BackTrack 4 (January 2010) on Ubuntu 8.10 and BackTrack 5 (May 2011) on Ubuntu 10.04. Kali Linux 1.0 followed on 13 March 2013, built on Debian 7 (wheezy). Kali "started off using Debian stable as the engine under the hood before moving to Debian testing when Kali became a rolling OS."

So Kali shares a grandparent with Ubuntu, not a parent. If someone tells you Kali is "based on Ubuntu," they are describing BackTrack.

How do the release models differ?

Debian: stable releases and a five year life cycle

Debian's releases page says the release life cycle "encompasses five years: the first three years of full support followed by two years of Long Term Support (LTS)." The Debian security FAQ adds that the security team supports a stable distribution for three years after release, because supporting more than two distributions at once is not practical. After that, Debian LTS covers two more years, and the releases table also lists an ELTS column, which it describes for older releases as "third-party paid extended LTS support."

Here are the dates from the Debian releases table as we fetched it:

One caution: the page was last modified in June 2026, so its status column still describes Debian 11 as "under LTS support" even though the LTS end date it lists, 31 August 2026, has now passed. Use the dates, not the status text. Our post on Debian 11 bullseye end of life, LTS and ELTS dates covers what that means in practice.

Ubuntu: every six months, with an LTS every two years

Ubuntu's release cycle page says Ubuntu "releases a new version every six months," named by year and month. Ubuntu 26.10, codename "Stonking Stingray," was released in October 2026.

• Interim releases "provide cutting-edge features and hardware support every six months, but with only 9 months of updates." The page recommends them for teams "prioritizing speed and rapid feature testing."
• LTS releases come every two years and "receive 5 years of standard security maintenance," with CVE patches for packages in the Main repository. Ubuntu recommends them "for production environments, enterprises, and long-term projects."
• ESM through Ubuntu Pro extends LTS releases to "10 years of security updates for the 'Main' repository and also adds 10 years of security coverage for the 'Universe' repository."
• The Legacy add-on covers "additional 5 years," for "a total of 15 years security maintenance and support for LTS releases."

The dates above are from the release cycle page. Ubuntu's 26.04 LTS release notes, dated 23 April 2026, say the release "will be supported until April 2031" and that ESM is available "for ten years" with Ubuntu Pro. The release cycle page says May 2031. We used the release cycle page in the table and flag the one month difference here. The page also states that Ubuntu Pro "subscriptions are free for personal use on up to five machines."

Ubuntu's official flavours (Kubuntu, Xubuntu, Lubuntu and the rest) follow their own support policies. The release cycle page says "the release cycle for flavours may differ" and points to each flavour's own site.

Kali: rolling, with a release four times a year

Kali 2.0 in August 2015 was the release where Kali became a rolling distribution, and Kali 2016.1 on 21 January 2016 is listed on Kali's releases page as "the first Kali Rolling release." Since then Kali has published versioned snapshots of the rolling branch. Kali's update guide says "Kali has a release four times a year, and follows a loose quarterly schedule."

The latest release on Kali's releases page when we checked is Kali 2026.2, released 29 June 2026, with kernel 6.19 and Xfce 4.20.7. The 2026.2 release post also moved GNOME to version 50 and KDE Plasma to 6.6 for users who choose those desktops, and changed fresh installs to keep APT sources in /etc/apt/sources.list.d/kali.sources in the newer deb822 format instead of the old /etc/apt/sources.list. The releases page lists no 2026.3 as of 23 October 2026.

Kali offers two complete branches for users:

• kali-rolling is "the main default branch that most should be using." It is updated continuously.
• kali-last-snapshot freezes at each versioned release. Users get "all of the updates between versioned releases" in one step at the next release, and nothing in between. Kali calls it the "safest" option for stability.

Two partial branches, kali-experimental and kali-bleeding-edge, sit on top of kali-rolling, and kali-dev is for Kali developers only. Kali warns that kali-dev "should not be used by end-users as it will regularly break."

How does security support differ?

This is where the three diverge most, and where most real-world mistakes come from.

Debian: the security team, DSAs and backports

Debian's security page says the project handles "all security problems brought to our attention" and coordinates many advisories with other free software vendors, so "these advisories are published the same day a vulnerability is made public." Fixes are announced as Debian Security Advisories (DSAs) on the debian-security-announce mailing list, with a link to the Debian Security Tracker for each. On the day we checked, the page listed DSAs for packages including erlang, roundcube, bind9, nginx, php8.4, apache2 and the Linux kernel within the previous week.

Debian's DSAs are CVE compatible, and Debian publishes its security data in OVAL format. The security page also notes that the unattended-upgrades package "can be installed" to apply security updates automatically.

Three points from the Debian security FAQ matter for comparisons:

1. Debian backports fixes rather than upgrading versions. A version number that looks old does not mean a package is vulnerable. Compare against the fixed version in the advisory. Our post on how to check whether a distro has backported a security fix walks through this for Debian and Ubuntu.
2. Testing gets fixes later. The FAQ says security for testing benefits from work done for unstable, but "there is a minimum two-day migration delay," and fixes can be held up by transitions, especially in the months after a stable release. Its advice: "If you want to have a secure (and stable) server you are strongly encouraged to stay with stable."
3. contrib, non-free and non-free-firmware are not covered. The FAQ's short answer to how security is handled there: "it's not."

Point 2 matters for Kali too, because Kali is built from Debian testing.

Ubuntu: USNs, Main versus Universe, and ESM

Ubuntu publishes Ubuntu Security Notices (USNs) at ubuntu.com/security/notices. Standard security maintenance on an LTS covers packages in Main. The release cycle page explains that Ubuntu packages are grouped into Main and Restricted (the base system) and Universe and Multiverse (community and extra packages). That distinction is easy to miss: a package from Universe on an LTS release is not covered by standard security maintenance, and ESM for Universe ("ESM Apps") comes with Ubuntu Pro. Our explainer on whether Ubuntu patches Universe packages goes deeper.

Ubuntu's security documentation explains how ESM is delivered. Once you attach a Pro subscription, the Pro client writes APT sources for special archive pockets: Infra pockets for Main and Apps pockets for Universe, served from esm.ubuntu.com and signed with their own keyrings. ESM fixes are announced through the same USNs. The client pins ESM packages to APT priority 510, slightly above the default, so a standard update with a higher version number cannot quietly roll back an ESM security fix.

Ubuntu Pro also includes Kernel Livepatch, Landscape, FIPS 140-3 certified packages and CIS hardening, according to the release cycle page. Ubuntu's security feature matrix lists Livepatch for the 22.04, 24.04 and 26.04 LTS kernels and not for interim releases.

Kali: stay on rolling

Kali does not publish a fixed support window for a versioned release in any of the pages we fetched, and its model makes one unnecessary: the supported state of Kali is a current kali-rolling install. Kali's update guide says that with a default installation "you should be checking for updates every few days or weeks," and that hearing about a security update may speed that up. Users on kali-last-snapshot "will not receive updates until we release the next version of Kali."

Kali's guide also advises checking that your tools work before an engagement and not updating during it, because "once in a while issues will sneak into rolling." That suits a test window, not a long running server.

Because Kali tracks Debian testing, the Debian FAQ's note about testing applies: fixes for testing can lag behind unstable. Kali does not run its own advisory feed comparable to DSAs or USNs in the pages we fetched.

What are the default security settings?

Defaults are what you get if nobody touches the box. Here is what each project's documentation says about them. Where a page we fetched does not cover a default, we say so instead of filling the gap.

Root and sudo

• Ubuntu. The Ubuntu Server user management guide says Ubuntu developers "decided to disable the administrative root account by default in all Ubuntu installations." Root has "a password hash that matches no possible value," and administration happens through sudo. From Ubuntu 25.10 onward, sudo is provided by sudo-rs, a Rust implementation; the original sudo remains available as sudo.ws in 25.10 and 26.04 LTS.
• Debian. The Debian installation guide asks you to set a root password. If you leave it blank, "this account will be disabled but the sudo package will be installed," and "the first user created on the system will be allowed to use the sudo command to become root." So Debian's default depends on what you type during install.
• Kali. Kali's sudo page says that "with 2020.1 Kali has swapped to a privileged non-root user by default." Root has no password set, the account created at install is the one to use, and Kali says re-enabling root login "is not recommended." Kali offers an optional package for password-less sudo and warns it "poses a security risk should someone gain access" to the account.

Network services and the firewall

• Ubuntu. Ubuntu's security docs say it has followed a "No Open Ports" policy since Ubuntu 6.06 LTS: "a new installation should have no listening network services, with only rare exceptions." The firewall page describes ufw as "a simplified firewall configuration tool for Ubuntu," which is "available in Ubuntu, but disabled by default." The nftables backend for the iptables tools has been the default since Ubuntu 20.10. If you want to turn ufw on, see our guide to ufw on an Ubuntu developer laptop.
• Kali. Kali's network service policy says Kali "does not enable any externally-listening services by default," and "will disallow network services from persisting across reboots by default." If you install a package that would start a listening service, Kali's hooks stop it from starting at boot unless you enable it yourself. Kali's "Should I use Kali Linux?" page adds that "additional services such as Bluetooth are also blocklisted by default."
• Debian. The Debian pages we fetched do not describe a default firewall state or a no open ports policy, so we make no claim about either.

Mandatory access control

• Ubuntu. AppArmor is "a core technology for the Linux Security Module (LSM) on Ubuntu," according to Ubuntu's security docs. The feature matrix lists AppArmor 5.0.0 on 26.04 LTS and 26.10, and AppArmor unprivileged user namespace restrictions in kernel and userspace from 24.04 LTS onward, which let AppArmor "deny unprivileged applications the use of user namespaces" to reduce kernel attack surface. SELinux is available from Universe. Our comparison of SELinux and AppArmor for a server covers the trade-offs.
• Debian and Kali. The pages we fetched for Debian and Kali do not state whether AppArmor is enabled by default, so we make no claim either way.

Disk encryption and Secure Boot

• Ubuntu. Ubuntu's security docs describe full disk encryption with LUKS, using AES-256 in XTS mode by default, unlocked by passphrase or by TPM. The feature matrix lists "LUKS + TPM" for every current release, and the 26.04 LTS summary describes TPM-backed full disk encryption on Ubuntu Desktop, where the disk keys "are automatically generated and stored safely in your computer's Trusted Platform Module." UEFI Secure Boot is listed as "amd64, kernel signature enforcement." Kernel lockdown is in "integrity only" mode.
• Debian and Kali. Disk encryption and Secure Boot defaults are not described in the Debian and Kali pages we fetched.

Compiler hardening

Ubuntu's feature matrix lists stack protector, Fortify Source, RELRO, PIE and BIND_NOW on the main architectures, plus kernel and userspace ASLR. The Debian and Kali pages we fetched do not cover build flags.

Automatic updates

• Ubuntu. The feature matrix lists "Automatic security updates: enabled" for every current release. The Ubuntu Server guide says this is done by the unattended-upgrades package, "which is installed by default." Our post on unattended-upgrades and reboot settings explains the configuration, and phased updates explains why some updates arrive gradually.
• Debian. The security page says unattended-upgrades "can be installed" to keep the computer current.
• Kali. Kali's update guide tells you to update manually every few days or weeks and to freeze during engagements.

Snaps, repositories and telemetry

• Ubuntu supports both deb packages and snaps. The release cycle page says snaps "can run in a secure, confined environment with limited system access, or as 'classic' snaps with broader access," and advises choosing snaps "from trusted publishers, especially when using classic confinement." Our post on snap and flatpak security models compares them.
• Kali keeps "the set of upstream software sources which Kali uses" to "an absolute minimum," and says there is "absolutely no support whatsoever for the apt-add-repository command, LaunchPad, or PPAs." Every Kali package is GPG signed by the developer who built it and again by the repository.
• Debian signs each release's Release file, and for stable and oldstable adds a second signature "using an offline key specifically generated for a release" by a member of the Stable Release Team.
• Telemetry defaults are not described in the pages we fetched for any of the three, so we make no claim.

Who should use Debian, Ubuntu or Kali?

Servers and production systems

Both Debian stable and Ubuntu LTS are designed for this, in their own words. Debian calls stable "the production release of Debian, the one which we primarily recommend using." Ubuntu recommends LTS releases "for production environments, enterprises, and long-term projects" and says interim releases are for teams that move fast.

How to choose between them:

• Pick Ubuntu LTS if you want a predictable two year LTS cadence, five years of standard maintenance with a documented path to 10 or 15 years through Ubuntu Pro, ESM coverage for Universe packages, Livepatch, or certified FIPS and CIS tooling.
• Pick Debian stable if you prefer a volunteer run project with no commercial subscription layer, and three years of full support plus two years of LTS fits your upgrade rhythm.
• Pick neither interim Ubuntu nor Debian testing for production. Interim releases get nine months of updates. Debian's own FAQ says security fixes for testing can lag and recommends stable for servers.
• Never pick Kali for a production server. It is a rolling distribution with no fixed security window, and its own update guide accepts that a rolling update can occasionally break things.

Desktops and laptops

For a general purpose desktop, Ubuntu or one of its official flavours is the usual choice, and Debian stable works well for people who prefer it. If you are setting one up, our guide to installing Ubuntu alongside Windows or on a Mac covers it step by step, including disk encryption and Secure Boot.

Kali is not a desktop distribution. Kali's "Should I use Kali Linux?" page says it is "NOT a recommended distribution if you're unfamiliar with Linux or are looking for a general-purpose Linux desktop distribution for development, web design, gaming, etc." It warns that even experienced users will struggle to add packages from outside Kali's sources, and that "trying to install Steam on your Kali Linux desktop is an experiment that will not end well." Kali's own summary: if you want "a distro that you can use as a general purpose desktop installation, Kali Linux is probably not what you are looking for."

Authorised security testing, forensics and research

This is what Kali is for. Kali's documentation describes it as "an open-source, Debian-based Linux distribution which allows users to perform advanced penetration testing and security auditing," with "several hundred tools, configurations, and scripts" for tasks such as "computer forensics, reverse engineering, and vulnerability detection." Its tools are grouped into categories such as information gathering, vulnerability analysis, web application testing, password attacks, wireless testing, reverse engineering, exploitation frameworks, forensics and reporting.

Use Kali only on systems you own or have written permission to test. Kali's own page is direct about this: "misuse of security and penetration testing tools within a network, particularly without specific authorization, may cause irreparable damage and result in significant consequences, personal and/or legal." Before any engagement, agree scope and rules in writing; our guide on how to scope a penetration test and define rules of engagement covers what that agreement should contain.

Where to run it:

• In a virtual machine first. Kali's own advice: "If you are installing Kali Linux for the first time, it is recommended to install first in Virtual Machine." Kali publishes pre-built VMware and VirtualBox images with guest tools installed.
• On a dedicated machine or USB live boot for engagements that need hardware access, such as wireless testing. Kali publishes ISO files for Intel based PCs that run "Live" from USB, and ARM images for single board computers.
• On other platforms Kali lists: ARM, NetHunter for mobile, cloud images, Docker, Vagrant and WSL through the Microsoft Store.

Keep the testing box separate from your daily machine, because it will hold engagement data.

Decision table: which one should you use?

Which container base images exist for each?

Containers are where the three projects most often meet in an engineering team: an application image built on Ubuntu or Debian, and maybe a Kali image in a security team's toolbox.

Ubuntu. Canonical's release cycle page describes rocks: "minimal, optimized container images built from Debian packages," compatible with Docker and Kubernetes. Chiseled rocks go further "by removing shells, package managers, and other non-essential components." Ubuntu Minimal images are also available for major public clouds. An Ubuntu based image inherits the support window of its release, so an image built on 22.04 LTS gets standard security maintenance until May 2027. Our posts on the Ubuntu Docker image and on Alpine, distroless and Ubuntu base image trade-offs go further.

Debian. The debian.org pages we fetched do not describe official container images, so we will not make claims about them here. What does carry over is the life cycle: an image built on Debian 12 inherits Debian 12's end of life and LTS dates from the table above. See Alpine versus Debian base images and base image support dates for Debian, Ubuntu and Alpine side by side.

Kali. Kali's documentation says it provides official Docker images "updated once a week on Docker Hub." The main one is kalilinux/kali-rolling, which tracks kali-rolling. kalilinux/kali-last-release is built from kali-last-snapshot and "will not get any update until the next release." There are also bleeding-edge, experimental and dev images for special cases. None of them ship the default metapackage; Kali says you need to install kali-linux-headless yourself. A Kali image is a tool image for authorised testing, never a base for an application you ship.

The main difference in support windows: Ubuntu and Debian images are fixed releases with backported fixes and published end dates, so you can plan rebuilds against a calendar. A Kali image is a snapshot of a rolling distribution and is only current until the next weekly rebuild. Whatever the base, check the release your images are actually on; our guide on how to check if your base image operating system is end of life shows how.

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

Each step below uses commands from the official documentation linked in the sources.

Step 1: Identify the distribution and release

Every Debian family system has /etc/os-release. Kali's 2026.2 release post uses this check, and the same file exists on Ubuntu and Debian:

grep VERSION /etc/os-release

On Kali 2026.2, Kali's post shows VERSION="2026.2" and VERSION_CODENAME="kali-rolling". On Ubuntu and Debian the codename field shows the release codename instead.

Step 2: Check the running kernel

uname -r

Kali's 2026.2 post shows 6.19.14+kali-amd64 and notes "the output of uname -r may be different depending on the system architecture." Compare the result with the kernel your distribution currently ships; a machine that has installed a new kernel but not rebooted is still running the old one.

Step 3 (Ubuntu): Check Ubuntu Pro and ESM status

The Ubuntu Pro client tutorial uses:

pro status

On an unattached machine it lists services that are available, such as ESM and Livepatch. On an attached machine it shows which services you are entitled to and whether each is enabled. If ESM shows as enabled, the Pro client has added the ESM Infra and Apps sources described earlier.

Step 4 (Ubuntu): Make sure automatic updates are installed

The Ubuntu Server guide notes unattended-upgrades is installed by default, and gives the command if it is missing:

sudo apt install unattended-upgrades

Step 5 (Ubuntu): Upgrade to the next supported release

The Ubuntu Server upgrade guide says to fully update first, including phased updates that might block the upgrade:

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

Then run the release upgrader:

sudo do-release-upgrade

The guide is explicit about the rules: you "can only upgrade from one LTS release directly to the next sequential LTS release," you cannot skip releases, and LTS to LTS upgrades "are only available after the first point release." The 26.04 release notes add that from 22.04 LTS you must go to 24.04 LTS first before moving to 26.04 LTS.

Step 6 (Kali): Confirm you are on kali-rolling

Kali's update guide says to first check the sources file:

cat /etc/apt/sources.list.d/kali.sources

It should show Suites: kali-rolling and Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg. Kali's branches page notes that systems installed before Kali 2026.2 may instead have the one line entry in /etc/apt/sources.list.

Step 7 (Kali): Update to the latest Kali

sudo apt update
sudo apt full-upgrade -y

Kali's guide says these commands "will upgrade us to the latest Kali version." Then repeat steps 1 and 2 to confirm the version and kernel. Do this before an engagement, not during one.

Common mistakes

• Calling Kali "Ubuntu based." That was BackTrack 4 and 5. Kali has been Debian based since 1.0 and has tracked Debian testing since January 2016.
• Using Kali as a daily desktop. Kali's own docs advise against it. Your testing machine holds sensitive engagement data and should do nothing else.
• Running Kali tools against systems you have no written permission to test. Kali warns of "significant consequences, personal and/or legal." Get the scope in writing first.
• Adding PPAs or random repositories to Kali. Kali says there is "absolutely no support whatsoever" for PPAs, and that extra repositories risk breaking the install.
• Running Kali, Debian testing or an Ubuntu interim release in production. None of them gives you a long fixed security window. Use Debian stable or Ubuntu LTS.
• Assuming every Ubuntu package is covered for five years. Standard security maintenance covers Main. Universe needs ESM Apps through Ubuntu Pro.
• Reading an old looking version number as "vulnerable." Debian and Ubuntu backport fixes. Check the fixed version in the DSA or USN.
• Trusting a status label instead of a date. Debian's releases page still labels Debian 11 as under LTS support though its listed LTS end date has passed. Plan from dates.
• Skipping LTS releases when upgrading Ubuntu. You must go one LTS at a time, and only after the first point release.
• Leaving a Kali VM on kali-last-snapshot for months. That branch gets nothing until the next release.
• Assuming ufw is on. On Ubuntu it is available but disabled by default.

FAQ

Is Kali Linux based on Ubuntu?

No. Kali is based on Debian testing, according to Kali's policy page on its relationship with Debian. Its predecessor BackTrack used Ubuntu for versions 4 and 5, but Kali 1.0 in 2013 moved to Debian 7, and Kali has used Debian testing as the starting point for kali-rolling since January 2016.

Is Ubuntu based on Debian?

Yes. Ubuntu's governance page calls Debian "the rock on which Ubuntu is built." Until each cycle's Debian Import Freeze, new package versions are imported automatically from Debian unstable, and Ubuntu developers merge Debian changes into packages where Ubuntu carries its own patches.

What is the difference between Debian and Ubuntu?

Debian is a volunteer project that ships a stable release with three years of full support and two years of LTS. Ubuntu, led by Canonical, ships every six months, makes an LTS every two years with five years of standard security maintenance, and offers up to 15 years of coverage through Ubuntu Pro. Ubuntu also differs in defaults: root locked, ufw shipped but disabled, automatic security updates on, and snaps alongside debs.

Can I use Kali Linux as my main operating system?

Kali's documentation says it is not recommended as a general purpose desktop or for people new to Linux, and that adding software from outside Kali's own sources can break the system. Use Ubuntu or Debian as your main OS and run Kali in a virtual machine or on a dedicated machine for authorised testing.

Is Kali Linux safe to use?

Kali is built with care: a small trusted team, signed packages and repositories, network services blocked from persisting across reboots, and a non-root default user since 2020.1. The risk is in how it is used. Keep it updated on kali-rolling, keep it separate from daily work, and use its tools only on systems you are authorised to test.

Which is more secure, Debian or Ubuntu?

Neither is simply "more secure." Both backport fixes to fixed releases and publish advisories, DSAs for Debian and USNs for Ubuntu. Ubuntu documents more hardened defaults, such as AppArmor with user namespace restrictions, a No Open Ports policy, compiler hardening flags and automatic security updates, and offers longer support through Ubuntu Pro. Debian stable has a smaller commercial footprint and a well documented security process. Your patching discipline matters more than the choice.

Does Kali Linux get security updates?

Yes, through kali-rolling. Kali does not publish a fixed support period for a versioned release. Its update guide says to check for updates every few days or weeks, and users on kali-last-snapshot get nothing until the next release. Packages imported from Debian testing follow Debian's testing security process, which Debian says can lag behind unstable.

What is the latest version of Kali Linux?

The latest release listed on Kali's releases page on 23 October 2026 is Kali 2026.2, released on 29 June 2026, with kernel 6.19 and Xfce 4.20.7. Kali releases about four times a year, so check the releases page for anything newer.

Fix it without waiting for upstream

Whichever distribution you pick, the operating system is only part of what you run. A server on Ubuntu 20.04 without Ubuntu Pro no longer gets standard USNs, a Debian 11 host past its LTS date gets nothing from Debian, and the application dependencies inside a container are never fixed by the distribution at all.

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 chooses a distribution for you or patches a host kernel; those stay with Debian, Canonical and the Kali team. They show the step after, when you need to know what is inside the images and projects you build on Ubuntu or Debian, and to move vulnerable dependencies to fixed versions with a person approving each action.

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 applies to an application running on an Ubuntu LTS or Debian stable base: the distribution patches the OS packages, and this is how the application's own dependencies get to fixed versions.

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

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 a given Ubuntu or Debian base, for example with safeguard scan --image, produces an SBOM that shows which OS packages and versions the image actually contains, so you can see whether it is on a release that is still supported.

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 how you find every image still built on a base that has reached end of life. 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.

Quick check

Sources

• Kali Linux: Should I Use Kali Linux?
• Kali Linux: What is Kali Linux?
• Kali Linux: Kali's Relationship With Debian
• Kali Linux: Kali Linux History
• Kali Linux: Releases
• Kali Linux: Kali Branches
• Kali Linux: All about sudo
• Kali Linux: Updating Kali
• Kali Linux: Network Service Policy
• Kali Linux: Downloading Kali Linux
• Kali Linux: Official Kali Linux Docker Images
• Kali Linux: Kali Network Repositories
• Kali Linux blog: Kali Linux 2026.2 Release
• Debian: Debian Releases
• Debian: Security Information
• Debian: Security FAQ
• Debian Installation Guide: Using individual components (users and passwords)
• Ubuntu: Release cycle
• Ubuntu: Debian (community governance)
• Ubuntu: Security notices
• Ubuntu project documentation: Merges and syncs
• Ubuntu project documentation: Freezes (Debian Import Freeze)
• Ubuntu release notes: Ubuntu 26.04 LTS
• Ubuntu release notes: Ubuntu 26.04 LTS summary for LTS users
• Ubuntu security documentation: Overview of security features
• Ubuntu security documentation: AppArmor
• Ubuntu security documentation: Firewall
• Ubuntu security documentation: No open ports
• Ubuntu security documentation: Full disk encryption
• Ubuntu security documentation: Expanded Security Maintenance
• Ubuntu Server documentation: User management
• Ubuntu Server documentation: How to upgrade your Ubuntu release
• Ubuntu Server documentation: Automatic updates
• Ubuntu Pro client documentation: Basic commands

Last reviewed: 23 October 2026.