~8 minutes
La Cloud Security Alliance a publié le 16 juin 2026 : Mean Time to Breach: Why Traditional Patch Cycles No Longer Protect You. Le constat est simple et brutal : 48 minutes entre l’accès initial et la compromission complète, contre 5 jours ou plus de temps de patch moyen pour la moitié des entreprises. J’ai lu cet article en le confrontant à ma propre matrice de priorisation CVE/CVSS/EPSS/KEV publiée en janvier 2026.
Source : Cloud Security Alliance — lien original — publié le 16 juin 2026.
Le fossé temporel que ma matrice de priorisation ne résout pas seule
Ma matrice CVE/CVSS/EPSS/KEV répond à la question « que dois-je patcher en premier ? ». L’article de la Cloud Security Alliance pose une question différente et plus dérangeante : même bien priorisé, votre cycle de patch est-il assez rapide ?
Les chiffres cités : temps moyen entre l’accès initial et la compromission complète, 48 minutes (CrowdStrike 2025) ; mouvement latéral le plus rapide observé, 51 secondes. En face, le temps de patch moyen des organisations dépasse 5 jours pour la moitié d’entre elles. Mon propre workflow “checklist du lundi matin” (récupérer KEV, croiser EPSS, prioriser, patcher le mercredi) est déjà considéré comme une bonne pratique dans l’industrie, mais il trop lent face à ce que documente la Cloud Security Alliance.
Note du PandaRedacteur: Un attaquant qui compromet un système en 48 minutes n’en a rien a F….de vos processus.
L’effondrement de la fenêtre d’exploitation
Le point que je trouve le plus utile dans l’article : la contraction du délai entre publication d’une CVE et exploitation active.
| Période | Délai moyen avant exploitation active |
|---|---|
| Avant 2024 | ~32 jours |
| 2024-2025 | ~5 jours |
| 2026 (constat CSA) | 33% des CVE critiques exploitées dans les 24h, 54%+ en une semaine |
Ce chiffre change directement la lecture de ma matrice de priorisation : mon “Niveau 1 : KEV = Priorité absolue” avec un délai de patch cible de 24-48h était déjà agressif en janvier. À la lumière de ce nouvel article, ce délai est l’exception qui devrait devenir la norme, pas la réaction d’urgence réservée aux CVE déjà confirmées activement exploitées. Un EPSS élevé sans KEV ne doit plus attendre “cette semaine” ; les kits d’exploit sont disponibles “within hours of CVE publication” selon la CSA.
Ce que ni ma matrice ni EPSS/KEV ne mesurent : le travail manuel comme surface d’attaque
C’est l’angle que je n’avais pas du tout dans ma série de janvier. La Cloud Security Alliance cite Ryan Braunstein (Automox) :
« Manual work is the new attack surface. »
Les chiffres qui l’accompagnent sont frappants : 43% des équipes passent 10 heures ou plus par semaine sur des tâches manuelles de gestion des endpoints, 42% s’appuient encore sur des tableurs statiques et des dashboards disparates, et seulement 6% des organisations fonctionnent avec des workflows entièrement automatisés.
Mon workflow CVE/CVSS/EPSS/KEV proposait déjà des scripts Python pour automatiser la récupération KEV/EPSS. Ce qui devient crucial est de ne pas s’arrêter à la priorisation, mais couvrir la chaîne complète jusqu’au déploiement du patch. Prioriser vite avec des outils automatisés et déployer lentement à la main revient au même résultat qu’une priorisation manuelle.
Note du PandaRedacteur : et si comme de nombreuses personnes vous êtes liés aux outils 1.0 (Excel PPT, ..) pour vos processus, cela ne va pas vous aider
La dette technique comme amplificateur, pas comme excuse
La CSA identifie trois obstacles récurrents à l’automatisation : systèmes legacy et dette technique (35%), budget insuffisant (35%), lacunes de compétences (34%). Ce triptyque crée un cycle vicieux que l’on retrouve dans tous les produits (ou presque): la dette ralentit le patch, ce qui augmente l’exposition, ce qui force une remédiation en mode crise, laquelle génère encore plus de dette technique par les correctifs à la va-vite.
C’est ce mécanisme qui est documenté côté supply chain logicielle dans mon article SLSA : sécuriser sa supply chain : sans provenance et sans automatisation des contrôles à la source, chaque niveau de maturité gagné coûte plus cher que le précédent parce que la dette s’est déjà accumulée.
Le patch virtuel : la mitigation que ma matrice ne couvrait pas
Point concret que je n’avais pas traité : le patch virtuel (virtual patching) via WAF/WAAP comme mesure de confinement en attendant le déploiement du correctif définitif. La CSA cite des chiffres précis : le patch virtuel a bloqué 62% des attaques web et 71% des attaques API dans les cas documentés, et l’intégration des scanners de vulnérabilités avec des solutions WAAP a permis de réduire un délai de remédiation de plusieurs mois à trois jours.
Ma matrice de janvier classait la “facilité de mitigation” en quatre niveaux (facile, moyenne, difficile, impossible) mais ne proposait pas le patch virtuel comme option intermédiaire explicite entre “on patche tout de suite” et “on planifie”. C’est un gap que je corrige ici : entre le KEV du lundi matin et le déploiement du mercredi, un WAF correctement configuré comble une partie de la fenêtre de 48 heures.
Note du PandaRedacteur: et de nombreuses personnes savent ce que je pense du WAF..mais…
Le Mean Time to Patch comme métrique exécutive
Le recadrage le plus important de l’article CSA, à mon sens : traiter le MTTP (Mean Time to Patch) comme un indicateur de performance exécutif, pas un problème IT. Seules 10% des organisations atteignent la cible de moins d’un jour de MTTP. Et le ROI est chiffré : les organisations qui contiennent une brèche en moins de 200 jours économisent plus d’un million de dollars comparé aux réponses lentes.
Mon reporting hebdomadaire proposé dans la matrice de janvier (“CVE patchées, CVE en KEV, backlog”) reste un bon point de départ opérationnel, mais il manque la couche de traduction vers un board exécutif. Le MTTP devrait apparaître à côté du RTO/RPO dans les tableaux de bord de direction, pas seulement dans le dashboard Grafana de l’équipe sécu.
Ce qu’il faut retenir de tout cela
Ma matrice CVE/CVSS/EPSS/KEV répond à “quoi patcher en premier”, l’article de la Cloud Security Alliance répond à “à quelle vitesse, et pourquoi votre vitesse actuelle ne suffit plus”.
La conclusion qui s’impose : la priorisation seule ne suffit plus si le temps entre la décision et le déploiement reste mesuré en jours pendant que les attaquants opèrent en minutes.
Note du PandaRedacteur : Ce n’est plus un problème d’outillage de scan. C’est un problème d’architecture défensive : éliminer le travail manuel du chemin critique entre la détection et le déploiement.