Auto-patch (opt-in par hôte)

Auto-patch permet à monsys de traiter les CVE de façon autonome sur les hôtes qui l’activent explicitement. Sans ce drapeau, monsys ne patche jamais automatiquement — c’est le comportement par défaut du reste de la plateforme.

Quand activer

• Hôtes où une minute d’indisponibilité est acceptable (install → redémarrage optionnel)
• Hôtes où vous faites confiance au QA des mainteneurs distro (Ubuntu/Debian/RHEL security updates)
• Couches de flotte que vous ne voulez plus patcher manuellement (postes dev, staging, runners CI)

Ne pas activer sur :

• Primaires de bases de données production (patcher après canary)
• Hôtes où un redémarrage d’app touche des clients (utilisez le flux EAT avec fenêtre de maintenance)
• Mises à jour kernel (délibérément NON auto-patchable — risque de reboot)

Ce qui est patché

Catégorie	Source	Action EAT	Redémarrage ?
Paquets OS	apt / dnf / apk / zypper	install_package par (paquet, version)	géré par le gestionnaire de paquets
Dépendances applicatives	npm / pip / composer / RubyGems / Go	update_packages par (projet, écosystème)	install-seul en v1 — pas de redémarrage automatique du service
Kernel	—	—	NON auto-patchable en v1

Filtrage :

• fixed_version IS NOT NULL — uniquement les CVE avec un correctif connu
• Sévérité ≥ seuil configuré (CRITICAL ou CRITICAL+HIGH)
• acknowledged_at IS NULL — les CVE que l’opérateur a précédemment marquées comme rejetées sont ignorées
• Max 25 paquets par hôte par cycle — plafond de sécurité contre l’emballement

Cycle

• Warmup : 2 minutes après démarrage du hub
• Intervalle : 30 minutes
• Limite par hôte : au moins 25 minutes depuis le tick précédent
• Les hôtes sans CVE ouverte sont aussi touchés — la mise à jour de last_run_at évite le re-polling

Activation

Onglet Governance sur le détail de l’agent → section Auto-patching (opt-in) :

1. Cochez OS-packages et/ou Application dependencies
2. Choisissez la sévérité minimum : CRITICAL ou CRITICAL + HIGH
3. Cliquez Opslaan (TOTP) — une boîte de dialogue demande votre code TOTP
4. La confirmation + horodatage apparaît sous la section

Désactiver ne nécessite pas de TOTP — remettre le drapeau à false est par définition un fallback sûr.

Cycle d’attestation

Chaque phase d’auto-patch produit une entrée dans l’attestation chain.

Quand	Type d’entrée	Payload
Drapeau flippé sur l’hôte	remediation.auto_flag_set	os_packages, app_deps, min_severity, set_by, turned_on
Le worker dispatche un EAT	remediation.auto_proposed	category, package, target_version, cve_id, severity, eat_nonce, flag_set_by, flag_set_at
L’agent rapporte un succès	remediation.auto_applied	eat_nonce, exit_code, note
L’agent rapporte un rollback	remediation.auto_rolled_back	idem, avec exit_code ≠ 0 ou note de rollback

Un auditeur externe remonte de auto_applied → auto_proposed (via eat_nonce) → flag_set_by → auto_flag_set (via subject_ref = agent_id). Chaque patch autonome est cryptographiquement lié à l’utilisateur qui a donné son consentement.

Alertes

Chaque cycle déclenche toujours une alerte, même en cas de succès :

• info — Auto-patch dispatched: <pkg> → <version> à chaque EAT émis
• warning — Auto-patch rolled back en cas de restart-fail ou exit non-zéro

Vous voyez ainsi dans la vue alertes standard quels hôtes tournent en autonome, même si vous ne regardez jamais l’attestation chain.

Rollback

Les wrappers côté agent (monsys-action install pour paquets OS, monsys-package-update pour deps applicatives) font :

1. Snapshot — lockfile + node_modules (ou dpkg status pour apt) est préservé
2. Install — la mise à niveau demandée
3. Restart (si restart_service est défini) — absent en auto-patch v1
4. Rollback — si un restart échoue, retour au snapshot

Si l’install elle-même échoue (conflit config dpkg, npm ERESOLVE) : pas de rollback nécessaire car rien n’a changé. Le code de sortie non-zéro revient via PostEmergencyResult et émet auto_rolled_back.

Pourquoi v1 ne patche pas le kernel

Les mises à jour kernel nécessitent un reboot pour prendre effet. Les reboots ont des effets de bord que le wrapper ne peut pas annuler (services qui ne redémarrent pas seuls, montages filesystem, config réseau). Le risque ne vaut pas la commodité — les CVE kernel sont assez urgentes pour qu’un opérateur fasse un TOTP manuel via le pipeline CVE kernel avec canary + verify.

Pourquoi v1 app-deps est install-seul

npm install remplace les fichiers sur disque, mais le processus en cours a déjà chargé l’ancien code. Un redémarrage de service est nécessaire pour que le correctif soit effectif. En v1 il n’y a pas de mapping automatique (project_path, ecosystem) → unité systemd, donc nous ne forçons pas un redémarrage qui pourrait être erroné. Le patch est en place ; l’opérateur redémarre quand cela convient. Un champ restart_service par projet pourra plus tard rendre ce lien explicite.

Comparaison avec Root/Aikido et OS auto-updates

• Root (Aikido) fait des images de conteneur durcies — au niveau dépendance, remplacement drop-in. Complémentaire, non concurrent. Si vous utilisez des conteneurs : Root pour les images, monsys pour l’hôte.
• Ubuntu unattended-upgrades / dnf-automatic patchent aussi les paquets OS, mais sans attestation, sans policy centralisée, sans boucle rollback-alerte. Monsys auto-patch est utile sur les distros où unattended-upgrades donne trop peu de contexte pour un audit NIS2/CRA.

Schéma SQL

agents a (mig 113) :

auto_patch_os_packages    BOOLEAN NOT NULL DEFAULT FALSE
auto_patch_app_deps       BOOLEAN NOT NULL DEFAULT FALSE
auto_patch_min_severity   TEXT    NOT NULL DEFAULT 'HIGH'
                                  CHECK IN ('CRITICAL', 'HIGH')
auto_patch_enabled_by     UUID    REFERENCES users(id)
auto_patch_enabled_at     TIMESTAMPTZ
auto_patch_last_run_at    TIMESTAMPTZ

L’index partiel idx_agents_auto_patch_enabled maintient la requête worker en O(log n) sur l’ensemble activé, indépendamment de la taille totale de la flotte.

API

• GET /api/v1/agents/:id/auto-patch — lecture (rôle viewer)
• PATCH /api/v1/agents/:id/auto-patch — écriture (rôle admin + purpose TOTP agent_auto_patch)

Body :

{
  "os_packages": true,
  "app_deps": false,
  "min_severity": "HIGH"
}

Les trois champs sont optionnels ; seuls ceux présents sont mis à jour. enabled_by + enabled_at ne sont mis à jour que lorsque vous activez un drapeau — la désactivation laisse ces champs d’audit intacts pour que le dernier acteur du consentement reste traçable.