De la divulgation à l'exploitation en heures : votre SLA de patch est périmé

Pendant des années, le SLA de patch standard ressemblait à ça : 30 jours pour les critiques, 90 pour les hautes, le reste au cycle trimestriel. Ce modèle est mort. En 2026, la fenêtre entre la divulgation d'une faille et son exploitation se mesure en heures, pas en semaines. Si votre processus n'a pas bougé, vous patchez des vulnérabilités qui ont déjà servi.

Les chiffres qui tuent le modèle à 30 jours

Quelques cas récents, tous documentés :

| Vulnérabilité | Délai divulgation → exploitation | | --- | --- | | marimo (CVE-2026-39987) | ~10 heures | | LMDeploy (CVE-2026-33626) | ~12 heures | | Drupal Core (CVE-2026-9082) | < 48 heures après le correctif | | Check Point VPN (CVE-2026-50751) | exploité ~1 mois avant le patch (zero-day) | | Oracle PeopleSoft (CVE-2026-35273) | zero-day, exploité avant l'alerte |

Deux phénomènes se cumulent. D'un côté, les attaquants construisent un exploit directement depuis l'avis de sécurité (parfois assistés par IA) en quelques heures. De l'autre, une part croissante des failles de bordure est exploitée en zero-day, avant tout correctif. Dans les deux cas, le délai utile pour se protéger est court ou nul.

Le régulateur a déjà acté le changement : BOD 26-04

La CISA ne raisonne plus en cycles. Sa directive BOD 26-04 (« Prioritizing Security Updates Based on Risk ») impose désormais une fenêtre de 3 jours pour les failles à haut risque aux agences fédérales, on l'a vu appliquée à PeopleSoft (KEV le 12 juin, 3 jours pour patcher). Le catalogue KEV, lui, est mis à jour dans les 24 h suivant la confirmation d'une exploitation.

Le signal pour le privé est clair : le statut d'exploitation, pas le score CVSS, pilote la priorité, et l'unité de temps est le jour, pas le mois.

Recalibrer : prioriser comme un attaquant

On ne patche pas 200 CVE en 3 jours. La solution n'est pas de tout accélérer, mais de trier finement et d'agir vite sur le sommet de la pile. La règle Kreomnis :

Si  inKev == true  OU  exploitation publique connue   → patch / mitigation sous 72 h
Sinon si pré-auth ET sans interaction ET exposé Internet → patch sous 7 jours
Sinon si EPSS ≥ 0.50  ET  CVSS ≥ 7.0                    → patch sous 30 jours
Sinon                                                    → cycle normal

C'est le prolongement direct de notre logique EPSS vs CVSS : KEV et exploitation observée passent devant tout, l'exposition et l'absence de prérequis priment ensuite, le CVSS seul arrive en dernier.

Ce qui doit changer concrètement

1. Le patch ne ferme plus l'incident. Quand l'exploitation précède le correctif (Check Point, PeopleSoft), appliquer la mise à jour ne suffit pas : il faut présumer la compromission, chasser les IoC et faire tourner les secrets. Marquer un CVE « remédié » parce que la version est à jour, alors que des identifiants volés restent actifs, est un faux positif de conformité.

2. Les mitigations temporaires deviennent stratégiques. Si vous ne pouvez pas patcher en 72 h, vous devez savoir réduire l'exposition immédiatement : règle pare-feu, désactivation de fonction, blocage d'endpoint, réglage registre. Ces palliatifs doivent être préparés à l'avance, pas improvisés.

3. L'inventaire d'exposition est le prérequis. On ne peut prioriser « ce qui est exposé sur Internet » que si on sait ce qui l'est. Une cartographie à jour de la surface externe (ASM) n'est plus un luxe : c'est ce qui permet de répondre en heures.

4. Automatisez la veille KEV. Le catalogue CISA KEV et les flux d'exploitation doivent alimenter directement votre file de priorisation, idéalement automatiquement. C'est précisément la logique de la veille CVE de Kreomnis Vigie.

Le mot de la fin

Le SLA à 30 jours n'a pas disparu : il reste valable pour le bas de la pile, l'immense majorité des CVE qui ne seront jamais exploitées. Ce qui a changé, c'est le sommet : pour les failles exploitées, exposées et pré-auth, l'unité de temps est l'heure ou le jour. La discipline de patch n'a plus de marge ; la discipline de tri, elle, en a plus que jamais.

Pour une priorisation détaillée des dernières failles Microsoft, voir notre panorama du Patch Tuesday de juin 2026.

• Kreomnis