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
Section intitulée « 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
Section intitulée « 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
Section intitulée « 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 viakernel_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 unabort_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
Section intitulée « 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-updateLe 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 actionauto-at-window:shutdown -r +5(uniquement dans une fenêtre de maintenance)
Sources et le statut « correctif en attente »
Section intitulée « Sources et le statut « correctif en attente » »Le worker combine par distribution :
| Distro | Source | Résultat |
|---|---|---|
| Ubuntu | base USN | patched ou vulnerable avec la version corrigée, par flavor de noyau |
| Ubuntu | CVE tracker (ubuntu.com/security/cves) |
CVE noyau de priorité high/critical sans paquet encore (needed/pending) |
| Debian | security-tracker (en flux, seulement le paquet linux) |
open/resolved par suite ; resolved ne devient patched que si la version Debian en cours (depuis uname -v) atteint la version corrigée |
| RHEL/Gentoo | CSAF / GLSA | limité (voir feuille de route) |
Une CVE dont la distribution n’a pas encore publié le correctif apparaît en
vulnerable avec, dans la colonne correctif disponible, pending 7.0.0-43.43
(la version annoncée) ou no fix in archive yet. C’est exactement la fenêtre
où vous devez atténuer vous-même ; c’est ainsi que CVE-2026-98432 (MPTCP) est
apparue le 30/10/2026 avant tout USN de Canonical. La suite et le codename
viennent d’os-release (12 → bookworm, 26.04 → resolute) ; un noyau
rétroporté (~deb12u1) est vérifié contre son propre paquet source
(linux-6.12). Les CVE Debian d’urgence unimportant ne deviennent pas des
constats.
Impact sur le Trust Score
Section intitulée « Impact sur le Trust Score »Depuis cette pipeline, patch_hygiene est un composite :
final = 0,7 × application_cves + 0,3 × kernel_currencyPé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 : −25is_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
Section intitulée « 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é
Section intitulée « 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)