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.