Linux at 35: Security Milestones From 1991 to 2026

Linux turned 35 on 25 August 2026, and its security story runs from plain Unix permissions in 1991 to a kernel that now assigns its own CVE numbers and accepts Rust as a core language. The milestones that changed how you defend a Linux system are the LSM framework and SELinux (2000 to 2003), seccomp (2005, then filters in 2012), namespaces and cgroups (2002 to 2013), KASLR (2014), the Meltdown and Spectre response (2018), lockdown and Landlock (2019 and 2021), Rust (2022 to 2025) and the kernel CVE Numbering Authority (February 2024).

Below: each milestone with dates checked against primary sources, what each control does and does not do, and read only commands that show which are active on your machines.

Key takeaways

• The Linux Foundation marked the anniversary with a report published on 6 October 2026.
• Linux security grew in layers. Discretionary Unix permissions came first, then pluggable mandatory access control through the Linux Security Module (LSM) framework, then per process attack surface reduction (seccomp), isolation (namespaces and cgroups) and exploit mitigation (ASLR, KASLR, page table isolation).
• Most of these controls are opt in or depend on configuration. A kernel can support SELinux, AppArmor, seccomp and Landlock and still run a workload with none of them applied.
• Since 13 February 2024 the kernel project has been its own CVE Numbering Authority. It assigns a CVE to almost every bug fix it identifies in a supported stable tree, which is why NVD now lists more than 18,000 records from the kernel CNA.
• The kernel team says plainly that it cannot tell you whether a given CVE applies to your system. Its advice is to take whole stable releases rather than cherry pick fixes.
• Rust landed as a minimal experiment in Linux 6.1 (11 December 2022). At the December 2025 Maintainers Summit, developers agreed it is no longer experimental.

A dated timeline of Linux security milestones

Dates come from Torvalds' Usenet posts, KernelNewbies release notes, LWN, kernel.org and the CNA announcement. Two early dates rest on secondary summaries, marked in Sources.

How did Linux start, and what did security look like in 1991?

On 25 August 1991 a University of Helsinki student posted to the comp.os.minix newsgroup asking what people liked and disliked about Minix, because he was writing a free operating system for 386 and 486 AT clones. He described it as "just a hobby, won't be big and professional like gnu". In a later note collected in the same archive, Torvalds explains that 0.01 went out quietly as source only, without binaries, and that he announced 0.02 on 5 October 1991.

Security in that first kernel meant what it meant on any small Unix: user and group IDs, read, write and execute bits on files, and a superuser who could do anything. That model is called discretionary access control because the owner of a file decides who can use it. It is simple and still the first check the kernel makes, but it has two weaknesses that drove almost everything that followed:

1. Root is all powerful. A bug in any program running as root hands over the whole machine.
2. Users and their programs can give away access. A compromised process running as you can read everything you can read.

The rest of this history is mostly the kernel narrowing those two gaps.

The Linux Foundation's anniversary post frames the same 35 years from the other side: how a newsgroup hobby became the kernel underneath Android phones, Chromebooks, more than 200 million servers and every machine on the TOP500 list, with roughly ten changes landing every hour and a new release every eight to nine weeks. Kernel.org's own release page says nine to ten weeks, so treat the cadence as approximate.

How did SELinux and the LSM framework change Linux security?

Mandatory access control arrives

Mandatory access control (MAC) means a system wide policy decides what a process may do, regardless of what file owners want. The US National Security Agency released its Security Enhanced Linux code to the public under the GPL in December 2000, according to the project's history as summarised on Wikipedia, which cites the original Linux kernel mailing list post. Kernel developers responded with a general hook system so several models could plug in.

The Linux Security Module framework

That hook system is the Linux Security Module framework. The kernel documentation explains that LSM lets new kernel extensions hook into security checks, and that the word "module" is misleading: these are not loadable modules but features chosen when the kernel is built, selectable at boot with the security= parameter when more than one is compiled in. LSM became a standard part of Linux 2.6, released in December 2003, with SELinux among the first users.

The documentation also tells you how to see what is active. Reading /sys/kernel/security/lsm returns a comma separated list in the order checks run. The capability module is always first, then any minor modules such as Yama, then at most one major module such as SELinux. The same page lists SELinux, Smack, TOMOYO and AppArmor as the main MAC users of the interface.

AppArmor joins mainline

AppArmor took a different approach. The kernel documentation describes it as a task centred MAC extension: profiles are loaded from user space, and a task without a profile runs unconfined, which is the same as ordinary Unix permissions. AppArmor was merged in Linux 2.6.36, released on 20 October 2010. It can be selected at build time or with security=apparmor at boot.

What LSM gave defenders

The practical change was that a web server or database could be confined by policy even when running as root, so a bug inside it reaches far less. The cost was complexity, and teams often switch it off to make an error go away. Our guides on SELinux or AppArmor for a server and on hardening a Linux server cover the day to day choices.

What is seccomp, and how did it grow from 2005 to 2012?

Strict mode in 2.6.12

Seccomp (secure computing) arrived in Linux 2.6.12, released on 17 June 2005. As the KernelNewbies notes for 3.5 summarise, a process could switch into a mode allowing only exit, sigreturn, and read and write on already open file descriptors.

The same 2.6.12 release also randomised where each process's stack starts and where the mmap area begins. That user space address randomisation is the ancestor of KASLR, discussed below.

Filter mode in 3.5

Linux 3.5, released on 21 July 2012, added seccomp filters. The kernel documentation explains the reasoning: every process can reach a large number of system calls it never uses, and each one is attack surface. With filter mode, a process installs a Berkeley Packet Filter (BPF) program that sees the system call number and its arguments and decides what happens. Because BPF filters cannot dereference pointers, they only evaluate the values passed directly, which avoids the time of check to time of use races common in older syscall interposition tools.

The documentation is careful about what seccomp is not. It describes syscall filtering as a mechanism for shrinking exposed kernel surface that sandbox authors build on, not a complete sandbox by itself. Information flow and logical behaviour still need other controls such as an LSM.

Where seccomp shows up today

Browsers, container runtimes and system services use seccomp filters heavily. Our explainers on whether Docker uses a seccomp profile by default and on what seccomp, capabilities and no new privileges each do go into the switches.

How did namespaces and cgroups make containers possible?

Containers are not a single kernel feature. They are a combination of namespaces (what a process can see), cgroups (how much it can use) and the confinement features above (what it may do).

Namespaces, one resource at a time

Michael Kerrisk's 2013 LWN series is still the clearest account of how namespaces arrived:

• Mount namespaces came first, in Linux 2.4.19 in 2002. They give a group of processes its own view of the mount table, which is why the clone flag is the generic CLONE_NEWNS.
• UTS and IPC namespaces followed in 2.6.19, isolating the hostname and System V IPC objects.
• PID namespaces arrived in 2.6.24. The KernelNewbies notes for 2.6.24 list PID and network namespaces together.
• User namespaces began in 2.6.23 and were completed in Linux 3.8, released on 18 February 2013, after about five years of work.

The 3.8 change was the big one. From that release, an unprivileged process can create a user namespace in which it has full privileges, and from there create the other namespace types. That enabled rootless containers and unprivileged sandboxes. It also opened a large new attack surface, because code paths once reachable only by real root became reachable by ordinary users inside their own namespace. That trade off is why the setting deserves a deliberate decision on your own systems.

Control groups

Linux 2.6.24, released on 24 January 2008, also brought task control groups, which let the kernel account for and limit CPU, memory and other resources per group of processes. Linux 4.15 later added the CPU controller to the unified cgroup v2 hierarchy, which the kernel documentation now describes as the current interface.

For the container side, see container isolation with namespaces, cgroups and seccomp. For a well known case where a cgroup feature became an escape path, see our write up of CVE-2022-0492, the cgroups release_agent escape.

What is KASLR, and when did Linux add it?

Why randomise the kernel

Address space layout randomisation places code and data at unpredictable addresses so that an attacker who finds a memory bug cannot simply jump to a known location. User space ASLR existed from 2.6.12. In October 2013, LWN reported on Kees Cook's Linux Security Summit talk making the case for doing the same to the kernel. It built on Dan Rosenberg's 2011 proposal.

As LWN summarised the talk, a typical kernel exploit needs to know where useful kernel functions live, and those addresses are fixed for a given distribution build. Randomising the kernel's base address forces the attacker to find an information leak first. The talk was also frank about limits: KASLR is a statistical defence with a limited number of possible slots, it helps most where processes are already confined (for example a browser renderer sandboxed with seccomp), and it depends on closing leaks. Cook recommended enabling the kptr_restrict and dmesg_restrict sysctls and making logs readable only by root.

Merged in 3.14

KASLR for 64 bit x86 was merged in Linux 3.14, released on 30 March 2014. Cook told the summit that ARM was next on his list. Linux 5.13 (27 June 2021) extended the idea with randomisation of the kernel stack offset on each system call, alongside support for Clang's Control Flow Integrity, which stops execution when certain kinds of control flow hijack are detected.

KASLR can be switched off with the nokaslr boot option, so check rather than assume, and remember it is only as strong as the leak hygiene around it. A kernel that prints raw pointers to logs that unprivileged users can read gives much of the benefit away.

How did the kernel respond to Meltdown and Spectre in 2018?

The disclosure

On 3 January 2018, Jann Horn of Google Project Zero published details of three CPU side channel issues that the team had reported to Intel, AMD and ARM on 1 June 2017: bounds check bypass (CVE-2017-5753), branch target injection (CVE-2017-5715) and rogue data cache load (CVE-2017-5754). The first two became known as Spectre variants 1 and 2, the third as Meltdown.

These were hardware flaws, but the kernel absorbed much of the fix. Its documentation lists affected processor families from almost every major vendor.

Page table isolation and retpoline

Linux 4.15, released on 28 January 2018, shipped the mainline mitigations. Page table isolation (PTI), previously called KAISER, gives user space its own set of page tables that maps almost none of the kernel, so a speculative read from user space has nothing secret to find. Retpoline, a compiler technique, mitigated Spectre variant 2. At release, PTI covered x86 Intel CPUs and could be disabled at boot.

What changed permanently

The lasting change was process and visibility. The kernel gained a documented way to handle embargoed hardware issues, and a sysfs directory, /sys/devices/system/cpu/vulnerabilities/, where each file reports whether the CPU is affected by a given issue and which mitigation is active. For the background, see our posts on Spectre and Meltdown in 2018, the difference between Meltdown and Spectre and the later Retbleed variant.

What did lockdown and Landlock add?

Kernel lockdown (5.4)

Linux 5.4, released on 24 November 2019, added kernel lockdown mode. The KernelNewbies summary describes its purpose as strengthening the boundary between UID 0 and the kernel. Traditionally root could modify the running kernel through several interfaces, such as writing to kernel memory devices or loading unsigned code. Lockdown restricts those interfaces, which matters most on systems using Secure Boot, where the chain of trust would otherwise end the moment root got a shell.

Landlock (5.13)

Linux 5.13 added Landlock, a stackable LSM designed for unprivileged sandboxing. The current kernel documentation (dated August 2026, by Landlock's author Mickaël Salaün) explains the goal: let any process, including an unprivileged one, restrict its own ambient rights, such as global file system or network access, as an extra layer on top of system wide controls. Rules cover file hierarchies and, since later ABI versions, TCP ports (ABI v4) and UDP ports (ABI v10). The difference from seccomp is the object: seccomp filters system calls by number and arguments, while Landlock restricts access to specific files and ports. Our post on what Landlock is and how it differs from seccomp has examples.

Which Linux security control does what?

These features overlap in name but not in purpose. This table is the decision aid.

These controls stack: a well configured container host uses all of them, and removing one leaves a gap the others were not designed to fill.

How did Rust get into the Linux kernel?

A deliberately small start

C offers no built in protection against memory safety bugs such as use after free. The Rust for Linux project spent several years building the support code to write kernel components in Rust. When it was merged for Linux 6.1, Linus Torvalds asked for as little as possible to go in. LWN's first look on 13 October 2022 reported that the merge contained only what was needed to build a loadable Rust module and one sample, and that no production 6.1 system would be running Rust code. Linux 6.1 was released on 11 December 2022.

No longer an experiment

Over the following releases, Rust abstractions and real drivers were merged. On 10 December 2025, LWN reported that the annual Maintainers Summit had agreed Rust in the kernel is no longer experimental and would lose that label. The kernel documentation now has a full Rust section with a quick start guide and coding guidelines.

What Rust does and does not change

Rust prevents whole classes of memory errors in the code written in it. It does not retroactively fix the tens of millions of lines of existing C, it still needs unsafe blocks to talk to hardware and to C code, and logic bugs remain possible. The realistic expectation is a gradual drop in memory safety bugs in new drivers and subsystems written in Rust, not an end to kernel CVEs. Our posts on Rust adoption in security critical software and what unsafe blocks still allow cover the trade offs.

Why did the Linux kernel become a CVE Numbering Authority in 2024?

The announcement

On 13 February 2024, stable kernel maintainer Greg Kroah-Hartman announced that the Linux kernel project had been accepted as a CVE Numbering Authority (CNA) for vulnerabilities in Linux. A CNA controls CVE assignment for its scope, so no other group can assign a kernel CVE without involving it. He thanked the Python project and OpenSSF for help with the process, and said the change was a way for the project to take more responsibility in a CVE system he considers broken in many ways.

LWN's Jonathan Corbet explained the background the next day: kernel CVEs had often been requested for reasons unrelated to real risk, and contesting a bad one was slow. Projects such as curl, Kubernetes and Python had already become CNAs partly to stop that.

How the kernel assigns CVEs

The kernel documentation sets out a process unlike most CNAs:

• Because almost any kernel bug might be exploitable, and exploitability is often unclear when the fix lands, the team is deliberately cautious and assigns a CVE to any bug fix it identifies.
• No CVE is automatically assigned for an unfixed issue. Assignment happens after a fix is applied to a stable tree and is tracked by the commit ID of the original fix.
• CVEs are only assigned for kernel versions currently supported by the stable and longterm team. Issues that exist only in a distribution's modified or out of support kernel must go to that distribution.
• Only the maintainers of the affected subsystem can dispute or change an assigned CVE.

Most important for defenders, the documentation states that applicability is the user's job. The kernel team does not know your configuration or which parts of the tree you use, says that many assigned CVEs will not be relevant to any given system, and recommends taking all released stable changes as a tested whole rather than picking individual fixes.

What the volume looks like

The numbers follow from the policy. As of 23 October 2026, NVD's API returns 18,260 CVE records whose source is the kernel CNA. In the first four months of 2025 alone it lists 1,663. Corbet's 2024 article gave the scale in advance: by version 6.1.74, the 6.1 kernel had received 12,639 fixes, and 4.19 had received 27,952 by 4.19.306. Not every fix gets a CVE, but many do.

That volume breaks any process that treats every CVE as an individual ticket, or any policy that forbids shipping with an open CVE. Teams that backport selected kernel fixes into an old, unsupported kernel cannot keep up. Teams that track a supported longterm branch and take its releases regularly can. For embedded teams, our post on the kernel CVE flood and which CVEs apply to an embedded device goes further.

What does the Linux kernel look like in late 2026?

Kernel.org on 23 October 2026 lists mainline 7.3 (released 18 October 2026), stable 7.2.12, and six longterm branches: 6.18, 6.12, 6.6, 6.1, 5.15 and 5.10. The releases page gives projected end of life dates of December 2026 for 5.10 and 5.15, December 2027 for 6.1 and 6.6, and December 2028 for 6.12 and 6.18. If any of your systems still run 5.10 or 5.15 based kernels from kernel.org, they have about two months of upstream support left. Distribution kernels follow their vendor's schedule instead.

The Linux Foundation post adds two current trends. PREEMPT_RT real time support was mainlined in 6.12, ending a roughly twenty year effort. And the kernel community is both adapting to AI workloads and using AI tooling to help maintainers with patch review and security auditing. More automated bug finding means more fixes, and more CVEs to absorb.

Step by step: see which of these milestones your systems actually use

Every command below is read only; some need root for full detail.

1. Identify the kernel and its support status

uname -r
# Compare the major.minor version against https://www.kernel.org/releases.html
# Anything after the dash (for example 6.12.0-55.el10.x86_64) means a distribution kernel
cat /proc/version

2. List the active security modules

cat /sys/kernel/security/lsm
# Example output: lockdown,capability,landlock,yama,apparmor

Then check the major module's state:

getenforce 2>/dev/null          # SELinux: Enforcing, Permissive or Disabled
sudo aa-status 2>/dev/null | head -20   # AppArmor: loaded and enforced profiles

3. Check Landlock and lockdown

sudo dmesg | grep -i landlock || sudo journalctl -kb -g landlock
cat /sys/kernel/security/lockdown 2>/dev/null   # the active mode is shown in brackets

4. Check seccomp use by a running process

grep -E 'Seccomp|NoNewPrivs' /proc/self/status
# Replace self with a PID, for example a container's main process
grep -E 'Seccomp|NoNewPrivs' /proc/$(pgrep -o nginx)/status
# Seccomp: 0 none, 1 strict, 2 filter

5. Check namespaces and cgroup version

lsns | head -20
stat -fc %T /sys/fs/cgroup     # cgroup2fs means the unified v2 hierarchy
sysctl user.max_user_namespaces

6. Check KASLR and pointer leak settings

grep -o 'nokaslr' /proc/cmdline || echo "nokaslr not set on the command line"
sysctl kernel.kptr_restrict kernel.dmesg_restrict

A kptr_restrict value of 0 means kernel pointers may be printed to unprivileged users, which weakens KASLR.

7. Check CPU vulnerability mitigations

grep -r . /sys/devices/system/cpu/vulnerabilities/
grep -oE '(nopti|mitigations=off|spectre_v2=off)' /proc/cmdline

A line reading Vulnerable deserves a look, and any of those boot options means someone disabled a mitigation on purpose. Find out why before changing it.

8. Record it

Store a short record per host type (kernel branch, LSM and mode, lockdown, cgroup version, mitigations) next to its software bill of materials, so the next kernel CVE batch becomes a lookup.

Where Safeguard fits, honestly

Safeguard does not configure or harden kernels. It does not turn on SELinux, AppArmor, seccomp, Landlock or lockdown, it does not apply kernel patches to hosts, and it cannot decide whether a particular kernel CVE is reachable on your hardware and configuration; the kernel team itself says only you can do that. What Safeguard does cover is the software you build and ship on top of Linux. It scans repositories, container images and SBOM files, matches the components it finds against vulnerability databases, applies reachability analysis to application dependencies, shows which projects contain a given component and version, and evaluates policies and gates. That matters here because container images carry their own user space (C libraries, OpenSSL, language runtimes) that needs the same discipline as the kernel underneath, and because a vendor's SBOM for an appliance or device image can be scanned with safeguard scan --sbom <file> to see what it contains.

Common mistakes

• Disabling SELinux or AppArmor to fix one error. Switching to permissive mode while you write a policy fix is reasonable; disabling MAC entirely and forgetting about it is the most common way these controls disappear. Our guide to SELinux permissive versus disabled explains the difference.
• Assuming a feature is on because the kernel supports it. Seccomp, Landlock and AppArmor profiles only protect processes that use them. Check /proc/PID/status and aa-status rather than the kernel config.
• Triaging kernel CVEs one by one, or cherry picking fixes into an unsupported kernel. The kernel documentation warns that many problems need several changes together and some relevant fixes have no CVE. Track a supported branch and take whole stable updates.
• Ignoring end of life dates. Kernel.org projects December 2026 for 5.10 and 5.15. After that, the kernel CNA will not assign CVEs for issues found only in those branches, so a quiet CVE feed does not mean a safe kernel.
• Leaving kptr_restrict and dmesg_restrict at 0 on multi user systems. That hands out the kernel addresses KASLR is meant to hide.
• Allowing unrestricted unprivileged user namespaces without a reason. They enable rootless containers, but they also expose kernel code paths to ordinary users. Decide deliberately.

FAQ

When was Linux first released?

Linus Torvalds announced the project on the comp.os.minix newsgroup on 25 August 1991. Version 0.01 sources were shared a few weeks later without a public announcement, and 0.02 was announced on 5 October 1991. The 35th anniversary therefore fell on 25 August 2026.

Is SELinux part of the Linux kernel?

Yes. SELinux is a Linux Security Module in the mainline kernel and has been since the 2.6 series. The policy that tells it what to allow comes from user space, usually from your distribution or the SELinux reference policy.

What is the difference between SELinux and AppArmor?

Both are mandatory access control modules built on LSM. SELinux decides on labels attached to processes and objects; AppArmor attaches profiles to programs, mostly by path, and leaves programs without a profile unconfined.

Does seccomp make a process a sandbox?

Not on its own. The kernel documentation describes seccomp filtering as a way to reduce exposed kernel surface that sandbox developers build on. A real sandbox combines it with namespaces, an LSM or Landlock, and dropped privileges.

How did Linux fix Meltdown?

With page table isolation (PTI), which gives user space a separate set of page tables that maps almost none of the kernel. It shipped in Linux 4.15 on 28 January 2018, alongside retpoline for Spectre variant 2.

Why does the Linux kernel have so many CVEs now?

Since becoming a CNA in February 2024, the kernel team assigns a CVE to almost every bug fix it identifies in a supported stable tree, because it cannot know in advance which bugs are exploitable. NVD lists more than 18,000 kernel CNA records as of October 2026. Many will not apply to your configuration.

How do I know if a Linux kernel CVE affects me?

The kernel team says that is up to you, because it depends on your kernel version, configuration and how the system is used. Start with uname -r, confirm you are on a supported branch, check whether the affected subsystem is built and loaded, and prefer taking whole stable updates over judging each CVE.

Is Rust still experimental in the Linux kernel?

No. Initial support arrived in Linux 6.1 in December 2022, and at the Maintainers Summit in December 2025 developers agreed Rust is no longer experimental and is a core part of the kernel.

Fix it without waiting for upstream

The kernel's own policy is the best argument for patch discipline: take tested releases quickly and as a whole, because a large backlog of individually tracked fixes is where risk hides. The same applies to the open source libraries and container images you run on top of Linux, which is the part of the stack Safeguard works on.

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.

To try it on your own machine, download Safeguard from https://safeguard.sh/download and see the CLI documentation at https://docs.safeguard.sh/docs/cli .

See how Safeguard would help

The first demo sets up Safeguard's local runner on your own Linux or other machine, approves it with a device code, and runs a scan from the terminal. On an image build host, the same flow shows which packages and libraries went into the images you ship on top of the kernel. It does not inspect or patch the host kernel itself.

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

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, 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. That approve each step flow is the application level version of the kernel team's advice: apply the tested fix, run the tests, and keep a human in the loop.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask which of your projects carry a given package version, while deciding exactly what the assistant is allowed to touch.

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

Quick check

Sources

• Linux Foundation: Celebrating 35 Years of Linux (6 October 2026)
• Linus Torvalds' early Linux posts, archived at Carnegie Mellon University
• kernel.org: The Linux Kernel Archives (current releases)
• kernel.org: Active kernel releases and longterm support
• Greg Kroah-Hartman: Linux is a CNA (13 February 2024)
• Linux kernel documentation: CVEs
• Linux kernel documentation: Linux Security Module usage
• Linux kernel documentation: SELinux
• Linux kernel documentation: AppArmor
• Linux kernel documentation: Seccomp BPF
• Linux kernel documentation: Landlock
• Linux kernel documentation: Rust
• Linux kernel documentation: Spectre side channels
• Linux kernel documentation: Page Table Isolation
• Linux kernel documentation: Control Group v2
• LWN: A turning point for CVE numbers (14 February 2024)
• LWN: Kernel address space layout randomization (9 October 2013)
• LWN: Namespaces in operation, part 1 (4 January 2013)
• LWN: A first look at Rust in the 6.1 kernel (13 October 2022)
• LWN: The (successful) end of the kernel Rust experiment (10 December 2025)
• Google Project Zero: Reading privileged memory with a side channel (3 January 2018)
• NVD CVE API: records with the kernel CNA as source
• KernelNewbies: Linux 2.6.12 (seccomp, address space randomisation)
• KernelNewbies: Linux 2.6.24 (control groups, PID and network namespaces)
• KernelNewbies: Linux 2.6.36 (AppArmor)
• KernelNewbies: Linux 3.5 (seccomp filters)
• KernelNewbies: Linux 3.8 (user namespaces completed)
• KernelNewbies: Linux 3.14 (KASLR)
• KernelNewbies: Linux 4.15 (Meltdown and Spectre mitigations)
• KernelNewbies: Linux 5.4 (kernel lockdown)
• KernelNewbies: Linux 5.13 (Landlock, Clang CFI)
• KernelNewbies: Linux 6.1 (initial Rust support)
• Wikipedia: Linux Security Modules (secondary summary for the 2.6 merge date)
• Wikipedia: Security-Enhanced Linux (secondary summary for the December 2000 release date)

Last reviewed: 23 October 2026.