Skip to content
monsys.ai

Kernel-CVE pipeline

The kernel-CVE pipeline looks at kernel vulnerabilities differently from a generic OS-CVE scanner: it talks directly to the distro trackers so a backport no longer shows up as a false positive.

Why a dedicated pipeline

Section titled “Why a dedicated pipeline”

Generic OSV/NVD matching produces floods of false positives on kernels: the upstream kernel reports “fixed in 6.11.5” while your distro (Debian 6.8.0-49, Ubuntu 6.8.0-49.49, RHEL 5.14.0-410, …) has already backported the fix into its LTS line. The pipeline matches per running release against that distro’s tracker:

What remains are the actual open kernel CVEs for your host — vulnerable (no fix in your kernel), patched (distro resolved it in your version, reboot required) or no-backport (distro decided not to patch, alternative required).

What the agent reports

Section titled “What the agent reports”

Inside ExtendedInventorySnapshot.kernel_inventory (visible in the Kernel tab on every agent detail page):

fieldsource
running_releaseuname -r
running_versionuname -v (build string)
last_boot_time/proc/stat btime
installed_kernels[]dpkg-query / rpm / pacman / qlist / apk
default_kernel/boot/grub/grubenv or grubby --default-kernel
reboot_required/var/run/reboot-required or dnf needs-restarting -r
mitigations_status/sys/devices/system/cpu/vulnerabilities/*
is_custom_buildtrue when running release matches no installed package
kernel_cmdline/proc/cmdline

Older agent binaries send kernel_inventory: null; the hub-side worker silently skips those hosts — no false positives, no false negatives.

Roll-out: canary → primary

Section titled “Roll-out: canary → primary”

A KernelUpdateBatch is one operator decision (“patch CVE-2026-XXXX on every host with tag web-fleet”). The orchestrator (KernelUpdateOrchestratorWorker, every 60 s) splits that into:

  1. Canary: 10% of the selected hosts, max 3, min 1. Immediately receives a Level 3 EAT with update_kernel action. Phase tracked via kernel_update_progress.phase (queued → installing → installed → reboot_pending → rebooted_new).
  2. Primary: only activates after every canary host reaches rebooted_new. A single canary failure aborts the entire batch with an abort_reason.

Each EAT travels the same pipeline as manual actions: signing via MONSYS_EMERGENCY_PRIVATE_KEY, append-only transparency_log entry, persistent audit_log row.

Host-side wrapper

Section titled “Host-side wrapper”

The agent never runs as root. Kernel installs go through /usr/local/sbin/monsys-kernel-update with a specific sudoers rule:

monsys ALL=(root) NOPASSWD: /usr/local/sbin/monsys-kernel-update

The wrapper validates every argument itself (allowlist regex per package manager), snapshots the pre-install kernel set, runs the correct install (apt/dnf/zypper/pacman/portage), updates bootloader and initramfs, then writes /var/run/reboot-required so the hub picks it up on the next inventory cycle.

--reboot-strategy options:

  • none — operator reboots manually (default, safest)
  • manual — agent surfaces a banner; no action taken
  • auto-at-window — shutdown -r +5 (only inside a maintenance window)

Trust Score impact

Section titled “Trust Score impact”

Since this pipeline, patch_hygiene is a composite:

final = 0.7 × application_cves + 0.3 × kernel_currency

Kernel currency deductions (max −100):

  • each open vulnerable finding against the running release: −3 (cap −30)
  • reboot_required > 7 days: −15, > 30 days: −25
  • is_custom_build (no tracker visibility): −10
  • newer installed kernel than running (installed, not rebooted): −10

Hosts on a pre-pipeline agent are blanked (no score drop; UI shows “upgrade agent” hint).

Audit Pack section

Section titled “Audit Pack section”

The Monthly Audit Pack (see Monthly Audit Pack) gained four kernel emitters with this pipeline:

kindcontent
kernel_runningper agent: current release, distro, reboot-required, last boot
kernel_cve_findingper month: every detected CVE with tracker source + distro status
kernel_rebootper month: every reboot with prev/new release + expected flag (EAT-driven or not)
kernel_update_batchper month: every orchestrator batch with canary/primary status + abort reasons

The PDF gains a dedicated “Kernel currency” section between the KEV CVE table and the Emergency Action Tokens log.

Compliance mapping

Section titled “Compliance mapping”

Migration 095 adds 7 controls (all draft until legal review):

  • NIS2 Art21 §2(e) — kernel-CVE patching with canary + audit log
  • NIS2 Art21 §2(g) — kernel currency hygiene (outdated kernels)
  • CRA AnnexI §6 — secure kernel updates (Ed25519-signed)
  • CRA AnnexI §11 — vulnerability handling — kernel (backport-aware)
  • CRA AnnexI §12 — capability to deploy kernel patches
  • ISO 27001 A.8.8 — detection (continuous tracker monitoring)
  • ISO 27001 A.8.8 — patching cadence (vulnerable > 30 days)