From Whoppix and BackTrack to Kali 1.0: Kali Linux History, 2004 to 2015

Kali Linux descends from Whoppix (30 August 2004, built on Knoppix), WHAX (17 July 2005, on Slax) and BackTrack (26 May 2006 to 2013, on Slackware and then Ubuntu). Kali Linux 1.0 "moto" replaced BackTrack on 13 March 2013, rebuilt from scratch on Debian 7 "Wheezy", and the 1.x line ran through Kali 1.1.0a on 13 March 2015.

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 walks through the whole family tree, every 1.x release with what it changed, the security model of the time, and why the move from Ubuntu to Debian mattered. Every fact comes from kali.org, the official BackTrack site, the official Kali image archive at old.kali.org and archived official pages, all fetched on 23 October 2026. Where those pages are silent or disagree, we say so.

Key takeaways

• Four projects came before Kali. Whoppix (WhiteHat Knoppix), WHAX (WhiteHat Slax), the Auditor Security Collection, and BackTrack, formed when Auditor and WHAX merged in May 2006.
• BackTrack changed its base twice. Versions 1 to 3 used Slackware Live CD; Kali's history table puts BackTrack 4 on Ubuntu 8.10 and BackTrack 5 on Ubuntu 10.04 LTS. One Kali post remembers BackTrack 4 differently.
• Kali 1.0 was a rebuild, not BackTrack 6. The team chose to "start afresh" to follow Debian policy and the Filesystem Hierarchy Standard, and picked Debian over Ubuntu.
• The 1.x line was 13 releases over two years, from 1.0.0 (13 March 2013) to 1.1.0a (13 March 2015), adding encrypted LVM install fixes, the LUKS nuke option, encrypted USB persistence, EFI boot and a Shellshock and apt security rebuild.
• Root was the default user throughout. Kali's dated root user policy says no unprivileged account was created at install. That changed only in Kali 2020.1.
• Kali 2.0 (11 August 2015) ended the era, moving to Debian 8 "Jessie", a 4.0 kernel and a rolling model.
• Authorised use only. Kali says it is not a general purpose desktop, and misusing its tools without authorisation has legal consequences.

The family tree at a glance

Kali's "Kali Linux History" page gives a table of major releases. The official BackTrack site, which still resolves at backtrack-linux.org, adds kernel versions and short notes for each BackTrack release. The table below merges the two and marks where a fact comes from only one of them.

Kali's history page notes that its table covers "only the major releases" and that there were minor ones for bug fixes and tool updates.

What the official archive still holds

Kali's image archive at old.kali.org still has whoppix-images, whax-images, backtrack-images and kali-images directories. The WHAX 3.0 ISOs there are dated 17 July 2005, matching Kali's history table. These are a historical record, not something to install: every image is long out of support.

Whoppix and WHAX: the live CD years

Kali's history page describes Whoppix as the first project and explains the name: WhiteHat Knoppix. Knoppix was a live CD distribution, so Whoppix booted a full toolkit from a disc without installing anything. Kali's page says Whoppix had releases from v2.0 to v2.7.

The next project, WHAX, changed its base from Knoppix to Slax, and the name changed with it to WhiteHat Slax. Kali's page says WHAX "started at v3" to show it carried on from Whoppix.

At the same time, a separate project called the Auditor Security Collection, also built on Knoppix, was doing similar work. Kali's history page says the two efforts "were combined" to produce BackTrack. The BackTrack site dates that merger to 26 May 2006.

Kali's 2019 post on dropping the default root user describes original BackTrack as a live distribution "intended to be ran from a CDROM," with "no real update mechanism." A disc that boots, runs tools and is never updated is a very different security proposition from an installed system, and the design choices of the time follow from that.

BackTrack 1 to 3: Slackware live CDs

BackTrack 1, 2 and 3 were built on Slackware Live CD 10.2.0, 11.0.0 and 12.0.0 respectively, according to Kali's history table. The BackTrack site lists:

• BackTrack 1 (26 May 2006): the merger release, with live CD and live USB capability.
• BackTrack 2 (6 March 2007): kernel 2.6.20, a redesigned menu structure, and support for both Metasploit 2 and Metasploit 3.
• BackTrack 3 (19 June 2008): kernel 2.6.21.5, with additional tools added.

The default desktop for these releases is not stated on the official pages we fetched. The base systems, kernels and dates are.

In this period the toolkit lived under /pentest/, grouped by task. Kali's 1.0 post later dropped that tree because it raised placement questions "which could never be satisfactorily answered."

BackTrack 4 and 5: the Ubuntu years

BackTrack 4 "Pwnsauce" (9 January 2010)

Kali's history page lists BackTrack 4 as based on Ubuntu 8.10 "Intrepid Ibex." The BackTrack site gives kernel 2.6.34, "massively improved hardware support" and official Fluxbox support, but does not state the base system for BackTrack 4.

BackTrack 5 "Revolution" (10 May 2011)

BackTrack 5 moved to Ubuntu 10.04 "Lucid Lynx," a long term support release. The BackTrack site says "Based on Ubuntu Lucid LTS" and gives kernel 2.6.38. Three revisions followed, and their archived announcements on backtrack-linux.org are still available through the Wayback Machine:

• BackTrack 5 R1 (18 August 2011): "over 120 bug fixes, 30 new tools and 70 tool updates," with the kernel updated to 2.6.39.4 including wireless injection patches. GNOME and KDE ISOs shipped for 32 bit and 64 bit, plus a 32 bit GNOME VMware image. The post notes there was no ARM image for that release.
• BackTrack 5 R2 (1 March 2012): a "custom-built 3.2.6 kernel" and 42 new tools.
• BackTrack 5 R3 (13 August 2012): bug fixes, over 60 new tools and a whole new tool category, which BackTrack named Physical Exploitation. GNOME and KDE ISOs again shipped for 32 and 64 bit, with one GNOME 32 bit VMware image.

R3 was the last BackTrack release. On the BackTrack site's timeline, the next entry is 13 March 2013: "BackTrack Linux becomes Kali Linux" and "Support for BackTrack Linux ends."

Why BackTrack moved to Ubuntu

Kali's 2019 non-root post says people had started installing BackTrack on bare metal, so the team "felt like there should be an update mechanism," a view reinforced by seeing many DEF CON attendees running a BackTrack version with a known vulnerability. An Ubuntu base meant updates through apt. The same post is blunt about how that went: "we were so busy fighting with Ubuntu" that a new base was needed.

A disagreement in the official record

Kali's own pages do not agree on exactly when BackTrack left Slackware.

• Kali's history page and the BackTrack site say BackTrack 1 to 3 were Slackware based, and Kali's history page says BackTrack 4 (January 2010) was based on Ubuntu 8.10.
• Kali's 2019 non-root post says "BackTrack (v1-4) was a Slackware live based distro" and dates the move to Ubuntu to BackTrack 5, "February 2011."

The BackTrack site does not state BackTrack 4's base. We use the history page in our tables because it is Kali's dedicated reference page. The post's February 2011 also does not match the 10 May 2011 release date that both the history page and the BackTrack site give for BackTrack 5.

Why Kali 1.0 was built on Debian

Starting over instead of shipping BackTrack 6

Kali's 1.0 release post, published on 13 March 2013 and titled "The Birth of Kali Linux," explains the decision. When the team began talking about BackTrack 6, each developer wrote down wish list goals. With a "4 year old development architecture," the post says, those goals were not reachable without a massive restructure. The team concluded it would be easier to start afresh than "to patch up our existing environment to conform to Debian policies" and the Filesystem Hierarchy Standard.

The post also explains the name. Kali is "simply the name we came up with," chosen because "BackTrack 6" did not convey how much had changed.

Debian over Ubuntu

The 1.0 post says Debian and Ubuntu were "the main players on our table," and "Debian was our final choice," without listing reasons.

The longer explanation is in "Kali Linux Revealed," the official Kali book, whose history chapter Kali's history page links on the Wayback Machine. It says the project "began quietly in 2012" to replace BackTrack, which was "manually maintained," with "a genuine Debian derivative," and gives Debian's quality, stability and wide software selection as the reasons.

Kali's current policy page on its relationship with Debian says most Kali packages are imported "as-is" from Debian, forks are kept to a minimum, and Kali packaging "strives to comply with the Debian Policy."

Why Debian stable, and a timing detail

Kali's history page says Kali "started off using Debian stable as the engine under the hood before moving to Debian testing when Kali became a rolling OS." The Kali book says 1.0 was based on Debian 7 "Wheezy," "Debian's stable distribution at the time."

There is a timing detail worth knowing. Debian's own Wheezy release page says Debian 7.0 was "initially released on May 4th, 2013." Kali 1.0 shipped on 13 March 2013, seven weeks earlier, so Wheezy was not yet Debian's released stable distribution on Kali's launch day. Kali's pages do not discuss this.

The Kali book also explains why the stable base did not last. Keeping the latest testing tools on Debian stable "required us to backport many packages," because stable deliberately lags upstream releases. The move to Debian testing, and to Kali Rolling, followed from that.

The launch

Kali's press release, dated 13 March 2013 at Black Hat Europe in Amsterdam, introduced Kali as "the evolution of its popular BackTrack Linux," free of charge, with "more than 300 penetration testing and security auditing programs" and new ARM support. Five days later, Kali's "Release Aftermath" post reported "just over 90,000 downloads" and the first bug fix release, 1.0.1.

Every Kali 1.x release, 2013 to 2015

Kali's releases page lists every version. Kernel numbers appear only for some releases; where neither the releases page nor the release post gives one, the table says so. Kali's history page and the Kali book both describe the 1.x desktop. The book says Kali 1.x "avoided the GNOME Shell (relying on GNOME Fallback instead)," and Kali 2.0's post says the move to GNOME 3 in 2.0 marked "the end of a long abstinence period." So GNOME in fallback mode was the default desktop for the whole 1.x line.

The Debian 7 base for each 1.x release follows from Kali's history table, which lists Kali v1 on Debian 7, and Kali 2.0's post, which describes 2.0 as "now based on Debian Jessie." Individual 1.x release posts do not restate the base.

What changed from release to release

This is the "what changed versus the previous release" view. Each row lists only what the release post or releases page says was new.

Kali has no individual blog post for 1.0.2 or 1.1.0a; their URLs following the usual pattern returned 404, and the releases page is the only official source. Kali's image archive also has no kali-1.0.1 folder: it goes from kali-1.0.0 to kali-1.0.2.

Kali 1.0.0 to 1.0.4: settling in

The first months were about stability, accessibility and tools. For 1.0.3, two blind security practitioners told the team Kali had no built in accessibility. The team found bugs in Debian's GDM3 display manager that blocked accessibility features, worked with a GNOME developer to fix them upstream, and added a speech assisted install option. Kali 1.0.4, timed for Black Hat and DEF CON in July 2013, was mostly new and updated tools across web application testing, password attacks, wireless testing, forensics and vulnerability analysis, plus three more ARM boards.

Kali 1.0.5: encrypted LVM installs and software defined radio

The 1.0.5 post says the release included "our fix for the encrypted LVM installation issue," which the releases page summarises as "LVM Encrypted installs." So 1.0.5 fixed an existing encrypted install path rather than introducing it. The release also added software defined radio tools and drivers, updated NFC card tools and reached nine ARM device families.

Kali 1.0.6: kernel 3.12 and the LUKS nuke option

The 1.0.6 post (9 January 2014) lists a 3.12 kernel, a LUKS nuke feature, ARM build scripts and "Kali AMAZON AMI and Google Compute image generation scripts." The post describes scripts for building your own cloud images, while the releases page headline says "Amazon AMI."

The nuke option is a defensive feature for people who carry client data. A patch to cryptsetup lets a separate "nuke" passphrase, entered at boot, wipe the LUKS key slots, so nobody can decrypt the disk, including the owner, until a separately kept header backup is restored. Kali's follow up post says the aim was to simplify travelling "with confidential client information," and the release post says the patch "will not change anything for anyone that does not want to make use of it." Without a tested header backup, a nuked disk is gone for good, so we do not reproduce the commands; read Kali's documentation and test the restore first.

The same release separated official Kali images from VMware and ARM images contributed by OffSec, and began adding Debian "watch files" to Kali packages so the team could track new upstream releases automatically, the start of the upstream checking that Kali 2.0 later ran daily.

Kali 1.0.7: encrypted USB persistence

Kali 1.0.7 (27 May 2014) shipped kernel 3.14, partly needed for the headline feature: a Live USB with "LUKS Encrypted Persistence," so you could boot a clean image or overlay it with an encrypted persistent partition on the same drive.

Kali 1.0.8: EFI boot

Kali 1.0.8 (22 July 2014) added USB EFI boot support to the ISO builds, which "prompted this early" release because newer hardware, including some Apple laptops, required EFI. The result was an "EFI Bootable ISO Hybrid image" with encrypted USB persistence and LUKS nuke support.

Kali 1.0.9: firmware fix and the tools site

Kali 1.0.9 (25 August 2014) fixed outdated firmware in the 1.0.8 ISOs and refreshed ARM and VMware images. It also launched the Kali Tools website, which lists each tool with a description, links, licence information and the contents of each Kali metapackage.

Kali 1.0.9a: the Shellshock and apt security rebuild

Kali 1.0.9a (6 October 2014) is the most security relevant release of the era. The post says that "a bunch of nasty bugs" had hit, "from shellshock to Debian apt vulnerabilities," and that "we prefer not to ship vulnerable ISOs." Kali rebuilt its installer images, its NetHunter images (version 1.0.2) and its Amazon images with the fixes. Existing installs only needed a normal update.

Kali's post does not list CVE numbers. Debian's security tracker, which covers Wheezy, the base Kali 1.x used, shows what those bugs were:

• Shellshock, CVE-2014-6271: GNU Bash processed trailing strings after function definitions in environment variables. Debian's tracker notes "the original fix for this issue was incorrect," and that CVE-2014-7169 covers what remained. For Wheezy, the tracker lists bash fixed in 4.2+dfsg-0.1+deb7u1 (DSA-3032-1) for the first issue and 4.2+dfsg-0.1+deb7u3 (DSA-3035-1) for the follow up.
• APT, CVE-2014-6273: a buffer overflow in the HTTP transport code in apt-get, fixed for Wheezy in apt 0.9.7.9+deb7u5 (DSA-3031-1).
• APT, CVE-2014-0488: APT did not invalidate repository data when moving from an unauthenticated to an authenticated state, fixed for Wheezy in apt 0.9.7.9+deb7u3 (DSA-3025-1).

Kali's post does not say which apt advisories it meant, so treat the APT pairing as our reading. The lesson still holds: rebuilding images after a base package fix is part of shipping the fix.

Kali 1.1.0 and 1.1.0a: the end of 1.x

Kali 1.1.0 (9 February 2015) was, in the post's words, "our first point release" after "almost two years of public development (and another year behind the scenes)." It shipped a 3.18 kernel "patched for wireless injection," moved the ISO build system to live-build 4.x, improved wireless driver support, added NVIDIA Optimus support and updated the virtual machine guest tool packages. Kali 1.1.0a (13 March 2015) quietly fixed kernel ABI inconsistencies in the installers.

Both the releases page ("First dot release in 2 years") and the post ("our first point release") mean the first change to the second version number, not the first update overall.

Kali's releases page gives Kali 2.0's codename as "safi"; the 2.0 release post and the history page both say "Sana," which we use. Upgrading from 1.x was possible. Kali 2.0's release post says "you can upgrade Kali 1.x to Kali 2.0" by pointing APT at the new "sana" repositories and running a dist-upgrade, with a warning that systems carrying extraneous repositories or manually overwritten packages would likely fail and were better reinstalled.

Image types in the 1.x era

For each era, these posts list the image types a release shipped. For 1.x, the official pages and the old.kali.org archive show:

Each 1.x folder on old.kali.org also has .sha1sum files and a signed SHA1SUMS file, though the archive dates those SHA1SUMS files to August 2021.

The security model of the time

Root by default

Kali's archived "Kali Linux Root User Policy" page, which Kali now marks as dated, describes the 1.x model plainly: "the default Kali user is 'root', and no non-privileged user is created as a part of the installation process." The reasons given were that many tools could only run as root, and that a multi-user Kali system was "highly unlikely." The same page says this is one reason Kali "is not recommended for use by Linux beginners."

Kali's 2019 post explains the history. Kali had "inherited the default root user policy from BackTrack," which made sense for a live CD that was never updated and ran tools that needed root. The live system's login was root with the password toor; the 2019 post announces "No more root/toor." The default changed only in Kali 2020.1, covered in our post on Kali's quarterly releases from 2020 to 2026.

Debian policy and FHS compliance

The 1.0 post makes FHS compliance one of the two drivers for the rebuild, and Kali's "What is Kali Linux?" page still lists it as a feature, so that "Linux users can easily locate binaries, support files, libraries, and so on." The security relevance is quiet but real: when every tool is a proper Debian package installed in standard paths, it gets updates through APT like everything else, instead of sitting in a folder that nothing tracks. That was exactly the gap in the live CD era.

Signed packages and a small trusted team

Kali's "What is Kali Linux?" page says every package "is signed by each individual developer who built and committed it, and the repositories subsequently sign the packages as well." Its "Should I use Kali Linux?" page says Kali is open source but "not a wide-open source project, for reasons of security," with a small, trusted team and a deliberately small set of upstream repositories. Both pages are current documentation; the 1.x sources we fetched do not describe the 2013 signing scheme in detail. The same page says there is "absolutely no support whatsoever" for PPAs, a clear break from the Ubuntu based BackTrack years.

A kernel patched for wireless injection

Kali's docs and the 1.1.0 post describe a kernel "patched for wireless injection," needed for wireless assessments; BackTrack 5 R1 said the same of its kernel.

Network services

Kali's current "Should I use Kali Linux?" page says Kali "contains systemd hooks that disable network services by default." None of the 1.x sources we fetched describe how network services were handled in 1.x. We cannot confirm what the 1.x default was from official pages, so we do not state it.

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 "NOT a recommended distribution" for people new to Linux or wanting a general purpose desktop, and warns that misusing security tools without specific authorisation "may cause irreparable damage" with personal and legal consequences.

That was true in 2004 and is true now. Use Kali only on systems you own or have written permission to test, and agree scope and rules in writing first. 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.

From Whoppix to Kali 1.1.0, the toolkit grew across the same broad categories: information gathering, vulnerability analysis, web application testing, password attacks, wireless testing, software defined radio and RFID or NFC research, reverse engineering, exploitation frameworks, forensics and reporting. BackTrack 5 R3 added a physical security category. Kali's 1.0 press release counted more than 300 programs. We do not describe how to use any of them.

How to check a Kali system today

Kali 1.x and BackTrack are history. If you have a machine or image from that era, the right move is to retire it and install a current Kali. For a current system, these checks confirm you are on a supported, up to date Kali. Commands come from Kali's documentation and release posts, cited in each step.

Step 1: Check the Kali version

Kali's release posts (for example 2026.2) use:

grep VERSION /etc/os-release

On a current system, VERSION_CODENAME shows kali-rolling. If you see a 1.x version or a codename like moto or sana, the system predates rolling Kali and should be rebuilt.

Step 2: Check the running kernel

The same release posts use:

uname -r
uname -v

The 1.x kernels Kali's official pages name are all 3.x series (3.12, 3.14 and 3.18). A current Kali runs a 6.x or newer kernel.

Step 3: Confirm you are on kali-rolling

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

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

Expect Suites: kali-rolling and Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg. Kali's "Should I use Kali Linux?" page warns against adding other repositories.

Step 4: Confirm you have the current archive key

Kali's April 2025 archive signing key post gives this check:

gpg --no-default-keyring --keyring /usr/share/keyrings/kali-archive-keyring.gpg -k

The output should include key 827C8569F2518CC677FECA1AED65462EC8D5E4C5. If apt update reports that key as missing, follow the steps in Kali's post.

Step 5: Update

From Kali's update guide:

sudo apt update
sudo apt full-upgrade -y

Kali's guide adds a habit worth keeping: make sure your tools work before an engagement, and do not update during one, because "once in a while issues will sneak into rolling."

Common mistakes

• Running a BackTrack or Kali 1.x image from an old tutorial. Kali 1.x sat on Debian 7 Wheezy, whose long term support ended at the end of May 2018, per Debian.
• Assuming old Kali images are safe because Kali rebuilt them. The 1.0.9a rebuild fixed Shellshock and the apt bugs of 2014. Nothing after that reached 1.x images.
• Treating BackTrack and Kali as the same codebase. Kali 1.0 was a rebuild on Debian; paths, packaging and updates all changed.
• Adding outside repositories or PPAs. Kali says this "runs a very serious risk of breaking your Kali Linux installation," and it also widens who you trust to sign your packages.
• Using the nuke option without a tested header backup. It does what it says. Test the restore before you travel.
• Using Kali as a general purpose desktop. Kali says it is not built for that. Our Ubuntu vs Kali vs Debian comparison covers what to use instead.
• Using Kali tools without written permission. The consequences Kali warns about apply to everyone.

FAQ

What was Kali Linux before it was called Kali?

BackTrack. Kali's history page traces the line from Whoppix (2004, based on Knoppix) to WHAX (2005, based on Slax), then BackTrack (2006 to 2013), which formed when WHAX merged with the Auditor Security Collection. Kali 1.0 replaced BackTrack on 13 March 2013.

When was Kali Linux first released?

Kali Linux 1.0.0, codenamed "moto," was released on 13 March 2013 at Black Hat Europe in Amsterdam, according to Kali's releases page and press release.

Is BackTrack still supported?

No. The official BackTrack site's timeline says "Support for BackTrack Linux ends" on 13 March 2013, the day Kali 1.0 was released. The last release was BackTrack 5 R3 on 13 August 2012.

Was BackTrack based on Ubuntu?

The later versions were. Kali's history page lists BackTrack 4 on Ubuntu 8.10 and BackTrack 5 on Ubuntu 10.04 LTS, with BackTrack 1 to 3 on Slackware. A 2019 Kali blog post says versions 1 to 4 were Slackware based and only BackTrack 5 moved to Ubuntu, so Kali's own pages disagree about BackTrack 4.

Why did Kali switch from Ubuntu to Debian?

Kali's 1.0 post says the team wanted to conform to Debian policy and the Filesystem Hierarchy Standard, and after weighing Debian and Ubuntu, "Debian was our final choice." The official Kali book cites Debian's quality, stability and software selection, and a 2019 Kali post says the team had been "so busy fighting with Ubuntu."

Is Kali Linux based on Debian or Ubuntu?

Debian. Kali 1.x was based on Debian 7 "Wheezy," Kali 2.0 on Debian 8 "Jessie," and rolling Kali on Debian testing. Kali has never been based on Ubuntu, though BackTrack 5 was.

What kernel did Kali 1.0 use?

Kali's releases page and the 1.0 post do not state it. The first 1.x kernel Kali's official pages name is 3.12 in Kali 1.0.6 (January 2014), followed by 3.14 in 1.0.7 and 3.18 in 1.1.0.

Did Kali 1.0 run as root?

Yes. Kali's dated root user policy says the default user was root and no unprivileged account was created at install, and the live system used root with the password toor. Kali switched to a non-root default user in Kali 2020.1.

What was the last version of Kali 1.x?

Kali 1.1.0a, released on 13 March 2015 to fix kernel ABI inconsistencies in the installers. Kali 2.0 "Sana" followed on 11 August 2015.

Fix it without waiting for upstream

The 1.0.9a story is a small version of a problem every team has: a fix exists upstream, but it does nothing until it is in the images and builds you actually ship. Kali closed that gap by rebuilding its ISOs. For your own applications and container images, the same gap shows up as a fixed dependency version that nobody has moved to yet, or a dependency whose maintainer has not shipped a fix 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

These demos do not update Kali; that stays with the Kali team and Debian. They cover the part your team owns: what is inside the code and images you build, and moving vulnerable dependencies to fixed versions with a person approving each step.

In this Safeguard CLI session you run safeguard 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 and pushes nothing. A testing team's own scripts and reporting tools have dependencies too, and the same flow turns an outdated one into a reviewed change.

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 built container image produces an SBOM of the operating system packages inside it, which is how you would spot a lab image still carrying an old bash or apt, the gap Kali closed with 1.0.9a.

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. You can then ask which of your projects contain a given component and version, the first question after an advisory like Shellshock. Our post on using SBOMs to find affected products fast goes deeper.

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.

For what came next, read our posts on Kali 2.0 and the move to rolling releases, 2015 to 2019, every Kali quarterly release from 2020 to 2026 and Ubuntu vs Kali vs Debian.

Quick check

Sources

• Kali Linux docs: Kali Linux History
• Kali Linux: Release History
• Kali Linux blog: Kali Linux 1.0 Release, Moto, The Birth of Kali Linux (13 March 2013)
• Kali Linux blog: Kali Linux Release Aftermath (18 March 2013)
• Kali Linux blog: Kali Linux Accessibility Improvements (26 April 2013)
• Kali Linux blog: Kali Linux 1.0.4 Summer Update Release (25 July 2013)
• Kali Linux blog: Kali Linux 1.0.5 and Software Defined Radio (5 September 2013)
• Kali Linux blog: Kali Linux 1.0.6 Release (9 January 2014)
• Kali Linux blog: How to Nuke your Encrypted Kali Installation (13 January 2014)
• Kali Linux blog: Kali Linux 1.0.7 Release (27 May 2014)
• Kali Linux blog: Kali Linux 1.0.8 Release with EFI Boot Support (22 July 2014)
• Kali Linux blog: Kali Tools Website Launched, 1.0.9 Release (25 August 2014)
• Kali Linux blog: Kali and NetHunter Security Release Fixes, 1.0.9a (6 October 2014)
• Kali Linux blog: Kali Linux 1.1.0 Release (9 February 2015)
• Kali Linux blog: Kali Linux 2.0 Release, Sana (11 August 2015)
• Kali Linux blog: Kali Default Non-Root User (31 December 2019)
• Kali Linux blog: Kali Linux 2026.2 Release
• Kali Linux blog: A New Kali Linux Archive Signing Key
• Kali Linux docs: Kali Press Release
• Kali Linux docs: What is Kali Linux?
• Kali Linux docs: Should I Use Kali Linux?
• Kali Linux docs: Kali's Relationship With Debian
• Kali Linux docs: Kali Linux Root User Policy (dated)
• Kali Linux docs: Updating Kali
• Kali Linux image archive: old.kali.org
• Kali Linux image archive: Kali images
• Kali Linux image archive: BackTrack images
• BackTrack Linux official site timeline
• Kali Linux Revealed, 1.1 A Bit of History (archived official page, kali.training)
• BackTrack 5 R1 Released, 18 August 2011 (archived official page)
• BackTrack 5 R2 Released, 1 March 2012 (archived official page)
• BackTrack 5 R3 Released, 13 August 2012 (archived official page)
• Debian: Debian wheezy Release Information
• Debian security tracker: CVE-2014-6271
• Debian security tracker: CVE-2014-7169
• Debian security tracker: CVE-2014-6273
• Debian security tracker: CVE-2014-0488

Last reviewed: 23 October 2026.