# CVE Hygiene for Scanners and Auditors

> How enterprise Linux security teams verify Root Lock by HeartSuite kernel CVE status without false positives from upstream version comparison — correct workflow, status categories, scanner configuration, maintenance-kernel exceptions, and audit evidence.

---

LLMS index: [llms.txt](/llms.txt)

---

**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](../../security/) (per-CVE status and rationale), the [Procurement Brief](procurement-brief/) (posture at a glance), and the [Auditor Brief](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](../../security/) 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.

```bash
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](#distro-kernel-vs-hs-kernel) below; do not apply HeartSuite CVE rules to that boot state.

Record supporting bundle identity for audits:

```bash
# 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](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](../../security/) 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](../../security/#bpf-syscall-interface)), 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](#status-categories) below). In practice you will see one of:

| What you read on the page | What it means for the finding |
|---------------------------|-------------------------------|
| **Not Affected** — `CONFIG_*` not set | Vulnerable subsystem not compiled in; scanner false positive if based on version only |
| **Score on HeartSuite 0.0** | Environmental or architectural neutralisation (hardware absent, trigger not present, chain broken) |
| **Reachable** with non-zero Score on HeartSuite | Code path exists; document bounded impact under Lockdown and any residual confidentiality/availability notes |
| **Fixed in bundle** (when noted) | HeartSuite release incorporates an upstream or targeted fix; verify your `uname -r` matches the stated bundle |

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):

```bash
sha256sum -c heartsuite-install.sh.sha256
```

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

```bash
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`):

```bash
$ 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](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](../../security/) section for each CVE under review.
2. Attach the [Procurement Brief](procurement-brief/) (posture summary and decision context).
3. Attach the [Auditor Brief](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.

| Status | Meaning | Typical scanner behaviour | Auditor action |
|--------|---------|---------------------------|----------------|
| **Not Affected (compiled out)** | `CONFIG_*` option not set; vulnerable code is absent from the kernel binary | Flags anyway — compares upstream version only | Mark false positive; attach config-gate `grep` and transparency link |
| **Neutralized (Score on HeartSuite 0.0)** | Code may exist upstream, but environmental gates apply (no hardware, no trigger, broken exploit chain, allowlist blocks required tools) | Often flags at Base Score severity | Mark false positive or accepted risk with 0.0 environmental score rationale |
| **Reachable (bounded by Lockdown)** | Vulnerable code path exists; post-exploitation impact bounded — no new program execution, no persistence across reboot, no allowlist modification under Lockdown | May under-state impact if it assumes full root freedom | Document bounded impact; retain in risk register with HeartSuite compensating controls |
| **Fixed in bundle** | Addressed in a specific HeartSuite kernel/userspace release (backport or rebase) | May still flag until scanner rules updated | Verify `uname -r` and bundle version; apply [Updating HeartSuite](../../maintenance/updating-heartsuite/) if behind |

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](../../security/#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](../../security/) 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):

| Field | Example |
|-------|---------|
| CVE ID | CVE-2023-2163 |
| Scanner finding | Critical — kernel 6.18.9 vulnerable |
| Host kernel | `6.18.9-HeartSuite-1.0` |
| HeartSuite status | Not Affected — `CONFIG_BPF_SYSCALL` not set |
| Evidence | `grep CONFIG_BPF_SYSCALL /boot/config-...` → `n`; transparency page BPF section |
| Reviewer / date | VM team, 2026-06-22 |
| Re-review trigger | HeartSuite bundle upgrade or transparency page update |

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/`](/advisories/index.json):

| Feed | URL | Role |
|------|-----|------|
| Catalogue | [`/advisories/index.json`](/advisories/index.json) | Release tag (`hs-v1.6.4-kernel-6.18.9`), `gate_status`, feed list |
| CONFIG-gate SBOM | [`/advisories/hs-cve-config-sbom.json`](/advisories/hs-cve-config-sbom.json) | Validated `CONFIG_*` not-set claims per CVE group |
| OSV | [`/advisories/osv.json`](/advisories/osv.json) | 279 OSV entries (alias of `osv/all.json`) for config-gated Not-Affected CVEs |
| CycloneDX SBOM | [`/advisories/sbom.cyclonedx.json`](/advisories/sbom.cyclonedx.json) | Coordinated bundle bill of materials |

**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](supply-chain-and-advisories/#published-advisory-feeds-hs-kernel).

---

## 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.

| Boot state | `uname -r` pattern | CVE source of truth |
|------------|-------------------|---------------------|
| **HS kernel** (Setup Mode or Lockdown) | Contains `HeartSuite` | [Kernel Security Transparency](../../security/) + config gates |
| **Maintenance kernel** (Non-HS) | Distribution kernel string (no `HeartSuite` suffix) | **Distribution** CVE/errata — RHSA/RLSA, `dnf updateinfo`, Ubuntu USN, Debian DSA, etc. |

During [maintenance](../../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](../../security/#bpf-syscall-interface).

**Proof**:

```bash
$ 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](../../security/#fuse-filesystem).

**Proof**:

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

### The general pattern

| Scanner assumption | HeartSuite counter-check |
|--------------------|--------------------------|
| Version string ⇒ same code as upstream | Read `CONFIG_*` gate on transparency page |
| High Base Score ⇒ high risk on host | Read **Score on HeartSuite** (environmental CVSS) |
| Root compromise ⇒ full persistence | Under Lockdown, read **Reachable** entries for bounded impact |

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:

| RHEL / Rocky Linux artefact | Role | HeartSuite equivalent |
|-----------------------------|------|------------------------|
| **RHSA / RLSA** advisory | Published fix boundary with CVE list | No RHSA-style numbering — use transparency page entry + release tag (for example, `hs-v1.6.4-kernel-6.18.9`) |
| **RPM changelog** (`rpm -q --changelog`) | Proof fix is in installed NVR | Bundle SHA-256 manifest + `uname -r`; kernel `.config` SHA-256 in [Auditor Brief](auditor-brief/) |
| **`dnf updateinfo --cve`** | Advisory metadata | Manual lookup on [Kernel Security Transparency](../../security/); distro `updateinfo` only on maintenance kernel |
| **OVAL / OpenSCAP** | Automated false-positive reduction | **Not yet published** for HeartSuite; ingest published OSV and CONFIG SBOM feeds, or use manual workflow in this guide |
| **Red Hat CVE pages** (platform applicability) | Product-specific "not affected" | Per-CVE rationale and config gates on transparency page |

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](enterprise-adoption-guide/#evidence-and-independent-verification-for-customers-and-auditors) and [Kernel Support Policy](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](procurement-brief/)** — comparison table and buyer decision guide
- [ ] **[Auditor Brief](auditor-brief/)** — threat model, measured scores, residual risks, reproduction commands
- [ ] **[Kernel Security Transparency](../../security/)** 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](../../maintenance/updating-heartsuite/), [Protecting During Maintenance](../../maintenance/protecting-during-maintenance/))
- [ ] **Compensating controls** — Lockdown allowlist policy, SIEM/syslog integration ([Alert Settings](../../alerts/))

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](kernel-support-policy/) — Patch targets, notification channels, version-string semantics
- [Supply Chain and Advisory Feeds](supply-chain-and-advisories/) — Published JSON feeds (CONFIG SBOM, OSV, CycloneDX); OVAL and signing roadmap
- [Distro Compatibility Matrix](distro-compatibility-matrix/) — Validated distributions and RHEL-family guidance
- [Kernel Security Transparency](../../security/) — per-CVE status, Score on HeartSuite, config gates, scanner guidance
- [Procurement Brief](procurement-brief/) — hardening comparison and adoption decision guide
- [Auditor Brief](auditor-brief/) — threat model, residual risks, independent reproduction
- [Enterprise Adoption Guide](enterprise-adoption-guide/) — CVE handling ownership, supply chain, fleet operations
- [Updating HeartSuite](../../maintenance/updating-heartsuite/) — bundle application and SHA-256 verification
- [Mode Switching and Lockdown](../../mode-switching/) — HS kernel vs maintenance kernel semantics
- [How Root Lock by HeartSuite Compares](../../introduction/how-it-compares/) — vulnerability scanners as complementary controls
- [Comparison Matrix](kernel-comparison-matrix-5.19.6/) — 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.*