Your scanner flags CVEs this kernel does not have

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

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

Related reading: Start with Kernel Security Transparency (per-CVE status and rationale), the Procurement Brief (posture at a glance), and the Threat model (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 does not ship a vanilla upstream kernel. It ships a custom configuration on an LTS base (mainline 6.18.9; uname -r is 6.18.9-hs).

The version string tells you the LTS line. 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-hs, 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) or Score on Root Lock 0.0 (environmental neutralisation). A reachable CVE is not that answer. An in-kernel finding, or a bug that finishes inside an existing grant, stays on the patch date.

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 Root Lock 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 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 kernel that ships, uname -r is 6.18.9-hs. The 5.19 line can show a HeartSuite suffix (for example, 5.19.6-HeartSuite-1.0). A distribution string that is neither 6.18.9-hs nor a HeartSuite suffix is the maintenance kernel — see Distro kernel vs Root Lock 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 Root Lock kernel includes a published SHA-256 of its exact .config file — see the Threat model 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. Email support@heartsecsuite.com 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 kernel you boot:

Read the transparency row for that CVE. The build configuration published for the kernel you boot is the proof. The guest file /boot/config-6.18.9-hs is a stub. See Evidence Status.

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

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 Threat model (threat model, residual risks, reproduction steps).
4. Include uname -r output and the bundle SHA-256 verification from Step 1.
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 word you file is Not affected, Affected, or Fixed, as on Kernel Security Transparency. When the program that reaches the bug has no allowlist entry, that program does not run and the catalog prints 0.0. The catalog also prints 0.0 when the hardware the bug needs is not present. Approving the program makes that row Affected. Not affected is an unset option. An Affected row stays on the patch date.

The transparency page applies four assessment gates in order. That is how the row was checked, not the word you file: (1) compiled in?, (2) outbound control coverage?, (3) does the program that reaches the bug have an allowlist entry?, (4) what can root do under Lockdown? See Scanner Guidance on that page for how a row was checked. Catalog: Compiled-in CVEs, Disabled features.

Scanner configuration guidance

Root Lock 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.” Root Lock 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 Root Lock kernel

• Disable or override policies that map linux_kernel package version to generic NVD CPE ranges for hosts where uname -r is 6.18.9-hs or contains HeartSuite.
• Do not treat “kernel older than upstream fix version” as proof of exploitability on Root Lock.
• Do use the Kernel Security Transparency page as the authoritative CVE status source for Root Lock 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 Root Lock 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 Root Lock kernel

Root Lock installs two kernels via GRUB: the Root Lock kernel (enforcement active) and the original maintenance kernel (a distribution uname, not 6.18.9-hs). 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 Root Lock kernel does not describe the kernel that is running.
• Schedule vulnerability scans accordingly: tag scan results with kernel context (Root Lock kernel vs maintenance kernel) to avoid mixing evidence.

After reboot back to the Root Lock 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. For each one, the proof is the pin config — the build configuration published for the kernel you boot — not a grep on the host, because the guest file /boot/config-6.18.9-hs is a stub. See Evidence Status.

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-hs and reports Critical/High.

HeartSuite reality: CONFIG_BPF_SYSCALL is unset on 5.19.6 and on the 6.18.9-hs kernel that ships. The bpf() syscall returns ENOSYS. There is no verifier, no program store, and no reachable path — status Not Affected for the BPF syscall interface group. CONFIG_BPF=y stays built in. This covers the syscall entry point.

FUSE-related CVEs

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

HeartSuite reality: On the 6.18.9-hs kernel that ships, CONFIG_FUSE_FS=y, so these findings are real and stay on the patch date. They are false positives only on a kernel where CONFIG_FUSE_FS is unset. See the FUSE filesystem group.

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:

• Host context: uname -r, Lockdown state (Dashboard indicator or status.json), scan date
• Kernel line: Root Lock kernel (transparency page) vs maintenance kernel (distro errata) — explicit label
• Procurement Brief — comparison table and buyer decision guide
• Threat model — threat model, measured scores, residual risks, reproduction commands
• Kernel Security Transparency exports — one section per disputed or sampled CVE
• Config-gate evidence — the transparency row for that CVE. On the 6.18.9-hs kernel that ships, CONFIG_FUSE_FS=y, so FUSE findings stay on the patch date. See FUSE-related CVEs.
• Bundle integrity — sha256sum -c heartsuite-install.sh.sha256 output (or subscription delivery record)
• Config hash match — the published hash for the kernel you boot, in Evidence Status. The guest file /boot/config-6.18.9-hs is a stub.
• False-positive register — scanner exception rows with transparency links (if applicable)
• Maintenance records — dates when the maintenance kernel was used; distro patches applied during those windows (Updating Root Lock, 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 Root Lock, config gates, scanner guidance
• Procurement Brief — hardening comparison and adoption decision guide
• Threat model — threat model, residual risks, independent reproduction
• Enterprise Adoption Guide — CVE handling ownership, supply chain, fleet operations
• Updating Root Lock — bundle application and SHA-256 verification
• Lockdown — Root Lock kernel vs maintenance kernel semantics
• How Root Lock 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.