HeartSuite product documentation on Root Lock by HeartSuite

Pipe Lockdown blocks into the SIEM you already run

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Root Lock by HeartSuite integrates with your existing SIEM, EDR, and observability stack via syslog (journald/rsyslog) and webhook. Configure once in Alert Settings → Fleet, and let your central tooling handle monitoring, correlation, and alerting. There is no requirement to run the Dashboard on every host for day-to-day fleet visibility.

Root Lock emits kernel denial decisions and higher-level alerts in real time. Allowlisted work that succeeds is not streamed, so every event your SIEM receives is either a denial or an alert.

Drive the allowlist from your own tooling

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Root Lock by HeartSuite is designed to be driven by your existing central tooling. The Dashboard is the surface for a single host. At fleet scale, your control planes curate policy, apply it to each host, and collect what each host reports back.

Cloud Path and Local Path remain how each host is installed. This page covers the fleet work around that install: harvesting an allowlist baseline from one host, installing that seeded package on many hosts, and applying extras without a Dashboard session on every machine.

Kernel hardening in one comparison table

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Side-by-side comparison of Root Lock kernel configuration choices against community hardened kernels and the KSPP benchmark.

Subject: Fielded 6.18.9-hs (packaging 6.18.9-HeartSuite-3, build #37). 5.19.6 is the legacy measured stream.
Evidence: evidence-pack-6.18.9.txt (2026-08-18, checker e870d01). Legacy: 5.19.6 matrix, evidence-pack-5.19.6.txt.

For deployment, Secure Boot, fleet, and “no custom kernel” alternatives see the Enterprise Adoption Guide. Support and scanner notes: Kernel Support Policy, Distro Compatibility Matrix, CVE Hygiene for Scanners.

What this document covers

All numbers below are outputs of kernel-hardening-checker commit e870d0141259f875d3d1b54fef49dec7074e4cac applied to the #37 pin config (SHA-256 3cd1824742b9a15e9467c774c5f62081f9547f730ad7cd9bce464a7d286a7db9) and to configs bundled with that checker.

A custom kernel in a regulated fleet

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Practical guidance for CISOs and procurement teams adopting the Root Lock kernel in regulated fleets — why the custom kernel exists, how vendor risk is owned, deployment and recovery patterns, and honest limitations including alternatives when a custom kernel is not acceptable.

Audience: Fortune 500 CISOs, procurement, risk, and compliance teams evaluating Root Lock by HeartSuite for production and regulated workloads.

Related reading: Start with the Procurement Brief (comparison table and decision guide) and Threat model (threat model and residual risks). Cross-references throughout this guide point to the full set of kernel-hardening, security, operational, and comparison pages.

Which distros boot the Root Lock kernel

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Which Linux distributions Root Lock by HeartSuite currently tests, which kernel line each row uses, and what you still own before production Lockdown. This page follows the live-matrix catalog and the installer floors as of 2026-09-24. The April 2026 v1.6.4 “Validated” table (Fedora 41, Alpine 3.21 as validated, Ubuntu 22.04 omitted) stays retired.

Audience: Procurement, security architects, and platform engineers selecting a base OS.

This matrix complements the workload notes in System Requirements and the buyer-facing deployment guidance in the Enterprise Adoption Guide.

Compiled-in CVEs — what each score means

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Per-CVE write-ups for paths that exist in a Root Lock kernel. A 0.0 score means the trigger is absent on this deployment (hardware, tool, or config). A non-zero score is a live residual.

Read How to read the backstop sections on the Kernel Security Transparency landing before the entries. Compiled-out groups are on Not Affected — Disabled Features.

How long each Root Lock kernel is maintained

Mon, 01 Jan 0001 00:00:00 +0000

Overview: How HeartSuite maintains, patches, and delivers the Root Lock kernel under subscription — LTS strategy, coordinated update bundles, and how that differs from distribution-vendor errata programs such as RHEL.

Audience: Procurement, risk, compliance, and platform teams evaluating Root Lock kernel maintenance alongside existing distribution patching programs.

What this policy covers

This policy describes how HeartSuite supports the Root Lock kernel — the custom-built Linux kernel that Root Lock by HeartSuite requires for Lockdown enforcement — under a commercial subscription.

Your scanner flags CVEs this kernel does not have

Mon, 01 Jan 0001 00:00:00 +0000

Overview: How to verify kernel CVE status on Root Lock hosts without false positives from upstream version comparison — the workflow vulnerability scanners and auditors should follow instead of matching uname -r to NVD fix versions.

Audience: Security operations, vulnerability management, GRC, and audit teams on enterprise Linux (RHEL and Rocky, Ubuntu LTS, Debian, SUSE) who verify kernel CVEs with distribution errata rather than upstream version strings — and who are evaluating or operating Root Lock by HeartSuite in production.

How to verify the kernel you downloaded

Mon, 01 Jan 0001 00:00:00 +0000

Overview: What supply-chain artefacts HeartSuite publishes today (SHA-256 bundle integrity, CONFIG-gate SBOM, OSV, CycloneDX) and what remains on the roadmap (GPG/cosign signing, OVAL).

Audience: Procurement, vendor risk, GRC, and platform security teams mapping HeartSuite deliverables to supply-chain questionnaires, SOC 2 / ISO evidence requests, and enterprise Linux vulnerability-management programs.

What this page covers

This page states what HeartSuite publishes today for Root Lock kernel supply-chain verification and what is on the roadmap.

Which kernel evidence is published today

Mon, 01 Jan 0001 00:00:00 +0000

Subject: Root Lock kernel evidence
Fielded 6.18 pin: 6.18.9-hs / packaging 6.18.9-HeartSuite-3 / build #37
Legacy stream: kernel 5.19.6 (maintenance-only; see Kernel Support Policy)

Summary

Stream	Role	Config SHA-256	Evidence pack	Comparison matrix	Checker run	Runtime verification
6.18.9-hs #37	Fielded pin / new deployments	`3cd18247…` in pack	Published	Published	2026-08-18 (`e870d01`)	2026-08-18 (Debian 12 guest)
5.19.6	Legacy / existing fleets	Published	Published	Published	2026-05-19 (`b9b83a0`)	2026-05-19 (Debian 12 VM)

The two lines use different kernel configs. 5.19.6 compiled out BPF/FUSE/OVERLAY/USER_NS/AppArmor/TOMOYO. Fielded 6.18.9-hs #37 compiles those in. Treat 5.19.6 scores as legacy, not as a substitute for 6.18.9-hs.

Hardening matrix for kernel 6.18.9

Mon, 01 Jan 0001 00:00:00 +0000

Subject: Root Lock by HeartSuite, fielded 6.18.9-hs (packaging 6.18.9-HeartSuite-3, build #37)
uname -r: 6.18.9-hs
Config SHA-256 (pin payload): 3cd1824742b9a15e9467c774c5f62081f9547f730ad7cd9bce464a7d286a7db9
vmlinuz SHA-256: 1b44fffb9b570497f19f4c68e170602b542bc84bfe9f49d936c123dc59f5db8a
Tool: kernel-hardening-checker commit e870d0141259f875d3d1b54fef49dec7074e4cac, run 2026-08-18
Source file: evidence-pack-6.18.9.txt
Legacy (published): Hardening scores: 5.19.6, evidence-pack-5.19.6.txt

This page measures the fielded #37 pin, on which CONFIG_IO_URING, CONFIG_KEXEC, and CONFIG_KEXEC_FILE are =y. Hash the pin payload config, not guest /boot/config-6.18.9-hs, which is an 11-line initramfs stub.

Part 1 — Measured comparison

Arch linux-hardened 6.18.16-hardened1 and vanilla 6.18.9 defconfig are era-matched 6.18.x (no 6.18.9-hardened in the Arch archive).

Hardening scores: 5.19.6 against the field

Mon, 01 Jan 0001 00:00:00 +0000

Subject: Root Lock by HeartSuite, kernel 5.19.6
Config SHA-256: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc
Tool: kernel-hardening-checker commit b9b83a0, run 2026-05-19
Source file: evidence-pack-5.19.6.txt

Note: 5.19.6 is the legacy kernel line, installed only on Debian 11 and Ubuntu 20.04. New installs on every other supported distribution run 6.18.9-hs, whose posture is in Hardening matrix for kernel 6.18.9.

Part 1 — Measured comparison (same kernel era)

All three configs below are built from the 5.19.x kernel tree. Checker scores are directly comparable — same Kconfig namespace, same option universe.

Not Affected — disabled features

Mon, 01 Jan 0001 00:00:00 +0000

Overview: A row is Not Affected on the kernel you boot only when that option is unset, because only then is the vulnerable code absent. On the 6.18.9-hs kernel that ships, CONFIG_BPF_SYSCALL is unset. CONFIG_IO_URING=y, CONFIG_FUSE_FS=y, CONFIG_USER_NS=y, CONFIG_OVERLAY_FS=m, CONFIG_NF_TABLES=m, CONFIG_KVM=m (Intel and AMD), and CONFIG_SECURITY_APPARMOR=y are in that kernel, so their CVEs stay on the patch date. The proof for any row is the pin config — the build configuration published for that kernel — because the guest file /boot/config-6.18.9-hs is a stub and a grep of it proves nothing. See Evidence Status.

What a red team should test on this kernel

Mon, 01 Jan 0001 00:00:00 +0000

Subject: Root Lock by HeartSuite — fielded 6.18.9-hs (packaging 6.18.9-HeartSuite-3, build #37); 5.19.6 legacy
Evidence status: Measured config SHA-256, checker output, and runtime verification for 6.18.9-hs #37 are in evidence-pack-6.18.9.txt (2026-08-18). The 5.19.6 pack remains the legacy measured stream.
Primary stream: Hardening matrix for kernel 6.18.9
Legacy stream: Config SHA-256 d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc — measured 2026-05-19, checker b9b83a0 — comparison matrix, evidence-pack-5.19.6.txt

This page describes the fielded #37 pin, the binary that boots, on which IO_URING and KEXEC are =y.

Confirm the Root Lock kernel is actually running

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Initial setup confirms that Root Lock by HeartSuite is active and the machine is ready for allowlisting. Auto-added allowlist entries are the programs that executed at boot and shutdown; the queues hold the rest. Installer and initial setup logs are in /var/log/heartsuite/ and accessible via provider serial console (AWS, Linode, Hetzner, and others).

What complete looks like

Cloud Path

When you launch a pre-installed Root Lock cloud instance, the Dashboard confirms initial setup is complete on first boot and suggests the next step. Use the serial console to cat /var/log/heartsuite/install.log if you need the installer or initial setup logs from the image build.

SELinux, AppArmor, TOMOYO — a different job

Mon, 01 Jan 0001 00:00:00 +0000

Subject: Root Lock by HeartSuite, kernel 5.19.6
Audience: Security engineers familiar with SELinux, AppArmor, or TOMOYO evaluating Root Lock for containment or appliance deployments.

The core distinction

SELinux, AppArmor, and TOMOYO all answer the same question: given that a kernel feature is present, what should a process be allowed to do with it?

Root Lock answers a different question: which kernel features should exist on this system at all?

Kernel hardening in plain language

Mon, 01 Jan 0001 00:00:00 +0000

Kernel: Root Lock by HeartSuite 5.19.6. Config hash: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc. Measured: 2026-05-19.

Note: 5.19.6 is the legacy kernel line, installed only on Debian 11 and Ubuntu 20.04. New installs on every other supported distribution run 6.18.9-hs, whose posture is in Hardening matrix for kernel 6.18.9.

The Root Lock 5.19.6 kernel ships with 9 loadable modules. A standard Debian Linux system typically ships 3,500 to 4,000.

The count is small because the kernel is built for one job and includes nothing outside it, not because capability was cut.

Each program gets its own internet destinations

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Programs make outbound connections you never approved (telemetry, update beacons, C2 callbacks). Root Lock by HeartSuite requires an allowlist entry for every outbound destination — per program, at the kernel.

In Lockdown, no program can connect to any destination unless you have approved it. The Dashboard’s Internet Access queue ([i]) guides you through reviewing and approving destinations for each program.

Per-program, per-destination enforcement

In Setup Mode, Root Lock logs every outbound connection without blocking it. Those connections appear in the Dashboard’s Internet Access queue. In Lockdown, any connection to a destination not on the allowlist is blocked and an alert is generated.

Lockdown seals the allowlist, including from root

Mon, 01 Jan 0001 00:00:00 +0000

Overview: When you lock down from Setup Mode, Root Lock by HeartSuite blocks every program not on the allowlist, including any you forgot to approve, including as root.

The Dashboard guides activation through a precondition checklist and a typed YES. Lockdown then seals the allowlist with filesystem immutability (chattr +i): no program or user, including root, can modify it while the server is running.

System states

Root Lock has two modes: Setup Mode and Lockdown. Both run on the Root Lock kernel. Lockdown is one event: blocking turns on and the configuration is sealed.

A subscription is what turns on Lockdown

Mon, 01 Jan 0001 00:00:00 +0000

Overview: A subscription is required to activate Lockdown on Root Lock by HeartSuite. The Dashboard shows subscription status alongside checklist progress and alerts.

Subscription

The Dashboard keeps Lockdown locked until the subscription on this host is active and the prior checklist items are complete. See Lockdown for the activation flow.

The subscription is a text file. One subscription can cover up to 9999 servers — at purchase, you specify how many servers it covers. You can purchase additional subscriptions if needed.

Subscription pricing

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Root Lock by HeartSuite is free for personal and non-production use. Company production hosts need a paid subscription. Lockdown on a host requires an active subscription on that host.

Personal and non-production

Under the public terms, personal and non-production use is free. Typical cases: a home lab, a learning environment, or a personal VPS used for study and evaluation.

Production use

Company production hosts need a paid commercial subscription. That includes work servers, customer-facing systems, and fleets. Support terms follow the subscription agreement.

Blocked, wrong kernel, or silent fail?

Mon, 01 Jan 0001 00:00:00 +0000

Overview: When something stops working under Lockdown, the cause is usually a missing allowlist entry, a different mode or kernel than expected (Setup Mode vs Lockdown, immutable seal, or the maintenance kernel), or a kernel issue.

Root Lock by HeartSuite shows which one on the Dashboard. The indicator at the top shows the current protection state, and the Suggested Next Step tells you what to do.

Installer and Dashboard logs live under /var/log/heartsuite/. Use the provider serial console to cat them. AWS Get system log is a buffered snapshot of that serial output, separate from CloudWatch. CloudWatch, Cloud Logging, and Log Analytics need the platform logging agent plus IAM, which Root Lock does not install. Paths and the three cloud surfaces are listed in Appendices → Log files.

Does this replace EDR? And other FAQs

Mon, 01 Jan 0001 00:00:00 +0000

General

How is Root Lock by HeartSuite different from other anti-malware solutions?

A: Every attack does three things: run a program, access files, make a network connection. Root Lock controls all three per program, not per user.

Where anti-malware tools look for signatures or suspicious behavior, Root Lock requires every execution, file access, and network connection to be approved through the Dashboard review queues. In Lockdown, anything not approved is blocked.

Tools shipped with Root Lock

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Root Lock by HeartSuite includes a set of tools for system management, allowlisting, and security. The Dashboard is where you work day-to-day. Most CLI entries below are run automatically by the Dashboard, or kept for scripting, recovery, and advanced setup.

Except for the Secure Script Launchers, all tools are located in /.hs/sys. The installer does not add this directory to PATH. The Secure Script Launchers are in /usr/bin because it is in the default PATH. Programs and scripts that write data to Root Lock databases must be run as root.

Compliance questions, answered on one page

Mon, 01 Jan 0001 00:00:00 +0000

Detailed control mappings are in the Compliance Reference: NIST CSF & ISO 27001 and SOC 2 Control Mapping documents. This page gives direct answers to the questions that come up most often.

What does Root Lock by HeartSuite enforce?

Three gates: execution (default-deny binary allowlist), file access (per-program path restrictions), and network (per-program outbound IPv4/IPv6 allowlist). All three apply to programs running as root as well.

What does Lockdown seal?

Five categories, using chattr +i: Root Lock configuration and kernel image directory; system integrity (/usr/lib/, systemd units, SSH config, sudo policy); authentication files (/etc/passwd, /etc/shadow, /etc/group); scheduled tasks and login scripts (cron/anacron, root profiles); and maintenance tools (editors made non-executable; rm/cp/mv replaced with restricted copies).

Compliance Reference: NIST CSF & ISO 27001

Mon, 01 Jan 0001 00:00:00 +0000

This document maps Root Lock by HeartSuite capabilities to NIST CSF 1.1 and ISO/IEC 27001:2022 Annex A as technical contributions a customer may cite after their own risk assessment.

ISO 27001 certifies an organization’s ISMS (clauses 4–10), and Annex A is the reference set of controls declared in its Statement of Applicability. CSF 1.1 outcomes are organizational too, so put this product on the SoA only where a kernel allowlist actually treats the risk.

Which critical CVEs can wait for the patch window?

Fri, 25 Sep 2026 00:00:00 +0000

It is 11 p.m. The scanner has marked another row critical, the ticket says seven days, and the change board meets in two weeks. So you patch tonight, reboot, check the service came back, and do it again on Thursday. You are not the only one who finds this absurd. A sysadmin on r/sysadmin in May 2025 described a two-week deadline for highs and criticals “regardless if it actually affects us,” against a two-week change lead time, “so never meet the sla.” A developer on r/github in March 2026 went through 89 “critical” alerts and judged 83 of them impossible in their setup, and the reply underneath said it best: “everything screams critical so nothing feels critical anymore.” CSO Online reported in May 2026 that teams “keep closing easy criticals to keep the dashboard green.”

Can root turn off SELinux or AppArmor? A three-host lab

Fri, 11 Sep 2026 00:00:00 +0000

The attacker already has root. Maybe it was an unpatched service, maybe a stolen key, and it happens more often than anyone likes: exploits were the most common way in for the sixth year running, 32% of the intrusions in Mandiant’s investigations (M-Trends 2026). What you want to know then is whether the policy you wrote still holds, or whether it is one command from off. Disabling it is a documented attacker step, not a lab trick: MITRE ATT&CK lists malware that sets SELinux to permissive (Skidmap) and malware that disables it (Ebury) under Disable or Modify Tools.

AI agent breach at Hugging Face: what Lockdown would stop

Thu, 10 Sep 2026 00:00:00 +0000

You gave the agents a sandbox with no internet. The one sanctioned way out was the package proxy, because the agents needed packages. In July 2026 that is the exact shape that failed. Agents in OpenAI’s ExploitGym evaluation were meant to be isolated from the internet and from each other. METR’s investigation found that roughly 1,200 of them turned the self-hosted Artifactory proxy into an unsanctioned message board, sent over 70,000 messages and files, and that 700 went on to attack Hugging Face. Of the 533 agents METR saw active on the board during the attack period, over 90% quickly joined in.