Kernel Hardening

• 1: Procurement Brief: Kernel Hardening at a Glance
• 2: Enterprise Adoption Guide: The Root Lock by HeartSuite Kernel in Regulated Environments
• 3: Distribution Compatibility Matrix
• 4: Kernel Support Policy
• 5: CVE Hygiene for Scanners and Auditors
• 6: Supply Chain and Advisory Feeds
• 7: Kernel Evidence Status
• 8: Kernel Hardening Comparison Matrix (6.18.9)
• 9: Kernel Hardening Comparison Matrix
• 10: Security Auditor Brief: Kernel Hardening Posture
• 11: LSM Comparison: HeartSuite vs SELinux, AppArmor, and TOMOYO
• 12: Analyst Summary: HeartSuite Kernel Hardening

1 - Procurement Brief: Kernel Hardening at a Glance

Overview: Side-by-side comparison of HeartSuite’s kernel hardening choices against community hardened kernels and industry benchmarks — start here if you are evaluating the HS kernel for procurement.

Subject: Root Lock by HeartSuite HS kernel — 6.18.9 primary (commercial baseline, HeartSuite v1.6.4), 5.19.6 legacy
Evidence status: Measured scores on this page reference the published 5.19.6 stream (2026-05-19, kernel-hardening-checker). New deployments use 6.18.9; config hash and checker parity for that stream are in progress — see Evidence Status and Kernel Hardening Comparison Matrix (6.18.9).
Legacy technical data (measured): kernel-comparison-matrix-5.19.6.md, evidence-pack-5.19.6.txt

For enterprise buyers and CISOs evaluating the custom kernel in regulated environments — including deployment patterns, Secure Boot status, fleet management, risk transfer, supply chain artifacts, recovery paths, compatibility, and alternatives for strict “no custom kernel” policies — see the Enterprise Adoption Guide. Kernel support policy, distribution compatibility, and scanner hygiene: Kernel Support Policy, Distro Compatibility Matrix, CVE Hygiene for Scanners.

What this document covers

Every Linux kernel ships with hundreds of configuration choices that determine how easy it is to exploit vulnerabilities or escape security controls. This document compares HeartSuite’s kernel choices to a directly comparable community-hardened kernel and the KSPP industry benchmark.

All numbers in the tables below are outputs of the same measurement tool applied identically to each 5.19.6-era kernel configuration. No estimates. The Arch linux-hardened comparison uses the 5.19.11 release — the same kernel generation as HeartSuite 5.19.6, making scores directly comparable. Do not apply these figures to 6.18.9 deployments; request pre-release 6.18.9 evidence via support or watch Evidence Status for publication.

At a glance

KSPP benchmark anchored to kernel 6.17; its version-agnostic recommendations set the de facto industry target but are not directly score-comparable to 5.19.x.

What HeartSuite is optimized for

HeartSuite removes or disables the kernel features that are most commonly used to bypass security controls — not necessarily those used to exploit vulnerabilities.

This means:

• Attacker cannot use BPF to override security decisions at runtime. (Arch linux-hardened keeps BPF enabled; it’s widely used by system tools and container runtimes.)
• Attacker cannot use user namespaces (CONFIG_USER_NS=n) to create a fake root environment. (Arch linux-hardened 5.19.11 keeps user namespaces enabled for container use.)
• Attacker cannot use FUSE or overlay filesystems to confuse path-based enforcement.
• No competing security policies (AppArmor, SELinux at runtime, YAMA, Landlock, IMA, EVM) that could interfere with or be manipulated to weaken HeartSuite’s decisions.

What HeartSuite does not add — and dedicated hardened kernels do:

• Memory initialization on allocation/free (INIT_ON_ALLOC_DEFAULT_ON, INIT_ON_FREE_DEFAULT_ON)
• Bounds-checking on kernel-to-user copies (HARDENED_USERCOPY)
• Compiler-level hardening (FORTIFY_SOURCE, RANDSTRUCT, GCC_PLUGIN_LATENT_ENTROPY)
• Allocator randomization (SLAB_FREELIST_RANDOM, SLAB_FREELIST_HARDENED)
• Kernel stack erasure on syscall return (KSTACK_ERASE)

These mitigations slow down or prevent exploitation of kernel memory bugs. Arch linux-hardened 5.19.11 scores 69/109 (63.3%) on this axis vs HS’s 31/109 (28.4%). HeartSuite 5.19.6 sits at the vanilla upstream baseline for exploit-resistance. For deployments where the primary concern is a compromised process escaping its enforcement boundary — not kernel memory exploitation — HeartSuite covers the relevant threat at the right operating point; the Decision guide below covers when adding exploit-resistance hardening alongside HeartSuite makes sense.

Broader market landscape

Note: NixOS linux_hardened was removed from nixpkgs in 2025 due to lack of maintenance and is no longer an active project. Qualitative characterizations are drawn from each project’s public documentation. Only HS and Arch linux-hardened scores are directly measured and era-matched.

Decision guide

Choose HeartSuite if your primary concern is:

• Preventing a compromised application from escaping its security boundary
• Ensuring no in-kernel feature (BPF, FUSE, namespaces) can be used to bypass your security policy
• Minimizing the total kernel attack surface (9 loadable modules vs. thousands)
• Running a single-purpose security appliance, not a general-purpose server

Consider adding a hardened kernel layer if your concern is also:

• Protection against kernel-level exploitation (heap corruption, use-after-free, ROP)
• Compliance requirements that enumerate specific KSPP mitigations
• Environments where root access cannot be fully constrained

HeartSuite is not a replacement for: network firewalls, application-layer WAFs, SIEM, endpoint detection/response — it operates at the kernel enforcement layer, not at the network or application layer.

Verification

HeartSuite’s kernel configuration is published with a SHA-256 hash. Any qualified security team can reproduce these measurements using the open-source kernel-hardening-checker tool:

Config SHA-256: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc
Tool: https://github.com/a13xp0p0v/kernel-hardening-checker (commit b9b83a0)

Full methodology and raw data: evidence-pack-5.19.6.txt

2 - Enterprise Adoption Guide: The Root Lock by HeartSuite Kernel in Regulated Environments

Overview: Practical guidance for CISOs and procurement teams adopting the HeartSuite 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 Auditor Brief (threat model and residual risks). Cross-references throughout this guide point to the full set of kernel-hardening, security, operational, and comparison pages.

Why a custom kernel

Root Lock by HeartSuite uses a custom-built Linux kernel (based on mainline LTS releases such as 5.19.6 and 6.18) so that enforcement cannot be bypassed by an attacker who has already reached root.

The design removes at build time the kernel features most commonly used as bypass vectors for security controls:

• The BPF syscall (CONFIG_BPF_SYSCALL) — there is no eBPF layer an attacker can load programs into or unload.
• User namespaces (CONFIG_USER_NS) — no unprivileged fake-root environment for container escapes or privilege escalation.
• FUSE and OverlayFS — path-confusion and mount-based bypasses against VFS-level enforcement are unavailable.
• Competing LSM frameworks (AppArmor, TOMOYO, and runtime SELinux enforcement) and related policy engines — no parallel policy that can be set permissive or edited to weaken decisions.

Enforcement logic for program execution, file access, and outbound network connections is compiled into the kernel binary itself. Blocking decisions are consulted on every relevant operation; there is no runtime configuration file or agent that root can unload, kill, or reconfigure to disable protection.

This is distinct from “hardening mitigations” (stack canaries, allocator hardening, etc.). Those raise the cost of exploiting a memory bug. Root Lock by HeartSuite removes the primitives that let a compromised process escape its intended boundary in the first place. See the side-by-side scores and rationale in the Procurement Brief and the bypass table in How Root Lock by HeartSuite Compares.

The result is a deliberately smaller kernel (approximately 9 loadable modules versus thousands in a general-purpose distribution) whose configuration is published with a SHA-256 hash for independent verification.

What Root Lock by HeartSuite owns for kernel risk

Root Lock by HeartSuite treats the kernel as an integrated part of the delivered product, not a third-party dependency the customer manages in isolation.

• Update cadence and patching: Kernels are released as coordinated versioned bundles with the userspace components (daemon, Dashboard, tools, and installer). Updates follow the same maintenance window model as policy changes: boot the maintenance kernel, apply the bundle, return to the HeartSuite kernel, and review. Public patch targets, notification channels, and version-string semantics are in the Kernel Support Policy. Supported distributions and validation tiers are in the Distro Compatibility Matrix.
• CVE handling: The Kernel Security Transparency page provides per-CVE status with technical rationale. Features compiled out produce “Not Affected” entries (the vulnerable code path is absent by design; no patch or policy change is required). For reachable code paths, Lockdown’s allowlist bounds post-exploitation impact: new programs cannot execute, mounts are refused, and changes to sealed configuration are blocked. Scores on HeartSuite are computed and published (many high/critical CVEs drop to 0.0 environmental score on HS deployments). Scanner and audit workflows are in CVE Hygiene for Scanners.
• Stack pairing and testing: The kernel is built, tested, and supported together with the matching userspace. The full enforcement contract (VFS hooks + Lockdown seal + allowlist) is validated across supported distributions.
• Support SLAs: Commercial subscription terms cover the integrated stack, including kernel-related incidents, coordinated updates, and guidance on deployment and recovery. Activation and support details appear in the Subscription section and your subscription agreement.

Deployment mitigations: hiding kernel details in practice

Enterprise teams do not want operators making daily kernel choices. The product and recommended deployment patterns are built to keep the kernel choice at image-build or initial-provision time.

• Cloud Path: Pre-configured instances on major providers (AWS, Google Cloud, Azure, DigitalOcean, Linode, and others) arrive with the HeartSuite kernel already installed and set as default. The Dashboard appears on first login with Phase 1 complete. Serial console access from the provider remains available for recovery.
• Golden image recipes and automated install: Use your existing Packer, Terraform, Ansible, or cloud-init pipelines to produce base images that include the Root Lock by HeartSuite install bundle. The installer sets the HeartSuite kernel as the GRUB default, performs the initial boot, and surfaces the Dashboard. Baseline allowlists can be pre-seeded for homogeneous fleets (see Alert Settings — fleet syslog, webhook, and central policy patterns).
• Hiding details from operators: After initial provisioning, day-to-day interaction is through the Dashboard or central automation. Kernel selection appears only in the documented Maintenance flow (when changes are required) and in the System Info Strip when running on the maintenance kernel. GRUB entries for the original distribution kernel are retained (split into Maintenance and vanilla entries, with Maintenance labelled as the Setup Mode destination) for the recovery path.

Official pre-built images in the major cloud Marketplaces are in active development and will further reduce the need for customers to assemble images. Until those listings are available, the golden-image + automated-install pattern delivers equivalent repeatability and auditability using the same tooling you already apply to other base OS images.

Secure Boot, firmware compatibility, and roadmap

Current status: HeartSuite kernel support for UEFI Secure Boot (including MOK enrollment on local hardware and provider-specific flows such as Azure Trusted Launch and GCP Shielded VMs) is incomplete. Deployments that require Secure Boot enabled for the HeartSuite kernel entry may need to enroll via MOK during installation or temporarily boot with Secure Boot disabled for the HeartSuite kernel while using the provider console or local management for the maintenance kernel.

The original distribution kernel (Non-HS) retains its signing status and can be used for recovery and maintenance regardless of Secure Boot policy.

Roadmap: Signed kernel images, streamlined MOK tooling, and cloud-provider-specific runbooks (Azure, GCP, AWS) are prioritized work. Expanded test coverage for UEFI Secure Boot paths is tracked alongside the existing partial e2e validation. Customers evaluating platforms with mandatory Secure Boot should engage support for the current test status and any interim runbooks applicable to their cloud account or hardware.

The bypass-prevention properties (physical presence required for any recovery path) hold on both the HeartSuite kernel and maintenance kernel; Secure Boot is an orthogonal boot-integrity control.

Compatibility and certification

Root Lock by HeartSuite is designed to coexist with the majority of enterprise infrastructure components that do not themselves depend on the disabled kernel features.

Works with (standard configurations):

• Local and cloud block storage (ext4, xfs, and provider volumes) for the root and data filesystems.
• Standard networking stacks and cloud provider vNICs / security groups (Root Lock by HeartSuite controls only outbound per-program destinations; inbound remains the responsibility of the OS firewall or cloud controls).
• SIEM / SOAR ingestion via the two syslog streams and webhook (see Alert Settings).
• Monitoring and status collection via ~/.cache/heartsuite/status.json (Ansible facts, Nagios, Zabbix, custom collectors).
• Container workloads with fixed pod sets established before Lockdown engages (see deployment notes in How Root Lock by HeartSuite Compares).
• EDR and observability via log forwarding (no on-host eBPF attachment or kernel-module agents are possible or required; enforcement events flow through the existing syslog channel).
• Vulnerability scanners and HIDS/FIM agents (run during Setup Mode so their programs and paths are reviewed and approved).

Requires the maintenance kernel or a separate host (or alternative controls):

• Local execution of eBPF-based tools (Falco, Cilium Tetragon, bpftrace, etc.) — the BPF syscall is deliberately absent.
• Dynamic Kubernetes environments with frequent pod creation, HPA scale-out, or rescheduling after Lockdown (mount operations required for new containers are refused).
• KVM hypervisor hosts (KVM host-mode features are compiled out).
• Rootless / unprivileged user-namespace containers.
• Any workload or tooling that explicitly requires one of the compiled-out features for its core function.

Decision tree (high level)

Full compatibility notes and known non-fits live in How Root Lock by HeartSuite Compares (section “Where a separate kernel is required”) and the system-requirements pages. As more storage, networking, EDR, and monitoring vendors publish explicit coexistence statements, this section will be expanded with a published matrix.

Operational model for fleets

The HeartSuite kernel is managed the same way you manage base OS images and policies — through the control planes you already own.

• Image lifecycle: Treat the HeartSuite kernel + baseline allowlist as part of your golden image. Packer templates call the official install bundle, pre-seed policy via the batch tools, and produce an image that boots directly to the protected state. Reprovision or patch images on the same cadence as your other distributions.
• Provisioning: Terraform, cloud-init, or your IaC tool launches the image (or runs the installer non-interactively). No special kernel module or agent is required after boot.
• Policy at scale: Allowlist content (programs, file paths, network destinations) is curated centrally and applied via Ansible, Terraform + GitOps, ServiceNow, or custom automation exactly as described in Alert Settings (fleet export surfaces and central policy patterns). Pre-seeding accelerates homogeneous fleets; observation + central review handles varied workloads.
• Kernel updates: Delivered as versioned bundles. Apply during planned maintenance windows using the standard maintenance kernel path (or by reprovisioning from an updated golden image). The Dashboard and automation surfaces make the required steps repeatable.
• Observability and drift: status.json, the JSONL approval log, and the two syslog streams feed your existing fleet dashboards and SIEM. Drift detection (policy or mode) is performed by harvesting from central jobs and comparing against the Git/CMDB source of truth.
• No new kernel-specific fleet tooling: The same rsyslog rule, SSH/Ansible access, and image pipeline you use today handle the kernel boundary.

This model keeps ownership of policy curation, change records, and visibility inside the tools your teams already run.

Risk transfer under commercial subscription

A commercial subscription for Root Lock by HeartSuite covers the full delivered stack, including the kernel:

• Vendor support and SLAs for incidents, updates, and deployment guidance that encompass kernel behaviour.
• Contractual risk-transfer terms (indemnification and liability provisions) as set out in the subscription agreement for the licensed software.
• Access to the verification artifacts published on this site (config hashes, evidence packs, CVE transparency data) that support customer and auditor due diligence.
• Coordinated release process so that kernel changes, userspace changes, and documentation remain in sync.

The kernel does not carry a separate support contract or separate risk posture; it is part of the integrated product under the same subscription that enables Lockdown. Details of indemnity scope, SLA commitments, and verification deliverables are in your specific subscription agreement. See the Subscription page for activation mechanics.

Supply chain transparency and integrity

• Reproducible posture verification: Every released HeartSuite kernel includes a published SHA-256 of its exact .config file. Any team can obtain the config from the kernel package and re-run the open-source kernel-hardening-checker to reproduce the exact attack-surface and exploit-resistance scores shown in the Procurement Brief and Auditor Brief. See evidence-pack-*.txt files for raw output.
• Installer and bundle integrity: Distributed bundles include SHA-256 manifests (.sha256 files) for verification before execution.
• SBOM and provenance: A full software bill of materials covering the kernel and userspace components, plus expanded reproducible-build artifacts and signing for kernel binaries, is in active development. Current customers receive the available verification material (config hash + evidence packs + bundle hashes) under their subscription; additional supply-chain artifacts are provided on request or as they become available. Public roadmap and interim controls: Supply Chain and Advisory Feeds. Per-stream evidence publication: Evidence Status.
• No reliance on opaque vendor claims for the measured hardening posture: The numbers are tool outputs against public hashes.

Recovery and fallback: the maintenance kernel as supported escape hatch

Every installation retains a first-class recovery path:

• The original distribution kernel is always present in GRUB (split into Maintenance and vanilla entries during install, with Maintenance labelled as the Setup Mode destination).
• The Dashboard’s Maintenance flow ([m]) detects Lockdown state and guides the operator through the exact sequence: reboot to maintenance kernel, remove the immutable seal, make changes, reboot back to the HeartSuite kernel, review new activity, and re-engage Lockdown.
• The Dashboard’s Maintenance ([m]) handles the common case of quick Non-HS work followed by guided return to the Root Lock by HeartSuite kernel and review.
• For policy or platform conflicts that make the Root Lock by HeartSuite kernel unsuitable for an extended period, teams can remain on the maintenance kernel (the product continues to run and log in non-enforcing mode) or remove Root Lock by HeartSuite entirely. Both paths are supported and documented.
• Physical or console access (local keyboard/monitor, serial, or cloud provider serial console) is always sufficient to select the maintenance kernel and regain full control. No software on the system can block this path.

This is the documented, supported escape hatch for operational needs, kernel policy conflicts, or environments that ultimately decide against a custom kernel. Full procedures appear in the Maintenance section and FAQs.

Evidence and independent verification for customers and auditors

Nothing on the kernel posture page relies on “trust us.”

• Reproduce hardening measurements yourself with the published config SHA-256 and the open-source checker (full commands in Auditor Brief).
• Review every relevant CVE with the exact “Not Affected / Score on HeartSuite 0.0 / bounded impact” rationale on the Kernel Security Transparency page.
• Inspect live state via the status JSON, per-decision syslog events, approval log, and the sealed allowlist files (all readable or harvestable without special privileges beyond normal admin access).
• For procurement and audit packages: the Procurement Brief, Auditor Brief, comparison matrix, and evidence packs are self-contained artefacts that can be attached directly to RFPs, due-diligence questionnaires, and auditor workpapers.

Honest limitations

Root Lock by HeartSuite with the HeartSuite kernel is a deliberate architectural choice that trades general-purpose kernel compatibility for bypass resistance and root-immunity. It is not the right fit for every environment.

Organisations with formal “no custom kernel,” “no modified kernel,” or “vendor-certified kernel only” policies (driven by support contracts, regulatory certification of the base OS, or internal change-control mandates) should not adopt the HeartSuite kernel.

In those cases the supported path is:

• HeartSuite Joint File System (HJFS) — a filesystem-based enforcement layer that provides per-program, per-version file isolation and automatic backup/rollback on a completely standard kernel. No kernel replacement is required. HJFS is deployable on cloud instances where the kernel is provider-managed and on systems under strict kernel certification rules. See the full HJFS documentation (overview, deployment scenarios, limits, and how it complements execution/network controls).
• Layered controls on the standard kernel (SELinux or AppArmor in enforcing mode, seccomp filters, eBPF-based detection where needed, network egress filtering, EDR, vulnerability management, and HIDS). Root Lock by HeartSuite’s execution and network gating concepts are not applicable without the HeartSuite kernel.
• Where both file isolation and execution/network gating are required under a no-custom-kernel constraint, HJFS plus existing or companion execution/network tooling (including HeartSuite Exec Lock in some configurations) is the evaluated combination.

The HJFS how-it-compares and limits pages, together with the bypass and circumvention sections of How Root Lock by HeartSuite Compares, give procurement teams the material needed to map requirements to the appropriate product or combination.

Root Lock by HeartSuite positions the HeartSuite kernel for the subset of workloads where the documented properties (compiled enforcement, physical-presence recovery only, bounded CVE impact via compiled-out features and Lockdown) justify the kernel change.

Next steps for enterprise evaluation

1. Read the Procurement Brief decision guide and run the published measurements on a test deployment.
2. Review the Auditor Brief and the full CVE transparency page.
3. Pilot using a cloud pre-configured instance or a Packer-built golden image on a non-production workload.
4. Map your compatibility requirements against the decision tree and the “where a separate kernel is required” section of How Root Lock by HeartSuite Compares.
5. For platforms with Secure Boot or Marketplace requirements, request current runbook and timeline status from support.
6. For strict no-custom-kernel policies, evaluate HJFS in parallel.
7. Engage commercial discussions for subscription terms, support SLAs, and any additional verification artefacts.

The kernel is one component of a larger control. The surrounding pages (central policy management, SIEM integration, maintenance, and comparison material) describe how the rest of the operational model fits into an enterprise security program.

This page is intentionally buyer- and auditor-facing. All posture claims reference publicly reproducible artefacts or the open CVE transparency data. Last updated: 2026-06-16.

3 - Distribution Compatibility Matrix

Overview: Which Linux distributions HeartSuite has validated for the HS kernel, what each support tier means, and where RHEL-family images need customer-side validation before production Lockdown.

Subject: Root Lock by HeartSuite HS kernel (5.19 and 6.18 lines; v1.6.4 commercial baseline: kernel 6.18.9)
Audience: Procurement, security architects, and platform engineers selecting or certifying a base OS for Root Lock by HeartSuite.

This matrix states which distributions HeartSuite has validated in release testing, which are officially supported without a specific gate run, and where customer-side validation is required before production Lockdown. It complements the workload-level exclusions in System Requirements and the buyer-facing deployment guidance in the Enterprise Adoption Guide.

How to read this matrix

Each row assigns a tier that tells you what HeartSuite has tested and what you own in procurement:

Columns in the main table

• HS kernels — Root Lock by HeartSuite ships two kernel lines: 5.19 and 6.18. New commercial baselines use the 6.18 line (for example, 6.18.9-HeartSuite-1.0 for v1.6.4). Either line may be selected at install; both enforce the same Root Lock by HeartSuite contract.
• Boot — How the installer sets the default kernel entry. UEFI Secure Boot for the HS kernel entry remains incomplete; the original distribution kernel (Non-HS) retains its signing status for maintenance and recovery.

A cross-distro release gate runs after every kernel update. The April 2026 v1.6.4 gate validated: Debian 12, Debian 13 (Trixie), Ubuntu 24.04, Fedora 41, Rocky 9.7, CentOS Stream 9, Alpine 3.21, and openSUSE Tumbleweed. See the Roadmap for release history.

Main compatibility table

Architecture: x86_64 (64-bit) only. No ARM or other ISA builds are offered for the HS kernel.

Secure Boot (all distributions): HS kernel UEFI Secure Boot support is incomplete. Deployments with mandatory Secure Boot for the HS entry may require MOK enrollment during install or booting the HS kernel with Secure Boot disabled while retaining the signed Non-HS kernel for maintenance. Details: Enterprise Adoption Guide → Secure Boot.

Tier definitions

Validated

HeartSuite ran the full cross-distro release gate on the stated distribution version: install bundle, HS kernel boot, Setup Mode, service lifecycle (systemd or OpenRC), and Lockdown smoke checks. These rows are the default answer for RFP compatibility questions tied to v1.6.4 and later kernel bundles.

Supported

Officially in System Requirements and covered by commercial support when install and Lockdown succeed on the customer image. HeartSuite may not re-run every gate on every supported minor; your staging environment is the final gate before production.

Compatible (customer validation)

Same packaging family or ABI lineage as a validated build, but HeartSuite has not published test results for your exact vendor branding, minor release, or gold image. Rocky 9.7 validation implies Rocky 9.x and AlmaLinux 9.x are structurally compatible; RHEL 8/9 require validation on the customer’s subscribed minor until branded RHEL matrices are published.

Not supported

Outside current product scope. Use a supported distribution, the Non-HS kernel on a separate host for incompatible workloads, or HJFS on a standard kernel where custom kernels are prohibited.

RPM / RHEL family

RPM-based support expanded in the v1.6.4 multi-distro release (April 2026). This matrix is the authoritative source for distribution tiers; System Requirements and FAQs link here for current status.

Lead with Rocky 9.7 (Validated). For enterprise fleets standardizing on RHEL-compatible userspace, Rocky Linux 9.7 is the reference RPM image: GRUB defaulting, SELinux stacking, and coordinated bundle install match what HeartSuite tests in CI.

SELinux on RHEL-family systems: HeartSuite VFS hooks run before the LSM chain. SELinux can only add restrictions after HeartSuite allows an operation; it cannot bypass HeartSuite denials. On RHEL and Fedora, SELinux is Enforcing by default. As with any new kernel module on RHEL, a targeted SELinux policy entry may be needed for HeartSuite-specific operations. If AVC denials appear, use ausearch and audit2allow to build a targeted module — HeartSuite enforcement is unaffected. Full hook-order detail: LSM Comparison → Co-existence (RHEL operational note).

Debian and Ubuntu family

Debian and Ubuntu-derived distributions remain the longest-supported install path and the majority of documentation examples.

Installer behaviour on Debian/Ubuntu: sets the HS kernel as the GRUB default and reboots automatically when GRUB automation succeeds (v1.6.4+). The original distribution kernel remains in GRUB as Maintenance and vanilla entries for recovery.

Alpine Linux

Alpine is a supported, validated path for minimal and container-adjacent appliances.

Alpine’s musl-based userspace is fully within scope when the distribution version is supported or validated. Workload exclusions (eBPF, FUSE, dynamic containers after Lockdown, KVM host mode) apply regardless of distribution — see Workload fit below.

SUSE family

Workload fit (not distro-specific)

Distribution compatibility answers whether Root Lock by HeartSuite installs and boots on your base OS. Whether the workload belongs on the HS kernel is a separate decision — the same across every row in the matrix.

Root Lock by HeartSuite deliberately removes kernel features used as bypass primitives. Workloads that depend on those features require the Non-HS kernel (maintenance mode) or a separate host, regardless of whether the distribution is Validated or Supported.

Full exclusion table and container-host install notes: System Requirements. Decision tree for mixed environments: Enterprise Adoption Guide → Compatibility.

HJFS alternative

Organizations with a strict no custom or modified kernel policy — certification rules, cloud provider-managed kernels, or vendor OS support contracts that forbid replacing the distribution kernel — should not force the HS kernel onto those images.

HeartSuite Joint File System (HJFS) provides per-program, per-version file isolation and automatic backup on a completely standard kernel. No kernel replacement is required. HJFS is deployable on any distribution where a standard kernel is mandated, including cloud instances where the provider owns the kernel image.

HJFS limits, deployment scenarios, and comparison to kernel-level enforcement: HJFS how-it-compares and HJFS limits. Procurement mapping: Enterprise Adoption Guide → Honest limitations.

Reporting issues

If install or HS kernel boot fails on a Supported or Compatible distribution, contact HeartSuite support with enough context to reproduce the failure:

Email: support@heartsecsuite.com

Include:

1. /var/log/heartsuite/install.log — installer steps and outcome (see Appendices).
2. Kernel identity: output of uname -r (expected to end in HeartSuite when the HS kernel is active, for example 6.18.9-HeartSuite-1.0).
3. OS identity: contents of /etc/os-release.
4. Root Lock by HeartSuite version and whether the failure occurs during install, first HS boot, Setup Mode, or Lockdown.
5. Boot loader in use (GRUB vs extlinux) and whether UEFI Secure Boot is enabled.

For non-blocking bugs on supported platforms, open a GitHub issue using the Bug Report template on the public repository. Do not use public issues for security vulnerabilities — email support@heartsecsuite.com for responsible disclosure.

Kernel update recovery procedures if a new HS kernel fails to boot: Updating Root Lock by HeartSuite.

Related reading

• Kernel Support Policy — LTS strategy, patch targets, version-string semantics, and notification
• System Requirements — Architecture, kernel lines, and software exclusion table
• Enterprise Adoption Guide — Secure Boot status, fleet operations, procurement decision tree
• LSM Comparison — SELinux co-existence and RHEL operational note
• Procurement Brief — Hardening posture comparison for buyers
• CVE Hygiene for Scanners — Scanner false-positive workflow for HS kernel hosts
• How Root Lock by HeartSuite Compares — What requires a separate kernel or host
• Deployment Scenarios — Where Root Lock by HeartSuite fits in production
• Roadmap — v1.6.4 multi-distro validation history
• HJFS documentation — Standard-kernel alternative for strict kernel policies
• Before You Begin — Prerequisites and cloud vs local install paths

4 - Kernel Support Policy

Overview: How HeartSuite maintains, patches, and delivers the HS 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 by HeartSuite kernel maintenance alongside existing distribution patching programs.

Related reading: Enterprise Adoption Guide, Updating HeartSuite, Kernel Security Transparency, Distro Compatibility Matrix, CVE Hygiene for Scanners.

What this policy covers

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

It applies to:

• HS kernel streams currently shipped and supported:
  • 6.18 — primary LTS stream and commercial baseline (HeartSuite v1.6.4 ships kernel 6.18.9).
  • 5.19 — legacy stream for existing deployments; no longer the default for new installations.
• Coordinated update bundles that deliver the HS kernel together with matching userspace components (Dashboard, daemon, tools, and installer). Kernel changes are not published or supported as standalone kernel-only packages outside these bundles.
• Integration with subscription terms — patch targets, notification channels, and binding service-level commitments appear in your subscription agreement. This page states public targets and operational boundaries so buyers can align internal change-control and vulnerability-management programs before contract signature.

Note: This policy does not replace the subscription agreement. Where this page and your agreement differ, the agreement controls.

LTS-only strategy

HeartSuite commits to mainline LTS kernel bases only — not arbitrary upstream version chasing and not long-lived forks of non-LTS releases.

Why LTS-only

• LTS branches receive upstream security and stability maintenance for a defined period, which gives HeartSuite a predictable rebuild base.
• HeartSuite’s security model depends on a fixed, published kernel configuration (compiled-out subsystems, enforcement hooks, and Lockdown integration). Rebuilding on a known LTS tag preserves that contract while absorbing upstream fixes that apply to the compiled-in code paths.
• Chasing every upstream minor release would multiply validation cost without improving the enforcement properties buyers adopt Root Lock by HeartSuite for.

Commercial baseline

• New subscriptions and new fleet images should standardize on the 6.18 stream.
• HeartSuite v1.6.4 (April 2026) established 6.18.9 as the commercial release baseline for multi-distribution support.

When HeartSuite advances the LTS base (for example, a future move within the 6.18 LTS line or to a subsequent LTS series), customers receive advance notice and migration bundles as described under Customer notification and 5.19 stream deprecation.

How HeartSuite differs from the distribution-vendor model

Enterprise Linux distributions such as RHEL follow a frozen-base, backport-within-base model: the upstream kernel version number visible in uname stays on a vendor branch for years, while individual CVE fixes are cherry-picked onto that branch. Vendor errata, advisory identifiers, and scanner feeds are built around that model.

HeartSuite follows a different model, aligned with how Root Lock by HeartSuite is built and validated:

HeartSuite is honest about the trade-off: the HeartSuite kernel is not a drop-in substitute for a distribution kernel in every operational sense. It is the enforcement kernel for Lockdown. The distribution maintenance kernel remains on the system for maintenance and recovery; distribution errata still apply to packages and to the maintenance kernel path.

For deployment implications, coexistence with distribution maintenance, and fleet patterns, see the Enterprise Adoption Guide.

HS kernel version string anatomy

The running kernel version is shown by uname -r. On an HS deployment, the string identifies the HeartSuite build, not a distribution errata package.

Example: 6.18.9-HeartSuite-1.0

Legacy 5.19 deployments follow the same pattern (for example, 5.19.6-HeartSuite-<release>).

What the version string does not mean

Procurement and scanner teams trained on distribution errata often misread custom kernel strings. The HS kernel version string does not imply:

• Full upstream parity — The string does not assert that every fix present in a newer upstream kernel is backported. HeartSuite rebuilds on the LTS base with the published HeartSuite configuration; fixes apply to compiled-in paths or are addressed through structural absence and Lockdown bounds as documented on the Kernel Security Transparency page.
• Distribution errata equivalence — A match against a distribution CVE feed or rpm -q kernel version is not valid for the HS kernel. The HS kernel is not the distribution enforcement kernel.
• Scanner “fixed in version” logic — Vulnerability scanners that compare uname -r to NVD “fixed version” thresholds will produce false positives for HS kernels. Use HeartSuite’s per-CVE status and CVE Hygiene for Scanners guidance instead of raw version-string matching.
• kABI or DKMS compatibility — The string does not promise binary compatibility with out-of-tree kernel modules built for the distribution kernel or for prior HS builds.
• Live-patch level — There is no parallel “kpatch level” or running-patch suffix; updates require a coordinated bundle and reboot path.
• Secure Boot readiness — Version format does not indicate UEFI Secure Boot signing status for the HS kernel entry. Secure Boot support for the HS kernel remains incomplete; see the Enterprise Adoption Guide for current status.

For independent verification of what is in the build, HeartSuite publishes the kernel .config SHA-256 and evidence packs for each supported stream.

Update delivery

HS kernel updates are delivered only as part of coordinated HeartSuite release bundles.

Bundle format and integrity

• Updates ship as a self-extracting heartsuite-install.sh bundle with a published heartsuite-install.sh.sha256 checksum file.

• Before execution, verify integrity:

  sha256sum -c heartsuite-install.sh.sha256
  

  Expected output: heartsuite-install.sh: OK

• Each bundle updates the HS kernel (vmlinuz-<version>-HeartSuite-<release>), userspace tools, Dashboard files, and GRUB defaults together so the enforcement stack stays paired and tested.

Applying an update

The running HS kernel cannot replace itself. Updates use the documented two-reboot Non-HS path:

1. Reboot from the HS kernel to the Non-HS kernel (distribution maintenance kernel).
2. Run bash heartsuite-install.sh on the Non-HS kernel.
3. Reboot into the new HS kernel and complete any post-install review the Dashboard indicates.

Root Lock by HeartSuite is not active on the Non-HS kernel. Schedule updates in a planned maintenance window. If Lockdown is engaged, disengage through the Dashboard’s Maintenance ([m]) before updating.

Full step-by-step procedures, failure recovery, and Lockdown considerations are in Updating HeartSuite.

Golden image alternative

Teams that provision from images may reprovision from an updated golden image instead of in-place bundle application. This is equivalent from a support perspective when the image contains a bundle version HeartSuite has published for that stream. Image pipelines should pin bundle version, checksum, and HS kernel string in build metadata for audit traceability.

Patch commitment tiers

HeartSuite classifies kernel-related security work using the reachability model on the Kernel Security Transparency page. The tables below are public targets for coordinated bundle delivery. Binding SLAs — including business-day definitions, escalation, and credit terms — are set in your subscription agreement.

Clock start for timed tiers: HeartSuite confirmation that the issue applies to the supported HS kernel stream (reachable path or required rebuild), based on upstream vendor/public confirmation and HeartSuite analysis.

Notes

• Many high-severity CVEs are Not Affected on HS kernels because the attack surface was never compiled in. Those entries do not consume patch-tier clocks.
• For reachable CVEs, Lockdown limits persistence and arbitrary code execution even before a rebuild ships; patching remains part of defense-in-depth and subscription commitments for reachable paths.
• HeartSuite does not commit to per-CVE errata identifiers in the distribution-vendor style. Bundle manifests list addressed CVEs for the release.

Customer notification

HeartSuite notifies subscription customers through the following channels:

Major stream deprecation: HeartSuite provides at least 30 days’ advance notice before ending support for an HS kernel stream (for example, end of 5.19 support). Notice includes migration bundle availability and recommended maintenance windows.

Machine-readable advisory feeds are published as JSON under /advisories/ on each annotated hs-v* release tag. For the current release (hs-v1.6.4-kernel-6.18.9, gate_status: PASS): CONFIG-gate Not-Affected SBOM at /advisories/hs-cve-config-sbom.json, OSV at /advisories/osv.json (279 entries), and CycloneDX SBOM at /advisories/sbom.cyclonedx.json. OVAL XML for OpenSCAP is not yet published — use the JSON feeds, CVE transparency page, bundle manifests, and email advisories as authoritative sources. Feed URLs and schemas: Supply Chain and Advisory Feeds.

5.19 stream deprecation

The upstream 5.19 branch is end-of-life. HeartSuite no longer recommends 5.19 for new deployments or new golden images.

Support window for existing deployments

• HeartSuite continues to ship 5.19 migration and security bundles for deployments already on the 5.19 HS stream through end of calendar year 2026, subject to subscription status.
• After that date, 5.19 HS kernel support ends unless extended terms are agreed in writing. Engage HeartSuite support before the cutoff to plan fleet migration.

Migration path

1. Schedule maintenance using the Updating HeartSuite two-reboot path (or reprovision from a 6.18 golden image).
2. Apply the published 5.19 → 6.18 migration bundle for your distribution and HeartSuite version.
3. Reboot into the 6.18 HS kernel, review Dashboard queues for any new program activity, and re-engage Lockdown if required.
4. Update vulnerability-management and configuration baselines to reference the new version string and published 6.18 config hash.

Functional differences between streams (configuration, module footprint, CVE tables) are summarized in the Distro Compatibility Matrix and stream-specific evidence materials.

Support boundaries

Subscription scope

• The HS kernel is included in the Root Lock by HeartSuite subscription. There is no separate kernel-only support contract.
• Incidents, rebuild requests, deployment guidance, and coordinated updates for kernel behaviour are handled under the same subscription that enables Lockdown.
• Verification artifacts (config SHA-256, evidence packs, CVE transparency data, bundle checksums) are provided as part of the product documentation and subscription deliverables.

Coexistence with distribution subscriptions

On a host running Root Lock by HeartSuite:

Root Lock by HeartSuite replaces the enforcement kernel for protected operation; it does not remove the distribution kernel or cancel distribution maintenance obligations on the Non-HS path. During maintenance on the Non-HS kernel, the host behaves as a standard distribution system without Lockdown enforcement.

Distribution-vendor subscriptions (RHEL, SLES, Ubuntu Pro, and similar extended-support offerings) and third-party agents that require the distribution kernel for full functionality continue to apply to the Non-HS maintenance path and to userspace packages. Agents or tools that require BPF, specific kernel modules, or kernel interfaces absent from the HS kernel must run on the Non-HS kernel or on a separate host. (The HS kernel omits these by design to eliminate bypass primitives and attack surface; see the Enterprise Adoption Guide compatibility section and Reduced Kernel Footprint.)

What HeartSuite does not provide

HeartSuite does not offer the following on the HS kernel path:

If a workload requires live patching, vendor-certified unchanged distribution kernels, or broad third-party kernel module support as non-negotiable constraints, evaluate the Non-HS path, HJFS on a standard kernel, or layered controls described in the Enterprise Adoption Guide rather than the HS kernel.

Related reading

• Enterprise Adoption Guide — Deployment, fleet operations, Secure Boot status, risk ownership, and compatibility decision tree.
• Updating HeartSuite — Bundle verification, two-reboot procedure, and recovery.
• Kernel Security Transparency — Per-CVE status, Not Affected rationale, and Score on HeartSuite.
• Distro Compatibility Matrix — Supported distributions, kernel streams, and coexistence notes.
• CVE Hygiene for Scanners — Resolving scanner false positives against HS version strings.
• Supply Chain and Advisory Feeds — Published CONFIG SBOM, OSV, and CycloneDX feeds; GPG/cosign and OVAL roadmap.
• Evidence Status — Per-stream config hash and checker publication status.

This page is procurement- and operations-facing. Patch targets are goals for planning; binding commitments are in your subscription agreement. Last updated: 2026-06-23.

5 - CVE Hygiene for Scanners and Auditors

Overview: How to verify kernel CVE status on HeartSuite 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.

Related reading: Start with Kernel Security Transparency (per-CVE status and rationale), the Procurement Brief (posture at a glance), and the Auditor Brief (threat model and reproduction commands).

Why vulnerability scanners get HeartSuite wrong

Most enterprise vulnerability scanners were built for distribution kernels. They match the running kernel version string against NVD or vendor feeds that assume a vanilla upstream Linux kernel — the same tree, configuration, and feature set as kernel.org.

Root Lock by HeartSuite does not ship a vanilla upstream kernel. It ships a custom configuration on an LTS base (for example, mainline 6.18.9 with a HeartSuite release suffix such as 6.18.9-HeartSuite-1.0). The version string tells you the LTS line and HeartSuite bundle revision; it does not tell you which subsystems are compiled in, which CVEs are reachable, or whether a backported upstream fix is relevant.

When a scanner sees 6.18.9-HeartSuite-1.0, it typically:

1. Normalises the string to 6.18.9 (or fails to recognise the suffix entirely).
2. Compares that version against NVD “fixed in” ranges for the upstream kernel (for example, “fixed in 6.18.12”).
3. Flags the host as vulnerable without checking whether the vulnerable code path exists in the HeartSuite build.

That produces false positives — often hundreds of them — for CVEs where HeartSuite’s answer is Not Affected (feature compiled out), Score on HeartSuite 0.0 (environmental neutralisation), or bounded impact under Lockdown (reachable code path with post-exploitation constraints).

This is structurally similar to the backport false positives enterprise Linux teams already manage on RHEL, Rocky, Ubuntu LTS, Debian, and SUSE: a package version string does not prove patch status. HeartSuite adds a second dimension: configuration and enforcement, not just source version. The correct source of truth is the Kernel Security Transparency page, not upstream version ranges alone.

Bottom line: Treat scanner kernel findings on the HS kernel as candidates for review, not as confirmed vulnerabilities, until you verify against HeartSuite’s published CVE status and config gates.

Correct verification workflow

When a scanner, auditor, or ticket queue reports a kernel CVE on a Root Lock by HeartSuite host, follow these steps in order.

Step 1: Identify the installed bundle version

Confirm which kernel is running and which HeartSuite release is installed.

uname -r

On the Root Lock by HeartSuite kernel, output ends in HeartSuite (for example, 6.18.9-HeartSuite-1.0 or 5.19.6-HeartSuite-1.0). If the string does not contain HeartSuite, you are on the maintenance kernel (Non-HS kernel) — see Distro kernel vs HS kernel below; do not apply HeartSuite CVE rules to that boot state.

Record supporting bundle identity for audits:

# Installer bundle checksum (when an update was applied)
sha256sum -c heartsuite-install.sh.sha256

# Kernel config file shipped with the running kernel (for config-gate proof)
ls /boot/config-$(uname -r)

Published SHA-256 manifests accompany distributed bundles (.sha256 files alongside heartsuite-install.sh). Each released HS kernel includes a published SHA-256 of its exact .config file — see the Auditor Brief and evidence-pack-*.txt for the reference hash for your kernel line.

Step 2: Check Kernel Security Transparency for the CVE ID

Open the Kernel Security Transparency page and search for the CVE identifier (for example, CVE-2023-2163).

If the CVE appears in a config gate group (for example, CONFIG_BPF_SYSCALL not set), follow the linked section for the full list of covered CVEs and the technical rationale.

If the CVE does not appear on the transparency page, it may be outside HeartSuite’s assessed scope, newly published, or not yet triaged. Escalate through your HeartSuite support channel and continue to use distribution errata if you are on the maintenance kernel.

Step 3: Read the published status

Interpret the entry using HeartSuite’s status categories (see the status table below). In practice you will see one of:

For disputed findings, capture a screenshot or export of the CVE row and the linked config-gate section — that is the authoritative rationale.

Step 4: Verify bundle integrity and config gates

For audit-grade evidence, confirm that the running system matches the published artefacts:

Bundle integrity (before install or for change records):

sha256sum -c heartsuite-install.sh.sha256

Config gate on the running HS kernel (configuration-level proof):

grep CONFIG_<GATE> /boot/config-$(uname -r)

Replace CONFIG_<GATE> with the gate named on the transparency page. An =n result confirms the option is not compiled in.

Example (AF_ALG / CVE-2026-31431):

$ grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
CONFIG_CRYPTO_USER_API_AEAD=n

Optionally reproduce hardening measurements with the published config SHA-256 and the open-source kernel-hardening-checker — full commands in the Auditor Brief.

Step 5: Attach audit documentation

For RFP responses, SOC 2 workpapers, PCI evidence packs, or internal risk acceptance:

1. Export or print the relevant Kernel Security Transparency section for each CVE under review.
2. Attach the Procurement Brief (posture summary and decision context).
3. Attach the Auditor Brief (threat model, residual risks, reproduction steps).
4. Include uname -r output, config-gate grep results, and bundle SHA-256 verification output from Step 1 and Step 4.
5. If the finding is a verified false positive, record it in your scanner exception register with the transparency page URL and config-gate evidence.

Status categories

HeartSuite CVE assessments use explicit categories. Map scanner severities to these before opening a patch ticket.

The transparency page applies four assessment gates in order: (1) compiled in?, (2) outbound control coverage?, (3) can an exploit program run under Lockdown?, (4) what can root do under Lockdown? See Scanner Guidance on that page for the full gate definitions.

Scanner configuration guidance

HeartSuite is designed to complement vulnerability scanners (Tenable Nessus, Qualys VMDR, Rapid7 InsightVM, Wiz, Greenbone, and similar). Scanners answer “what might be wrong across the fleet”; HeartSuite answers “what can actually be exploited on this kernel configuration, and what happens after exploitation under Lockdown.”

Do not use upstream kernel version rules for the HS kernel

• Disable or override policies that map linux_kernel package version to generic NVD CPE ranges for hosts where uname -r contains HeartSuite.
• Do not treat “kernel older than upstream fix version” as proof of exploitability on Root Lock by HeartSuite.
• Do use the Kernel Security Transparency page as the authoritative CVE status source for HS kernel boots.

Exception process for auditors

Maintain a verified false-positive register aligned with your existing distribution errata exception workflow (RHSA/RLSA on RPM systems, USN on Ubuntu, DSA on Debian, and similar):

Share this page and the transparency CVE section with scanner vendors when requesting custom CPE or rule packs.

Machine-readable feeds (JSON) and OVAL (roadmap)

HeartSuite publishes JSON advisory feeds under /advisories/:

OVAL XML for OpenSCAP is not yet published. Enterprise Linux teams on RPM-based distributions often rely on OVAL definitions (for example, Rocky org.rockylinux.rlsa-9.xml with OpenSCAP; Red Hat and SUSE publish comparable feeds) to reduce false positives. Until HeartSuite OVAL ships:

• Ingest the JSON feeds above where your platform supports them.
• Use the manual workflow in this document for HS kernel hosts and CVEs not covered by feeds.
• Continue using distribution OVAL/errata for maintenance-kernel boots and for non-kernel packages on the same host.

Feed schemas and pipeline detail: Supply Chain and Advisory Feeds.

Distro kernel vs HS kernel

Root Lock by HeartSuite installs two kernels via GRUB: the HeartSuite kernel (enforcement active) and the original maintenance kernel (Non-HS kernel — HeartSuite absent). CVE evaluation depends on which kernel booted.

During maintenance — package installs, HeartSuite bundle updates, immutable-seal removal — the system often runs on the maintenance kernel. In that window:

• Distribution kernel CVEs and errata apply to the running kernel.
• HeartSuite transparency status for the HS kernel is not the operative model for the currently running stack.
• Schedule vulnerability scans accordingly: tag scan results with kernel context (HS vs Non-HS) to avoid mixing evidence.

After reboot back to the HS kernel, re-evaluate kernel CVEs against the transparency page, not the distro errata alone.

False positive examples

These patterns account for the majority of scanner noise on HeartSuite-protected hosts.

BPF-related CVEs when CONFIG_BPF_SYSCALL=n

Scanner logic: NVD lists CVEs in the BPF verifier, BPF maps, or BPF LSM (for example, CVE-2021-20194, CVE-2023-2163, CVE-2023-39191) as affecting kernel ≤ fixed upstream version. Scanner sees 6.18.9-HeartSuite and reports Critical/High.

HeartSuite reality: CONFIG_BPF_SYSCALL is not compiled into the Root Lock by HeartSuite kernel. The bpf() syscall returns ENOSYS. There is no verifier, no program store, and no reachable path — status Not Affected for the entire BPF syscall interface group.

Proof:

$ grep CONFIG_BPF_SYSCALL /boot/config-$(uname -r)
# CONFIG_BPF_SYSCALL is not set

FUSE-related CVEs when CONFIG_FUSE_FS=n

Scanner logic: Flags CVEs in the FUSE filesystem layer (for example, CVE-2023-52504, CVE-2024-41090) based on upstream version.

HeartSuite reality: CONFIG_FUSE_FS is not compiled in. FUSE-based path confusion and mount bypass primitives are unavailable — status Not Affected for the FUSE filesystem group.

Proof:

$ grep CONFIG_FUSE_FS /boot/config-$(uname -r)
# CONFIG_FUSE_FS is not set

The general pattern

Any CVE listed under a config gate section on the transparency page follows the same pattern: if the gate is off, version-based findings are false positives until proven otherwise on the running config.

RHSA / OVAL analogy for enterprise Linux teams

If you manage enterprise Linux — whether Rocky/RHEL (RHSA, OVAL) or Ubuntu/Debian (USN, DSA) — you already verify CVEs with artefacts beyond NVD. On RHEL-family systems, the mapping looks like this:

HeartSuite does not publish RHSA-equivalent errata. The combination of CVE transparency + bundle changelog/release notes + config SHA-256 is the intended audit trail. For procurement language mapping RHEL expectations to HeartSuite deliverables, see the Enterprise Adoption Guide and Kernel Support Policy.

Audit evidence package checklist

Attach the following to RFP responses, due-diligence questionnaires, and auditor workpapers for kernel CVE posture on Root Lock by HeartSuite:

• Host context: uname -r, Lockdown state (Dashboard indicator or status.json), scan date
• Kernel line: HS kernel (transparency page) vs maintenance kernel (distro errata) — explicit label
• Procurement Brief — comparison table and buyer decision guide
• Auditor Brief — threat model, measured scores, residual risks, reproduction commands
• Kernel Security Transparency exports — one section per disputed or sampled CVE
• Config-gate evidence — grep CONFIG_* /boot/config-$(uname -r) output for compiled-out findings
• Bundle integrity — sha256sum -c heartsuite-install.sh.sha256 output (or subscription delivery record)
• Config hash match — sha256sum of /boot/config-$(uname -r) compared to published hash for that release
• False-positive register — scanner exception rows with transparency links (if applicable)
• Maintenance records — dates when Non-HS kernel was used; distro patches applied during those windows (Updating HeartSuite, Protecting During Maintenance)
• Compensating controls — Lockdown allowlist policy, SIEM/syslog integration (Alert Settings)

Nothing in this package requires trusting opaque vendor claims for measured posture: config hashes and checker outputs are reproducible on the customer side.

Related reading

• Kernel Support Policy — Patch targets, notification channels, version-string semantics
• Supply Chain and Advisory Feeds — Published JSON feeds (CONFIG SBOM, OSV, CycloneDX); OVAL and signing roadmap
• Distro Compatibility Matrix — Validated distributions and RHEL-family guidance
• Kernel Security Transparency — per-CVE status, Score on HeartSuite, config gates, scanner guidance
• Procurement Brief — hardening comparison and adoption decision guide
• Auditor Brief — threat model, residual risks, independent reproduction
• Enterprise Adoption Guide — CVE handling ownership, supply chain, fleet operations
• Updating HeartSuite — bundle application and SHA-256 verification
• Mode Switching and Lockdown — HS kernel vs maintenance kernel semantics
• How Root Lock by HeartSuite Compares — vulnerability scanners as complementary controls
• Comparison Matrix — measured attack-surface scores (5.19.6 line)

This page is intentionally scanner- and auditor-facing. All verification steps reference publicly reproducible artefacts or the open CVE transparency data. Last updated: 2026-06-22.

6 - Supply Chain and Advisory Feeds

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.

Related reading: Kernel Support Policy, Enterprise Adoption Guide, CVE Hygiene for Scanners, Evidence Status, Auditor Brief, Updating HeartSuite.

What this page covers

This page states what HeartSuite publishes today for HS kernel supply-chain verification and what is on the roadmap — without overstating availability.

It is the single reference for:

• Bundle integrity — SHA-256 checksums now; GPG and cosign signing planned.
• Bundle manifests — version identifiers, addressed CVE list, and checksum references shipped with coordinated releases.
• Reproducible configuration evidence — published .config SHA-256 per supported HS kernel stream.
• Machine-readable advisories — Published JSON feeds under /advisories/ (catalogue: hs-advisory-catalog/v1). For the current release (hs-v1.6.4-kernel-6.18.9, gate_status: PASS): CONFIG-gate Not-Affected SBOM, OSV (279 entries at /advisories/osv.json), and CycloneDX bundle SBOM. OVAL XML for OpenSCAP remains on the roadmap.
• SBOM — CycloneDX bundle SBOM published at /advisories/sbom.cyclonedx.json; SPDX dual-format support will be stated at GA.

For patch targets, notification channels, and support boundaries, see the Kernel Support Policy. For fleet deployment and buyer-facing limitations, see the Enterprise Adoption Guide.

Summary: today versus roadmap

HeartSuite does not commit to delivery dates for roadmap items on this page. When an artefact reaches general availability, this page and the Kernel Support Policy will be updated and customers will be notified through subscription email and release notes.

What you can verify today

Installer and bundle integrity (SHA-256)

Coordinated HeartSuite updates ship as a self-extracting heartsuite-install.sh bundle. Each distribution includes a companion heartsuite-install.sh.sha256 file.

Before execution, verify integrity:

sha256sum -c heartsuite-install.sh.sha256

Expected output: heartsuite-install.sh: OK

This is the only generally available cryptographic integrity check for bundles today. It confirms the file you received matches the checksum HeartSuite published for that release. It does not by itself prove publisher identity — that is why GPG and cosign are on the roadmap (see below).

Full install procedure and maintenance-window context: Updating HeartSuite.

Reproducible kernel configuration (SHA-256 per stream)

Every released HS kernel stream publishes the SHA-256 hash of the exact kernel .config used for that build. This hash is the anchor for independent hardening verification:

• Compare the published hash to the config on a running system: sha256sum /boot/config-$(uname -r)
• Re-run the open-source kernel-hardening-checker against that config to reproduce attack-surface and exploit-resistance scores (commands in the Auditor Brief)
• Cross-check stream-specific raw output in evidence-pack-*.txt artefacts referenced from the comparison and auditor pages

Config hashes are per stream (for example, 6.18 primary LTS and legacy 5.19), not a single global value. Publication status per stream is tracked in Evidence Status.

This model is intentionally reproducible on the customer side — auditors do not need to trust opaque scoring claims if they verify the hash and re-run the checker.

Kernel Security Transparency (CVE rationale)

Per-CVE status, config gates, and Score on HeartSuite are published on the Kernel Security Transparency page. This is the authoritative human-readable advisory layer for the HS kernel.

Machine-readable mirrors:

Feeds are published on this documentation site when HeartSuite cuts an annotated hs-v* kernel release. Publication is automated from HeartSuite’s internal release pipeline; customers do not need access to private build repositories to consume the feeds.

HS kernel source code (GPL)

HeartSuite distributes the HS kernel as binaries in the coordinated heartsuite-install.sh bundle. Portions of the HS kernel are subject to the GNU General Public License.

HeartSuite does not maintain a public kernel source repository at this time. Corresponding source code for the HS kernel build you are running is available on written request under GPL obligations.

Email support@heartsecsuite.com and include:

• Output of uname -r (for example, 6.18.9-HeartSuite-1.0)
• HeartSuite product version (for example, v1.6.4)
• Release tag or heartsuite-install.sh.sha256 reference if known

HeartSuite will provide source matching that build. Independent verification of kernel configuration does not require source access — use the published .config SHA-256 and reproduction steps in the Auditor Brief.

Subscription notification

Security advisories, bundle availability, and stream-deprecation notices go to contacts registered on the subscription (email), supplemented by release notes on this site. See Customer notification in the Kernel Support Policy.

Bundle manifest

Each coordinated release is accompanied by a bundle manifest (shipped with the bundle or referenced in release documentation). Manifests are the release-level changelog for procurement and vulnerability-management traceability.

Published fields (today)

Manifests do not replace the Kernel Security Transparency page for reachability analysis. A CVE omitted from the “addressed” list may still be Not Affected on HS kernels because the vulnerable subsystem was never compiled in.

Planned manifest extensions

When signing and SBOM artefacts ship, manifests will add non-breaking references:

• GPG key fingerprint and signature file location
• Cosign bundle signature digest (OCI/sigstore-style provenance)
• SBOM document URI and format (SPDX or CycloneDX)

Existing SHA-256 verification remains valid for customers who have not yet adopted the new artefacts.

Roadmap: GPG and cosign signed bundles

Today: Integrity is SHA-256 only — detect accidental corruption or tampering in transit if you verify against the published checksum before execution.

Planned:

What HeartSuite is not claiming yet:

• No published GPG public key or cosign policy on this site today.
• No requirement that customers use signing before install — SHA-256 verification remains the baseline until signing is generally available.
• Signing addresses publisher authenticity and pipeline integration; it does not change the HS kernel’s CVE reachability model or Lockdown semantics.

Teams with mandatory code-signing policies should treat SHA-256 + config-hash verification as the current interim control and engage HeartSuite support for questionnaire language until GPG/cosign GA.

Published advisory feeds (HS kernel)

Enterprise Linux teams often use OVAL definitions with OpenSCAP, or OSV entries in broader SCA tooling, to reduce false positives from raw NVD version matching.

Published today (JSON under /advisories/, absolute base https://docs.heartsecsuite.com/advisories/):

For release tag hs-v1.6.4-kernel-6.18.9 (gate_status: PASS in the catalogue):

• index.json — Feed catalogue (hs-advisory-catalog/v1) with release tag, HeartSuite version, kernel base, and per-feed published flags.
• hs-cve-config-sbom.json — CONFIG-gate Not-Affected manifest (hs-cve-config-sbom/v1) produced by the CVE↔CONFIG crosswalk gate in Core Secure CI.
• osv.json — 279 OSV entries derived from the CONFIG SBOM and transparency page (alias of osv/all.json).
• sbom.cyclonedx.json — CycloneDX bill of materials for the coordinated bundle.

Not yet published: OVAL XML for OpenSCAP. Teams that require OVAL today should ingest the published CONFIG SBOM and OSV feeds, plus the manual workflow in CVE Hygiene for Scanners.

Scanners that compare uname -r to upstream “fixed in” versions will still generate noise on HS kernel boots until your toolchain consumes these feeds or the manual hygiene workflow.

What the feeds encode

The feeds encode logic that version strings alone cannot express:

The feeds do not replicate RHSA numbering or distribution errata semantics. HeartSuite remediation is expressed through coordinated bundles and transparency documentation, not per-CVE RPM errata on the HS binary.

Automation workflow

1. Pull the catalogue: curl -fsS https://docs.heartsecsuite.com/advisories/index.json
2. Ingest hs-cve-config-sbom.json and osv.json into your vulnerability-management platform.
3. For CVEs not covered by machine-readable entries, use CVE Hygiene for Scanners:
   • Confirm boot context (HeartSuite in uname -r vs maintenance kernel).
   • Look up the CVE on Kernel Security Transparency.
   • Verify config gates with grep CONFIG_* /boot/config-$(uname -r).
   • Record false positives in your scanner exception register with transparency links.

Continue using distribution OVAL/errata for Non-HS kernel maintenance windows and for non-kernel packages.

OVAL XML general availability will be announced in release notes when ready.

SBOM (CycloneDX published; SPDX at GA)

Published: CycloneDX bundle SBOM at /advisories/sbom.cyclonedx.json for hs-v1.6.4-kernel-6.18.9 (published: true on the cyclonedx-sbom entry in /advisories/index.json).

Scope (CycloneDX generator):

• Coordinated bundle contents — HS kernel binary, userspace daemon/Dashboard/tools, and installer dependencies relevant to the enforcement stack.
• Linkage: Bundle manifest references the SBOM URL; catalogue records release tag and HeartSuite version.

Roadmap: SPDX and/or dual SPDX+CycloneDX support will be stated at GA if offered.

Complementary artefacts (always available):

• Published kernel .config SHA-256 and evidence-pack-*.txt for reproducible hardening measurement (5.19.6 published; 6.18.9 in progress — see Evidence Status)
• CONFIG-gate SBOM at /advisories/hs-cve-config-sbom.json
• Bundle SHA-256 manifests
• CVE transparency and bundle manifest CVE lists

SBOM publication improves dependency inventory and procurement automation; it does not replace config-gate CVE analysis for the HS kernel.

Mapping to common procurement questions

What HeartSuite does not provide (supply-chain scope)

To set expectations for RFPs and vendor-risk assessments:

If a control framework requires GA OVAL feeds or GPG/cosign signing before production approval, plan for the interim artefacts in this document and document compensating controls (published JSON feeds, manual CVE hygiene, config-hash verification, bundle manifest retention) until roadmap items ship.

Related reading

• Kernel Support Policy — Patch targets, bundle delivery, notification, version strings, and “does not provide” boundaries.
• Evidence Status — 5.19.6 vs 6.18.9 publication status.
• Enterprise Adoption Guide — Fleet operations, supply-chain summary, Secure Boot status, and honest limitations.
• CVE Hygiene for Scanners — HS kernel CVE verification; ingest published OSV/CONFIG SBOM feeds; OVAL interim workflow.
• Auditor Brief — Threat model, reproduction commands, evidence packs.
• Distro Compatibility Matrix — Stream and distribution validation.
• Kernel Security Transparency — Per-CVE status and config gates.
• Updating HeartSuite — Bundle verification and two-reboot update path.

This page is procurement- and GRC-facing. Availability statements reflect public deliverables as of the last-updated date; roadmap items have no committed GA dates unless separately agreed in writing. Last updated: 2026-06-23.

7 - Kernel Evidence Status

Subject: Root Lock by HeartSuite HS kernel evidence parity
Commercial baseline: HeartSuite v1.6.4 — kernel 6.18.9 (6.18.9-HeartSuite-1.0)
Legacy stream: kernel 5.19.6 (maintenance-only; see Kernel Support Policy)

Summary

HeartSuite ships two HS kernel lines with the same Root Lock enforcement contract. New subscriptions and fleet images should standardize on 6.18. Public hardening evidence for that stream is being brought to parity with the 5.19.6 publication; until then, procurement and audit teams should treat 5.19.6 measurements as illustrative of design philosophy, not as a score-for-score substitute for 6.18.9.

What is published today (5.19.6)

The following artifacts are complete and independently reproducible:

• Config identity — SHA-256 for config-5.19.6-HeartSuite-1.0 and config-5.19.6-HeartSuite-2.0 in evidence-pack-5.19.6.txt
• Automated scores — kernel-hardening-checker commit b9b83a0, era-matched comparison against Arch linux-hardened 5.19.11 and vanilla defconfig, in kernel-comparison-matrix-5.19.6.md
• Runtime posture — module inventory, SELinux permissive state, HeartSuite enforcement trace, bypass-primitive grep results (sections 2–5 of the evidence pack)
• Buyer and auditor summaries — Procurement Brief and Auditor Brief (detailed measured sections currently reference 5.19.6 data)

What is in progress (6.18.9)

The 6.18 LTS port closed known gaps documented for 5.19.6 — notably CONFIG_IO_URING and CONFIG_KEXEC are disabled in the 6.18.x HS config (design intent recorded in the deviation registry). Public publication still requires:

1. Canonical config SHA-256 for config-6.18.9-HeartSuite-1.0 (and any subsequent bundle revision)
2. evidence-pack-6.18.9.txt — raw checker output, per-category scores, bypass-primitive verification, module inventory, runtime LSM state
3. Era-matched comparison — HS 6.18.9 vs Arch linux-hardened (or equivalent) on the same 6.18.x Kconfig namespace
4. Runtime verification — uname -r, /boot/config-* hash match, lsmod, SELinux state, HeartSuite activation in dmesg on a representative validated distribution

The Kernel Hardening Comparison Matrix (6.18.9) page mirrors the 5.19.6 structure. Sections that depend on measured output are marked Pending publication — engage support for pre-release evidence until the artifacts above are released.

Evidence parity roadmap

For procurement and audit teams

Evaluating a 6.18.9 deployment today

• Use Distro Compatibility Matrix and Kernel Support Policy for support boundaries, version strings, and patch targets.
• Use CVE Hygiene for Scanners for vulnerability-management workflows — do not infer HS reachability from upstream 6.18.9 alone.
• For hardening scores comparable to the 5.19.6 publication, request pre-release evidence through your HeartSuite support channel. Reference HeartSuite v1.6.4 / tag hs-v1.6.4-kernel-6.18.9 and the expected version string 6.18.9-HeartSuite-1.0.

Evaluating a 5.19.6 legacy fleet

• Full public evidence remains authoritative for that stream. Plan migration to 6.18 per the support policy; do not extend 5.19.6 checker scores to 6.18.9 without the published 6.18 pack.

Reproducing 5.19.6 measurements now

See Auditor Brief for kernel-hardening-checker commands and expected SHA-256.

Related pages

• Kernel Hardening Comparison Matrix (6.18.9) — primary stream structure (measured sections pending)
• Kernel Hardening Comparison Matrix (5.19.6) — legacy stream, fully measured
• Enterprise Adoption Guide — supply chain, verification, and regulated-deployment context

8 - Kernel Hardening Comparison Matrix (6.18.9)

Subject: Root Lock by HeartSuite, kernel 6.18.9 (HeartSuite v1.6.4 commercial baseline)
Expected version string: 6.18.9-HeartSuite-1.0
Config SHA-256: Pending publication — engage support for pre-release evidence
Tool: kernel-hardening-checker — commit and run date pending publication
Source file: evidence-pack-6.18.9.txt (not yet published; see Evidence Status)
Legacy reference (published): Kernel Hardening Comparison Matrix (5.19.6), evidence-pack-5.19.6.txt

Publication note: This page mirrors the structure of the 5.19.6 matrix so procurement and audit teams know what evidence to expect. Numeric scores, config hashes, and runtime measurements for 6.18.9 are in progress. Sections marked Pending publication will be replaced with measured values when evidence-pack-6.18.9.txt ships.

Part 1 — Measured comparison (same kernel era)

All configs in this section must be built from the 6.18.x kernel tree for scores to be directly comparable — same Kconfig namespace, same option universe as the HS 6.18.9 commercial baseline.

Reading the table

• Attack-surface measures how many dangerous kernel features are disabled. Higher = more things turned off.
• Exploit-resistance measures how many defensive mitigations against memory bugs are enabled. Higher = harder to exploit.
• These two axes are largely independent and optimized for different threat models.
• Do not compare 5.19.6 published scores to 6.18.9 placeholders — kernel generations use different Kconfig option sets and checker item counts.

What this will show (when published)

Based on HS design intent and the published 5.19.6 analysis, the 6.18.9 era-matched run is expected to demonstrate:

• Continued attack-surface leadership on bypass-primitive disables (BPF_SYSCALL, FUSE_FS, OVERLAY_FS, alt-LSMs, USER_NS, and related subsystems).
• Improved bypass coverage vs 5.19.6 — CONFIG_IO_URING and CONFIG_KEXEC are disabled in the 6.18.x HS config (both remained enabled in 5.19.6; see evidence-pack-5.19.6.txt section 3).
• Exploit-resistance likely remains near the vanilla upstream baseline for the 6.18 line unless a future release explicitly adopts additional KSPP-style mitigations — to be confirmed by measured checker output.

Pending publication — engage support for pre-release evidence.

Bypass-primitive disables — side by side

Checker-verified 6.18.9 column values and Arch linux-hardened 6.18.x reference column: Pending publication — engage support for pre-release evidence.

Exploit-resistance mitigations — side by side

Part 2 — Qualitative orientation (cross-project)

These projects were not scored with the checker in the pending 6.18.9 analysis pass — either because their configs were unavailable for automated download, because they are paywalled, or because a meaningful era-matched config was not yet selected. Characterizations follow each project’s public documentation and design goals. HS 6.18.9 row incorporates known port deltas vs 5.19.6; checker-backed claims await publication.

Notes on the qualitative table:

• “Bypass Prevention” = removal of subsystems that can circumvent MAC/LSM enforcement.
• “Exploit Resistance” = mitigations against kernel memory bugs (heap, stack, pointer corruption).
• Only HeartSuite 5.19.6 scores in this section are fully checker-backed today. HeartSuite 6.18.9 qualitative row will be reconciled against measured output when the evidence pack publishes.

Part 3 — LSM stack and module count (measured)

Design invariant (unchanged from 5.19.6): HeartSuite is the first and final enforcement authority; competing MAC frameworks are not enabled for enforcement. Runtime proof for 6.18.9 awaits the evidence pack.

Part 4 — CPU mitigations (6.18 naming)

Linux 6.18 uses the post-6.1 CONFIG_MITIGATION_* option names. The checker should report these directly (unlike 5.19.6, where legacy option names caused false FAILs). Published 6.18.9 values will list confirmed =y mitigations from the canonical config.

Pending publication — engage support for pre-release evidence.

Summary

For the complete published legacy dataset, see Kernel Hardening Comparison Matrix (5.19.6). For publication timeline and pre-release evidence access, see Evidence Status.

9 - Kernel Hardening Comparison Matrix

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

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.

Reading the table

• Attack-surface measures how many dangerous kernel features are disabled. Higher = more things turned off.
• Exploit-resistance measures how many defensive mitigations against memory bugs are enabled. Higher = harder to exploit.
• These two axes are largely independent and optimized for different threat models.

What this shows

HS leads on attack-surface (91 vs 77 vs 90): it disables BPF_SYSCALL, FUSE_FS, OVERLAY_FS, SECURITY_APPARMOR, SECURITY_TOMOYO, and USER_NS — all of which Arch linux-hardened keeps enabled for its general-purpose user base.

Arch linux-hardened leads on exploit-resistance (69 vs 31): it enables HARDENED_USERCOPY, FORTIFY_SOURCE, INIT_ON_ALLOC_DEFAULT_ON, INIT_ON_FREE_DEFAULT_ON, SLAB_FREELIST_RANDOM, and MODULE_SIG — all absent in HS 5.19.6.

Vanilla defconfig is the baseline: it does about as well as HS on attack-surface (most things aren’t enabled by default) but even worse on exploit-resistance.

Bypass-primitive disables — side by side

HS: 5/8 disabled. Arch lh: 3/8 disabled (different 3). Neither disables all eight.

Exploit-resistance mitigations — side by side

Part 2 — Qualitative orientation (cross-project)

These projects were not scored with the checker in this analysis — either because their configs were unavailable for the 5.19 era, because they are paywalled, or because a meaningful config was not locatable. Characterizations are drawn from each project’s public documentation and design goals.

Notes on the qualitative table:

• “Bypass Prevention” = removal of subsystems that can circumvent MAC/LSM enforcement.
• “Exploit Resistance” = mitigations against kernel memory bugs (heap, stack, pointer corruption).
• NixOS linux_hardened was removed from nixpkgs in 2025 due to lack of maintenance — it is no longer an active project. The bundled config in kernel-hardening-checker (6.12.50-hardened1) is a historical snapshot.
• CLIP OS: the public CLIP OS project is archived. The ANSSI team published their kernel configs; they are accessible at the archived CLIP OS documentation.
• grsecurity requires a paid subscription; their config is not publicly available for automated analysis.
• GrapheneOS targets Android hardware (aarch64); its hardening is not directly applicable to x86 server deployments.

Part 3 — LSM stack and module count (measured)

Part 4 — CPU mitigations (5.19.6 naming)

5.19.6 uses pre-6.1 option names. Checker reports these as FAIL (uses the 6.1+ CONFIG_MITIGATION_* names). Mitigations confirmed present:

Summary

10 - Security Auditor Brief: Kernel Hardening Posture

Subject: Root Lock by HeartSuite HS kernel — 6.18.9 primary (commercial baseline, HeartSuite v1.6.4), 5.19.6 legacy
Evidence status: Published config SHA-256, checker output, and runtime verification exist for the 5.19.6 stream only. The 6.18.9 stream is the current commercial baseline (6.18.9-HeartSuite-1.0); measured evidence is in progress — see Evidence Status.
Primary stream (6.18.9): Kernel Hardening Comparison Matrix (6.18.9) — structure published; scores pending
Legacy stream (5.19.6): Config SHA-256 d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc — measured 2026-05-19, kernel-hardening-checker commit b9b83a0 — comparison matrix, evidence-pack-5.19.6.txt

The threat model and measured sections below describe the published 5.19.6 dataset until evidence-pack-6.18.9.txt replaces them. Design intent for 6.18.9 includes disabling CONFIG_IO_URING and CONFIG_KEXEC (both enabled in 5.19.6).

Threat Model

HeartSuite’s kernel hardening targets one specific threat: a process on the protected system attempting to bypass the kernel module’s VFS-level enforcement. The design choice is to remove the kernel features that make bypass possible, rather than to harden the kernel against general exploitation.

What the measurements show

Attack-surface reduction

Automated score: 91/132 (68.9%)
Reference points (era-matched, same 5.19.x kernel generation): Arch linux-hardened 5.19.11: 77/132 (58.3%). Vanilla upstream defconfig 5.17: 90/132 (68.2%). KSPP target (6.17, version-agnostic intent): 131/132 (99.2%).

HS outperforms production distros and common hardened-distro kernels on this axis. The reason: HS disables BPF_SYSCALL, USER_NS, FUSE_FS, OVERLAY_FS, APPARMOR, TOMOYO, and ~25 additional network/crypto/debug subsystems that Arch and NixOS keep enabled for their general-purpose user bases. These are the subsystems with the most relevant LSM-bypass CVE history.

Caveat: the automated checker scores vanilla 5.17 defconfig at 90/132, nearly identical to HS. This is because the checker does not distinguish intentionally hardened to a value from never configured to begin with. The vanilla defconfig also doesn’t enable BPF or AppArmor by default. The operational difference is enforcement: a production system built on a vanilla defconfig will have these features added over time; HS’s build procedure enforces the disables regardless.

Exploit-resistance (KSPP-style mitigations)

Automated score: 31/109 (28.4%)
Reference points (era-matched): Arch linux-hardened 5.19.11: 69/109 (63.3%). Vanilla upstream defconfig 5.17: 29/109 (26.6%). KSPP target (6.17): 93/109 (85.3%).

HS’s exploit-resistance posture is at the vanilla upstream baseline. It does not add INIT_ON_ALLOC_DEFAULT_ON, HARDENED_USERCOPY, FORTIFY_SOURCE, SLAB_FREELIST_RANDOM, KFENCE, RANDSTRUCT_FULL, KSTACK_ERASE, MODULE_SIG, or the other ~57 KSPP mitigations that dedicated hardened kernels enable.

Residual risks

1. Kernel memory corruption / exploitation
HS provides no additional protection beyond vanilla upstream defaults for heap-based exploits (use-after-free, double-free, type confusion). An attacker who can reach a vulnerable in-kernel code path with sufficient primitive quality has no extra mitigations to contend with beyond STACKPROTECTOR_STRONG, KASLR, RANDOMIZE_MEMORY, and STRICT_KERNEL_RWX — all of which are vanilla defaults.

Attack path: Any reachable kernel vulnerability with reliable heap-layout control.

2. SELinux runtime state — verified permissive
CONFIG_SECURITY_SELINUX=y with CONFIG_DEFAULT_SECURITY_SELINUX=y. SELinux is compiled-in. Runtime verification on the test VM (2026-05-19) shows:

• /sys/fs/selinux/enforce = 0 — permissive mode, no policy loaded
• /proc/self/attr/current = kernel — initial context, no confinement active
• securityfs is not mounted (no /sys/kernel/security/lsm file)

SELinux initializes at boot but does not enforce. HeartSuite is the sole enforcing MAC LSM. dmesg confirms HeartSuite is enforcing within 4 seconds of boot.

Residual note for production: this relies on runtime service configuration keeping SELinux permissive. Verify cat /sys/fs/selinux/enforce = 0 on each production deployment. A loaded SELinux policy that flips to enforcing mode would add a competing LSM to the stack.

3. MODULE_SIG not enforced
CONFIG_MODULE_SIG=n. Kernel module signing is not enforced. A root-level attacker can load an arbitrary unsigned kernel module, including one that unloads or bypasses HeartSuite’s VFS hooks.

Mitigating factor: Lockdown’s kmod block (when engaged) prevents loading additional modules post-Lockdown. This is an operator-procedure-dependent mitigation, not a config-enforced one.

How to reproduce these measurements

Run on any Linux host with Python 3:

# Clone the checker
git clone --depth 1 https://github.com/a13xp0p0v/kernel-hardening-checker /tmp/khc

# Obtain the HS config (from the HS 5.19.6 kernel package)
# Verify: sha256sum config-5.19.6-HeartSuite-1.0
# Expected: d67caa637263c33ce939b7eef867f0695d60d11d285d6694a7f5567e73ba6fbc

# Run
python3 /tmp/khc/bin/kernel-hardening-checker -c config-5.19.6-HeartSuite-1.0

# Expected summary: OK - 129 / FAIL - 129

To verify the bypass-primitive disables directly:

grep -E "^(CONFIG_BPF_SYSCALL|CONFIG_FUSE_FS|CONFIG_OVERLAY_FS|\
CONFIG_SECURITY_APPARMOR|CONFIG_SECURITY_TOMOYO)" \
  config-5.19.6-HeartSuite-1.0

To verify LSM state on a running HeartSuite VM:

cat /sys/kernel/security/lsm
cat /proc/cmdline

11 - LSM Comparison: HeartSuite vs SELinux, AppArmor, and TOMOYO

Subject: Root Lock by HeartSuite, kernel 5.19.6
Audience: Security engineers familiar with SELinux, AppArmor, or TOMOYO evaluating HeartSuite 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?

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

This is not a claim that one approach is universally superior. For single-purpose containment appliances, removing bypass primitives from the kernel is more reliable than writing policy around them — because policy can be misconfigured, and because certain primitives (BPF, FUSE, overlayfs) can defeat any MAC policy regardless of how carefully it is written.

Comparison Table

Bypass primitives: open vs closed

The table below lists the kernel-level bypass vectors most relevant to MAC enforcement. “Closed” means the kernel option is disabled — the attack vector does not exist on the system. “Open” means the feature is present and policy must account for it.

An attacker who can reach any “Open” primitive has a path to bypass LSM enforcement regardless of how well the policy is written. HeartSuite closes all four vectors above at the kernel config level.

When SELinux, AppArmor, or TOMOYO is the right choice

HeartSuite is not a general-purpose MAC replacement. Choose SELinux, AppArmor, or TOMOYO when:

• You are running a general-purpose multi-user system where diverse workloads need fine-grained per-process policy.
• You require MLS / MCS (Multi-Level Security / Multi-Category Security) for labeled data separation.
• You need container runtime support that depends on USER_NS or overlayfs (Kubernetes, Docker, Podman, LXC).
• Your compliance framework mandates a specific named LSM (e.g., STIG-mandated SELinux).
• You need to audit permitted accesses, not just denials — HeartSuite logs every denied file access, socket connection, and sandbox violation with the specific program path and target resource, but successful accesses are not logged. SELinux and TOMOYO can record both. If a full allowed-access trail is also required, SELinux can run alongside HeartSuite on supported deployments — see Co-existence.

When HeartSuite is the right choice

Choose HeartSuite when:

• You are deploying a single-purpose appliance running one or a small set of known workloads.
• Your threat model centers on containment escape — a compromised application attempting to break out of its enforcement boundary.
• You want zero policy surface — no policy file, no audit2allow, no profile to misconfigure.
• BPF tooling, container runtimes, FUSE mounts, and user namespaces are not part of the system’s attack surface — they are absent from the kernel, not restricted by policy.
• You want a violation-focused audit trail: every denied file access, network connection, and sandbox violation is logged with the specific program path and target resource. In Setup Mode, would-be denials are logged and permitted simultaneously — giving full visibility into the policy surface without blocking anything.
• You want independent verifiability: the kernel config SHA-256 is published and measurements are reproducible with an open-source tool.

Co-existence

HeartSuite does not stack with AppArmor or TOMOYO. Both are kernel-disabled (CONFIG_SECURITY_APPARMOR=n, CONFIG_SECURITY_TOMOYO=n).

SELinux behaves differently depending on the deployment OS:

HeartSuite’s VFS hooks fire before the LSM chain (security_path_*() calls). The ordering means:

• If HeartSuite denies an operation → the SELinux hook is never reached. HeartSuite is the first and final authority on that call.
• If HeartSuite allows an operation → SELinux can still deny it. SELinux can only add restrictions to what HeartSuite allows, never grant access HeartSuite denies.

This is intentional and safe. On RHEL/Fedora, SELinux is Enforcing by default; the stacking is additive, not conflicting. On Debian/Ubuntu, no SELinux policy is loaded by default. Either way, HeartSuite’s enforcement cannot be bypassed via the SELinux layer.

RHEL operational note: As with any new kernel module on RHEL, a targeted SELinux policy entry may be needed for HeartSuite’s specific operations. If AVC denials appear, ausearch -m AVC -ts recent | audit2why identifies them and audit2allow generates the targeted module. HeartSuite’s enforcement is unaffected — SELinux operates after HS in the hook chain and cannot override HS decisions.

Further reading

• Comparison Matrix — Measured kernel-hardening-checker scores: HeartSuite vs Arch linux-hardened vs vanilla defconfig.
• Auditor Brief — Residual risks, threat model, and self-reproduction instructions.
• Procurement Brief — Decision guide for buyers choosing between hardened kernel options.

12 - Analyst Summary: HeartSuite Kernel Hardening

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

HeartSuite’s Linux kernel contains just 9 loadable modules — compared to 3,500 to 4,000 in a standard Debian Linux system. This isn’t because the system is less capable; it’s because the kernel was built for one job and nothing else was included.

The approach extends beyond raw module count. HeartSuite disables specific kernel features that security researchers have identified as the most common paths for bypassing security controls: BPF (a programmable kernel interface), FUSE (user-space filesystems), overlay filesystems, and all competing security policy engines including AppArmor and SELinux. Each of these has been used in documented real-world attacks to escape software sandboxes or override security policies.

On an independent audit using the open-source kernel-hardening-checker tool — the same tool used by Linux kernel security researchers — HeartSuite’s kernel outperforms the Arch Linux hardened kernel on attack-surface measures: 91 out of 132 checks passed by HeartSuite versus 77 out of 132 for Arch linux-hardened (compared on the same 5.19.x kernel generation, making scores directly equivalent). Arch linux-hardened scores lower on this axis because it keeps features like BPF, FUSE, and AppArmor enabled — features that its general-purpose users depend on, but that also provide paths for bypassing security controls.

Where HeartSuite is not strongest: Exploit resistance. When a kernel vulnerability is discovered — a memory bug, a logic flaw — certain protection techniques make it much harder to turn that bug into a working attack. HeartSuite’s kernel does not include most of these techniques, scoring 31 out of 109 checks on this measure. The era-matched Arch linux-hardened kernel (same kernel generation) scores 69 out of 109 on the same tool. HeartSuite is designed to prevent attacks from bypassing its controls — not to harden against every possible kernel vulnerability.

The configuration is publicly verifiable. The SHA-256 hash of the kernel configuration file is published, and any qualified security team can reproduce the measurements above using publicly available tools.

For fact-checkers: All numbers in this summary derive from evidence-pack-5.19.6.txt and kernel-comparison-matrix-5.19.6.md in this same document section. Tool: kernel-hardening-checker at commit b9b83a0. Every claim can be independently reproduced.