Kali 2.0 to 2019.4: The Move to Rolling Releases and to Xfce

Kali Linux 2.0 "sana" (11 August 2015, kernel 4.0, built on Debian 8 "Jessie") turned Kali into a rolling distribution, and Kali 2016.1 (21 January 2016, kernel 4.3, GNOME 3.18) was the first public kali-rolling release fed from Debian testing. The last release of the era, Kali 2019.4 (26 November 2019, kernel 5.3.9), replaced GNOME with Xfce 4.14.1 as the default desktop.

Kali is a distribution for authorised penetration testing, forensics and security research. Use it only on systems you own or have written permission to test. This post covers the five years between the first rolling Kali and the last release before the non-root default user arrived: every release's date, kernel and desktop, what changed from the release before, how the branch model works, and what a rolling operating system means for a security team that has to keep a testing workstation trustworthy. Every fact comes from kali.org (the releases page, the 2015 to 2019 release posts and the Kali documentation), fetched on 23 October 2026. Where those pages say nothing, or disagree with each other, we say so.

Key takeaways

• 2.0 made Kali rolling; 2016.1 made kali-rolling public. Until 2016.1, rolling was only open to "a select brave group" who upgraded from 2.0 by hand. Kali's branches page dates the Debian testing base for kali-rolling to January 2016.
• The 2.0 repository is gone. The "sana" repositories reached end of life on 15 April 2016 and were purged later that year.
• There is one supported line. You stay current on kali-rolling, or use kali-last-snapshot and get updates only at each versioned release.
• Kernels went from 4.0 to 5.3.9. Kali 2018.2 was the first Kali on Linux 4.15, which carried the x86 and x64 fixes for Spectre and Meltdown.
• GNOME was the default from 2.0 to 2019.3; Xfce from 2019.4.
• Root was the default user throughout. The non-root default was announced on 31 December 2019 and shipped in 2020.1.
• Authorised use only. Kali says it is not a recommended distribution for a general purpose desktop.

Kali 2.0 "sana": the release that made Kali rolling

Kali's releases page lists Kali 2.0 on 11 August 2015 as a major release, "now a rolling distribution, major UI changes." The release post, published the same day, calls it the most significant Kali release since the project began in 2013.

What shipped in Kali 2.0

According to the 2.0 release post, the release brought:

• A 4.0 kernel, based on Debian Jessie. Kali's history page lists "Kali Linux v2 (Sana)" with Debian 8 (Jessie) as its base OS.
• GNOME 3 as the default desktop, after what the post calls a long period of avoiding it. The post gives the minimum RAM for a full GNOME 3 session as 768 MB. It does not state an exact GNOME version, and neither does the releases page.
• Native support for other desktops through Kali's live build process: KDE, GNOME 3, Xfce, MATE, e17, LXDE and i3wm.
• A "light" ISO with a small set of tools and the Xfce desktop, aimed at computers with limited resources.
• Updated ARM images for boards such as Raspberry Pi, Chromebooks and Odroids, now with kernel sources included so users could compile drivers.
• NetHunter 2.0, Kali's mobile testing platform, rebuilt on Kali 2.0 for several Nexus devices and the OnePlus One.
• New VMware and VirtualBox images, published by OffSec in 32 bit and 64 bit GNOME 3 builds.

"Now a rolling distribution": what that meant in 2015

The 2.0 post describes the rolling model in one sentence: Kali pulls packages continuously from Debian testing, after making sure they are installable. It also introduced an upstream version checking system that ran daily against a list of common tools and alerted the Kali team when a new upstream version was tagged. Tool updates would arrive faster, and Kali said it would phase out the "tool upgrades" category in its bug tracker.

There is a subtlety here that matters if you ever meet a 2015 era system. The 2.0 post's upgrade instructions point a Kali 1.x machine at a repository called sana and a separate security repository, sana/updates, on security.kali.org. That is the shape of a fixed release with a security pocket, not of the rolling branch most people know today. The 2016.1 post confirms the split: Kali switched to a rolling release model at 2.0, but the rolling branch itself was only reachable by upgrading from 2.0 to kali-rolling, and only a small group did that during the following five months of testing. Kali's branches page dates Debian testing as the starting point for kali-rolling to January 2016.

So the accurate summary is: 2.0 announced and built the rolling process on a Debian Jessie base; 2016.1 made kali-rolling on Debian testing the public default.

Packaging changes in 2.0

At its vendor's request, the commercial editions of a well known exploitation framework were removed, leaving the open source package, which Kali moved to its own shared system libraries. That pattern runs through the era: Kali tools are Debian style packages, so updating the operating system updates the libraries they use.

Kali 2016.1: the first kali-rolling release

Kali 2016.1 shipped on 21 January 2016. The releases page describes it as the first Kali Rolling release, with kernel 4.3 and GNOME 3.18.

What kali-rolling means

The 2016.1 post explains the model by contrast. A standard distribution release goes through a cycle of being new, then mainstream, then outdated, and is tied to a numbered Debian release such as Debian 7, 8 or 9. Kali Rolling instead feeds continuously from Debian testing, giving a constant flow of current package versions. On top of that, the post says monitored tools typically reached kali-rolling 24 to 48 hours after a new upstream release. It also introduced the Kali Package Tracker, which shows which version of each package is in each Kali repository: the official place to check what Kali ships.

The Debian testing base

Kali's policy page on its relationship with Debian says Kali is "based on Debian Testing", that most packages are imported as is from Debian, and that newer packages are sometimes taken from Debian unstable or experimental to fix bugs or improve the experience. The branches page sets out how that works in practice. Debian testing is mirrored into Kali's build system, combined with Kali specific packages into kali-dev, and then copied into kali-rolling by a tool that only promotes packages once it has verified they can be installed. The page is direct about the limit of that check: it does not include functional testing, so broken software can still reach kali-rolling.

How often images are cut

Kali did not promise a fixed cadence in this era, and the release counts show it. The releases page lists two versioned releases in 2016 (2016.1 and 2016.2), three in 2017, four in 2018 and four in 2019 plus the 2019.1a fix release. Today Kali's update guide says it releases four times a year on a loose quarterly schedule, but that describes the 2020s; between 2016 and 2017 the gaps were up to seven months.

Two things made the gap matter less. From 2016.2 Kali published weekly ISOs, which the 2019.4 post notes are automated builds without the QA of versioned releases. And every post tells existing users simply to run a full upgrade: a versioned release is a snapshot of kali-rolling with images built from it, not a separate distribution.

The end of Kali 2.0 "sana"

The 2016.1 post gave migration steps from sana to kali-rolling (point APT at kali-rolling and run a full upgrade) and announced that the sana repositories would stop receiving updates and reach end of life on 15 April 2016. The 2016.2 post, in August 2016, says the grace period was over, the sana repositories had been purged from Kali's servers, and they remained available as an archive at old.kali.org. An archive is not a supported source of security fixes.

Every Kali release from 2.0 to 2019.4

The table lists every release on Kali's releases page from 2.0 to 2019.4. Dates, kernels and desktop versions are as the releases page states them; where the release post gives a more precise kernel or a different date, the next section notes it. The base column follows Kali's history and branches pages.

"Not stated" means the releases page gives no kernel or desktop version for 2019.1a, and we could not find a release post for it on kali.org. The releases page describes it only as a bug fix for the VMware installer.

Where Kali's own pages disagree

• 2.0 codename. The releases page says "safi". The release post (subtitled "Sana"), its sana repository, the 2016 posts and the history page all say sana. We use "sana", the name the repository itself used.
• 2016.1 date. The releases page and the release post say 21 January 2016. Kali's history page lists "Kali Linux Rolling" as 16 January 2016. We use 21 January, the date of the release post.
• 2018.3 date. The releases page says 27 August 2018; the release post is dated 21 August 2018. We use the releases page in the table and note the post date here.
• Kernel precision. The releases page rounds some kernels that the posts state exactly: 4.13 versus 4.13.10 (2017.3), 4.17 versus 4.17.0 (2018.3) and 4.18 versus 4.18.10 (2018.4). These are the same kernels described at different precision, not a conflict.
• GNOME 3.25 in 2017.2. The releases page lists GNOME 3.25 for 2017.2. The 2017.2 post does not mention a GNOME version, so we report the releases page value as written.

What changed from release to release

This is the "what changed versus the previous release" view. Each row lists the change that most affects how Kali behaves or how you maintain it, from that release's post.

Release by release, 2016.2 to 2019.3

2016 and 2017: weekly images and the cost of not updating

The security relevant change in 2016.2 is the weekly build. The post explains that a few hundred packages had changed since 2016.1, so even a three month old ISO started far behind; weekly images narrowed that gap for new installs. Kali 2017.1 noted that its repositories now supported HTTPS and an HTTPS APT transport, and packaged the OpenVAS 9 vulnerability scanner without installing it by default.

Kali 2017.2 is worth reading for one example. The post shows what an install from the 2017.1 ISO faced five months later: 1,399 packages to upgrade, 171 new packages and 1,477 MB to download. That is the clearest official illustration of how quickly a rolling system drifts.

2018: kernels, CPU side channels and an expired key

• 2018.1 shipped kernel 4.14.12 and said the Meltdown and Spectre patches would arrive in 4.15. It warned that long unupdated systems would see an APT error about an expired repository key, ID ED444FF07D8D0BF6. For today's archive key and how to check it, see our Kali quarterly releases post.
• 2018.2 was the first Kali on Linux 4.15, with the x86 and x64 fixes for Spectre and Meltdown, plus AMD Secure Encrypted Virtualization support.
• 2018.3 moved to 4.17.0, picking up further Spectre and Meltdown fixes from 4.16, and began showing how to confirm the version in /etc/os-release after upgrading.

On a rolling system those fixes reached users through ordinary kernel updates, but only once they rebooted. A laptop that was updated but not rebooted still ran the old kernel.

2019: infrastructure, testing and a smaller default

Kali's roadmap post of 19 June 2019 moved its package repositories to GitLab and deployed debci at autopkgtest.kali.org for automated runtime tests of packages, while admitting that tests for every package were a long way off. Kali 2019.3 then delivered:

• A CDN mirror, visible as the kali.download domain during apt update, alongside the standard mirrors, and status.kali.org to show whether mirrors respond.
• New metapackages. The "Major Metapackage Makeover" post renamed the old default kali-linux-full to kali-linux-large and introduced a slimmer kali-linux-default. Existing installs kept their tools; fresh installs got the smaller set.
• A quieter GNOME, which no longer refreshed package lists in the background.

A smaller default is a security property: fewer installed packages means fewer to track and patch.

Kali 2019.4: Xfce, Kali Undercover and the rest

Kali 2019.4 was released on 26 November 2019 with kernel 5.3.9 and Xfce 4.14.1. It was the last release of the root by default era.

Why Kali moved from GNOME to Xfce

The 2019.4 post gives three reasons: performance ("Gnome has been overkill for most Kali users", who mostly want terminals and a browser), one consistent interface from high end laptops to Raspberry Pi boards instead of a separate low end ARM interface, and a fresh look after the old theme's maintainer moved on. A new GTK3 theme covered both Xfce and GNOME.

GNOME did not go away. The post says Kali kept a GNOME build, and Kali's Xfce FAQ explains how to get a GNOME image from the download page or by installing the kali-desktop-gnome package.

Switching an existing install to Xfce

Upgrading a GNOME install to 2019.4 did not change its desktop. Kali's Xfce FAQ gives the steps to migrate without reinstalling:

sudo apt update && sudo apt install -y kali-desktop-xfce
update-alternatives --config x-session-manager

When asked for the default display manager, the FAQ says to choose lightdm, then select Xfce in the session manager prompt. The FAQ advises against removing the GNOME packages until you are sure you are ready.

Kali Undercover

Kali Undercover is a set of scripts that switches the Kali desktop theme to one that resembles Windows 10, and back again. Kali's documentation says it was released with 2019.4 to "hide in plain sight": its stated purpose is to stop the distinctive Kali desktop drawing attention while a tester works on an authorised engagement in a client's office or another public place. It changes only the look of the desktop. It does not change what the system does on the network.

Documentation, public packaging and BTRFS

Kali moved its documentation to Markdown in a public Git repository open to merge requests, documented how outside contributors can package a tool for Kali, and documented a BTRFS root setup that allows rollbacks after upgrades on bare metal, not yet in the installer.

PowerShell, NetHunter KeX and ARM

PowerShell became available in Kali. NetHunter KeX lets a supported Android phone drive a full Kali desktop over HDMI with a Bluetooth keyboard and mouse. On ARM, 2019.4 was the last release to support 8 GB SD cards; from 2020.1 the minimum became 16 GB.

What came next

Five weeks later, on 31 December 2019, Kali published "Kali Default Non-Root User", announcing a move to a "traditional default non-root user" model in 2020.1. Live images would run as user kali, and installs would prompt for a non-root user in the sudo group. The change appeared in weekly images straight away. Our Kali quarterly releases post picks up the story from 2020.1.

The security model in this era

Root by default

Kali's root user policy, now marked as dated, says that because many tools needed root and multi-user use was unlikely, the default user was root and no non-privileged account was created at install. The December 2019 post traces this to BackTrack, a live CD with no real update mechanism, and explains that by 2019 fewer tools needed root and more applications refused to run as root. Any install from 2.0 to 2019.4 that was never reconfigured works as root.

Network services off by default

Kali's network service policy says Kali enables no externally listening service by default and stops network services persisting across reboots, using an allowlist and blocklist that includes SSH, Apache, Bluetooth and CUPS. The page does not say when the policy started, so we do not date it.

A small, signed set of repositories

Kali's "Should I use Kali Linux?" page says packages are signed by both the individual committer and the team, that the upstream repository set is kept very small, and that PPAs and apt-add-repository are not supported. For why archive keys matter, see our explainer on Linux distribution package signing.

No long term security support for a fixed release

Sana had its own security repository. After April 2016 there is only kali-rolling, where the 2017.2 post says security updates "come to us via Debian Testing" with everything else. The only supported Kali is a current one.

Kali branches, and which one to use

Kali's branches page describes the branches that exist today. They grew out of the 2016 rolling model.

The page says you should use either kali-rolling or kali-last-snapshot, not both, and that the partial branches cannot be used on their own because they do not contain a full distribution. It maps Debian's options to Kali's: Debian stable is the equivalent of kali-last-snapshot, Debian testing is what kali-rolling has been built from since January 2016, and Debian unstable has no Kali equivalent.

How to choose:

• Default to kali-rolling. It gets fixes as soon as they pass Kali's installability check.
• Use kali-last-snapshot for reproducibility. If a team needs every tester on the same package set for the length of an engagement, last snapshot gives that, at the cost of waiting up to a quarter for fixes. Kali's update guide says users on last snapshot receive no updates until the next versioned release.
• Do not leave the partial branches enabled by accident. They pull newer, less tested packages into a working system.

Kali's APT sources page gives the command to switch a modern install to last snapshot:

sudo sed -i 's/^Suites: .*/Suites: kali-last-snapshot/' /etc/apt/sources.list.d/kali.sources

Run sudo apt update afterwards. The same page covers switching back.

What a rolling OS means for a testing workstation

Keep it current, but not mid engagement. Kali's update guide says to check for updates every few days or weeks, and not to update during an engagement because "once in a while issues will sneak into rolling" and may break a tool you need.

Assume an old image is far behind. An ISO, VM or container image built months ago is not current until fully upgraded. Weekly images help but are not QA tested like versioned releases.

Reboot after kernel updates. The 2018 releases show that kernel fixes only protect you once you boot the new kernel.

Snapshot before you upgrade. The 2019.4 post recommends VM snapshots and documents BTRFS for rollback on bare metal.

Do not run it as a general server. Kali documents no long term supported release. Our Ubuntu vs Kali vs Debian comparison covers what to use instead.

Retire, do not resurrect, 2015 to 2019 systems. A machine pointing at sana gets nothing, and one idle since 2019 faces years of transitions. The 2.0 post itself said a muddled upgrade is better replaced by a fresh install. Use a current, verified image.

Image types in this era

The release posts describe the image types Kali offered between 2015 and 2019:

The posts do not date Kali's first x86 WSL release; 2019.3 only says ARM64 support was added.

Authorised use only, and tools by category

Kali is a distribution for authorised security testing, forensics and research. Kali's "Should I use Kali Linux?" page says it is geared towards professional penetration testers and security specialists, and is not a recommended distribution for people new to Linux or looking for a general purpose desktop. The same page warns that misusing security testing tools on a network without specific authorisation can cause irreparable damage and serious personal or legal consequences, and that not understanding what you were doing is no excuse.

Use Kali only on systems you own or have written permission to test, and agree scope and rules before any engagement. Our guides on what penetration testing is and how to scope a penetration test and define rules of engagement cover what that agreement should contain.

Kali groups its tools into categories, and since 2019.3 it publishes them as metapackages named after those categories. Kali's metapackages page lists categories including information gathering, vulnerability analysis, web application testing, database assessment, password attacks, wireless (802.11, Bluetooth, RFID and SDR), sniffing and spoofing, exploitation, post exploitation, reverse engineering, forensics, fuzzing, hardware, crypto and stego, social engineering, VoIP and reporting. We do not describe how to use any of them.

How to check which Kali release you are on and bring it up to date

All commands below come from Kali's release posts and documentation, cited at each step. Do this between engagements, not during one.

Step 1: Check the Kali version

From the 2018.3 to 2019.4 release posts:

grep VERSION /etc/os-release

From 2019.3 onwards the posts show VERSION_CODENAME="kali-rolling" in the output, alongside VERSION and VERSION_ID. If VERSION shows a year from 2015 to 2019 on a machine you still use, it has not been upgraded in years.

Step 2: Check the running kernel

The 2019.3 and 2019.4 posts use:

uname -r
uname -v

Compare the result with the table above and with the current release. Kali notes that uname -r output varies by architecture.

Step 3: Confirm you are on kali-rolling

Kali's update guide says to check the APT sources first. On installs from 2026.2 onward:

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

Expect Suites: kali-rolling and Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg. Kali's APT sources page says older installs keep the one line format instead, and gives this check:

grep -v '^#' /etc/apt/sources.list | sort -u

That should return a single deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware line. If you see sana, the system dates from 2015 and its repository no longer exists. If you see kali-last-snapshot, you are on the frozen branch.

Step 4: Update to the latest Kali

From Kali's update guide:

sudo apt update
sudo apt full-upgrade -y

Kali says these commands upgrade you to the latest Kali version. If apt update reports a missing or expired archive key, do not work around it by disabling signature checks; follow the archive key steps in our Kali quarterly releases post, or reinstall from a current verified image.

Step 5: Reboot if the kernel changed

The 2019.3 and 2019.4 posts, which ran as root, check for the reboot flag like this:

[ -f /var/run/reboot-required ] && reboot -f

On a current install, prefix reboot with sudo. The -f flag skips a clean shutdown, so save your work first or reboot normally. Then repeat steps 1 and 2.

Step 6: Verify any new image before you use it

Kali's download documentation says to verify every image and not to use one you cannot verify. The strongest method checks the signed checksum file against Kali's key:

wget -q -O - https://archive.kali.org/archive-key.asc | gpg --import
gpg --verify SHA256SUMS.gpg SHA256SUMS
grep kali-linux-2026.2-live-amd64.iso SHA256SUMS | shasum -a 256 -c

Replace the file name with your image, and download only from kali.org/get-kali.

Common mistakes

• Treating Kali 2.0 as supported. Its repositories reached end of life on 15 April 2016.
• Assuming "rolling" means "always current". A rolling system is only as current as its last full upgrade.
• Updating mid engagement. Kali's update guide says not to.
• Upgrading without rebooting. Kernel fixes apply only after you boot the new kernel.
• Leaving kali-bleeding-edge or kali-experimental enabled. They are partial branches for special cases.
• Adding PPAs or third party repositories. Kali says these commonly break an install.
• Keeping an old root by default install in service. Reinstall from a current image, which uses a non-root user.
• Using an image you have not verified. Kali's download docs say not to.

FAQ

When was Kali 2.0 released?

On 11 August 2015, with a 4.0 kernel, a Debian 8 Jessie base and GNOME 3 as the default desktop.

What is the codename of Kali 2.0?

"sana", per the release post, the repository name, the 2016 posts and Kali's history page. Kali's releases page currently shows "safi."

When did Kali become a rolling release?

Kali 2.0 announced the rolling model in August 2015. Kali 2016.1, on 21 January 2016, was the first public kali-rolling release.

Is Kali based on Debian testing or Debian stable?

Debian testing, per Kali's policy and branches pages. Kali 1.x used Debian 7 Wheezy and Kali 2.0 used Debian 8 Jessie.

What kernel did Kali 2019.4 use?

Kernel 5.3.9. The post's example shows 5.3.0-kali2-amd64 from uname -r.

When did Kali switch from GNOME to Xfce?

In Kali 2019.4, released on 26 November 2019, with Xfce 4.14.1. GNOME remained available.

What is the difference between kali-rolling and kali-last-snapshot?

kali-rolling updates continuously. kali-last-snapshot is frozen at each versioned release and changes only at the next one.

Is Kali 2.0 or Kali 2016.1 still supported?

No. Only a current kali-rolling install, or kali-last-snapshot at the latest release, is supported.

What is Kali Undercover?

A 2019.4 script that switches the desktop theme to resemble Windows 10 and back, so a tester on an authorised engagement does not draw attention in public. It changes only appearance.

Did Kali run as root by default before 2020?

Yes. Kali's dated root user policy says so. The non-root default user shipped in Kali 2020.1.

Fix it without waiting for upstream

A rolling Kali install is only as safe as its last full upgrade, and the same is true of the scripts, reporting tools and container images a testing team builds on top of it. When an application dependency in that code has a known vulnerability, you do not have to wait for anyone else's release cycle to fix it.

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 updates Kali or chooses a kernel for you; that stays with the Kali team and Debian. They cover the step around it: knowing what is inside the projects and images your team builds, and moving 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 the in house scripts and reporting tools a testing team maintains alongside Kali: an outdated dependency becomes a reviewed change rather than a note in a backlog.

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. If your team builds lab or CI images on top of a Kali container image, scanning the built image (for example with safeguard scan --image) produces an SBOM listing the packages and versions inside it. That shows how far a snapshot has drifted since it was built, which is exactly the drift the 2017.2 post illustrates.

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, the question you face when a release changes a library underneath you. Our post on using SBOMs to find affected products fast works through that 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: Release History
• Kali Linux blog: Kali Linux 2.0 Release (11 August 2015)
• Kali Linux blog: Kali Linux 2016.1 Release, Rolling Edition
• Kali Linux blog: Kali Linux 2016.2 Release
• Kali Linux blog: Kali Linux 2017.1 Release
• Kali Linux blog: Kali Linux 2017.2 Release
• Kali Linux blog: Kali Linux 2017.3 Release
• Kali Linux blog: Kali Linux 2018.1 Release
• Kali Linux blog: Kali Linux 2018.2 Release
• Kali Linux blog: Kali Linux 2018.3 Release
• Kali Linux blog: Kali Linux 2018.4 Release
• Kali Linux blog: Kali Linux 2019.1 Release
• Kali Linux blog: Kali Linux 2019.2 Release
• Kali Linux blog: Kali Linux Roadmap (2019/2020)
• Kali Linux blog: Major Metapackage Makeover (22 August 2019)
• Kali Linux blog: Kali Linux 2019.3 Release
• Kali Linux blog: Kali Linux 2019.4 Release
• Kali Linux blog: Kali Default Non-Root User (31 December 2019)
• Kali Linux docs: Kali Linux History
• Kali Linux docs: Kali Branches
• Kali Linux docs: Kali Network Repositories
• Kali Linux docs: Updating Kali
• Kali Linux docs: Kali's Relationship With Debian
• Kali Linux docs: Kali Linux Xfce FAQ
• Kali Linux docs: Kali Undercover
• Kali Linux docs: Metapackages
• Kali Linux docs: Kali Linux Root User Policy (dated)
• Kali Linux docs: Kali Linux User Policy
• Kali Linux docs: Network Service Policy
• Kali Linux docs: Should I Use Kali Linux?
• Kali Linux docs: Downloading Kali Linux

Last reviewed: 23 October 2026.