Pipeline CVE noyau

La pipeline CVE noyau aborde les vulnérabilités du noyau différemment d’un scanner OS-CVE générique : elle interroge directement les trackers de la distribution pour qu’un back-port ne soit plus marqué comme faux positif.

Pourquoi une pipeline dédiée

Le matching générique OSV/NVD produit des inondations de faux positifs sur les noyaux : le noyau upstream annonce « corrigé en 6.11.5 » alors que votre distribution (Debian 6.8.0-49, Ubuntu 6.8.0-49.49, RHEL 5.14.0-410, …) a déjà back-porté le correctif dans sa ligne LTS. La pipeline associe par version en cours d’exécution au tracker de cette distribution :

Debian — security-tracker.debian.org
Ubuntu — ubuntu.com/security/notices (USN)
RHEL / Rocky / Alma / Fedora — access.redhat.com CSAF v2
Gentoo — security.gentoo.org/glsa

Ce qui reste, ce sont les vraies CVE noyau ouvertes pour votre hôte — vulnerable (pas de correctif dans votre noyau), patched (la distribution l’a résolu dans votre version, redémarrage requis) ou no-backport (la distribution a décidé de ne pas patcher, alternative requise).

Ce que l’agent rapporte

Dans ExtendedInventorySnapshot.kernel_inventory (visible dans l’onglet Kernel sur chaque page de détail d’agent) :

champ	source
`running_release`	`uname -r`
`running_version`	`uname -v` (chaîne de build)
`last_boot_time`	`/proc/stat btime`
`installed_kernels[]`	`dpkg-query` / `rpm` / `pacman` / `qlist` / `apk`
`default_kernel`	`/boot/grub/grubenv` ou `grubby --default-kernel`
`reboot_required`	`/var/run/reboot-required` ou `dnf needs-restarting -r`
`mitigations_status`	`/sys/devices/system/cpu/vulnerabilities/*`
`is_custom_build`	`true` si la version en cours n’est dans aucun paquet installé
`kernel_cmdline`	`/proc/cmdline`

Les binaires d’agent plus anciens envoient kernel_inventory: null ; le worker côté hub ignore silencieusement ces hôtes — pas de faux positifs, pas de faux négatifs.

Déploiement : canary → primary

Un KernelUpdateBatch est une décision d’opérateur (« patcher CVE-2026-XXXX sur tous les hôtes du tag web-fleet »). L’orchestrateur (KernelUpdateOrchestratorWorker, toutes les 60 s) divise cela en :

Canary : 10 % des hôtes sélectionnés, max 3, min 1. Reçoit immédiatement un EAT de niveau 3 avec action update_kernel. Suivi de phase via kernel_update_progress.phase (queued → installing → installed → reboot_pending → rebooted_new).
Primary : activé uniquement quand tous les hôtes canary atteignent rebooted_new. Une seule défaillance canary fait abandonner le batch entier avec un abort_reason.

Chaque EAT suit la même pipeline que les actions manuelles : signature via MONSYS_EMERGENCY_PRIVATE_KEY, entrée append-only dans transparency_log, ligne persistante dans audit_log.

Wrapper côté hôte

L’agent ne s’exécute jamais en tant que root. Les installations de noyau passent par /usr/local/sbin/monsys-kernel-update avec une règle sudoers spécifique :

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

Le wrapper valide lui-même chaque argument (regex allowlist par gestionnaire de paquets), snapshot le pré-install kernel-set, exécute l’installation correcte (apt/dnf/zypper/pacman/portage), met à jour bootloader et initramfs, puis crée /var/run/reboot-required pour que le hub le détecte au prochain cycle d’inventaire.

Options --reboot-strategy :

none — l’opérateur redémarre manuellement (défaut, plus sûr)
manual — l’agent affiche une bannière ; aucune action
auto-at-window — shutdown -r +5 (uniquement dans une fenêtre de maintenance)

Impact sur le Trust Score

Depuis cette pipeline, patch_hygiene est un composite :

final = 0,7 × application_cves + 0,3 × kernel_currency

Pénalités kernel currency (max −100) :

chaque finding vulnérable ouvert contre la version en cours : −3 (cap −30)
reboot_required > 7 jours : −15, > 30 jours : −25
is_custom_build (pas de visibilité tracker) : −10
noyau installé plus récent que celui en cours (installé non redémarré) : −10

Les hôtes sur un agent pré-pipeline sont blanked (pas de baisse de score, l’UI affiche « agent obsolète »).

Section Audit Pack

L’Audit Pack mensuel (voir Monthly Audit Pack) contient depuis cette pipeline quatre émetteurs noyau :

kind	contenu
`kernel_running`	par agent : version actuelle, distro, reboot-required, dernier boot
`kernel_cve_finding`	par mois : toutes les CVE détectées avec tracker source + statut distro
`kernel_reboot`	par mois : chaque redémarrage avec prev/new release + flag `expected` (EAT-driven ou non)
`kernel_update_batch`	par mois : tous les batches orchestrateur avec statut canary/primary + raisons d’abandon

Le PDF contient une section dédiée « Kernel currency » entre le tableau KEV-CVE et le log des Emergency Action Tokens.

Mapping de conformité

La migration 095 ajoute 7 contrôles (tous en draft jusqu’à la revue juridique) :

NIS2 Art21 §2(e) — patching CVE noyau avec canary + journal d’audit
NIS2 Art21 §2(g) — hygiène de version du noyau (noyaux obsolètes)
CRA AnnexI §6 — mises à jour noyau sécurisées (Ed25519-signed)
CRA AnnexI §11 — gestion des vulnérabilités — noyau (backport-aware)
CRA AnnexI §12 — capacité de déployer les correctifs noyau
ISO 27001 A.8.8 — détection (surveillance continue des trackers)
ISO 27001 A.8.8 — cadence de patching (vulnérable > 30 jours)