72 heures : le délai CVE-to-exploit est mort, votre patch management aussi

SAP Commerce Cloud : 72 heures entre le patch et l'exploitation active. VMware vCenter : 5 jours. Windows SharePoint : moins d'une semaine. Le temps dont vous disposiez pour appliquer vos correctifs en toute tranquillité appartient au passé. Si votre patch management fonctionne encore sur le modèle des années 2010 — scan mensuel, priorisation trimestrielle, fenêtres de maintenance le week-end — vous opérez dans un monde qui n'existe plus. Il est temps de regarder la réalité en face.

L'effondrement du délai d'exploitation : chronologie d'une tendance irréversible

En 2015, le délai médian entre la publication d'une CVE et son exploitation active dans la nature était de l'ordre de 45 à 60 jours selon les études de Rand Corporation et du Ponemon Institute. C'était suffisant pour qu'une organisation bien gérée ait le temps de tester, valider et déployer les correctifs dans ses fenêtres de maintenance habituelles. En 2020, ce délai était tombé à moins de 15 jours pour les vulnérabilités critiques. En 2023, Qualys documentait que 60 % des CVE critiques étaient exploitées dans les 24 heures suivant la publication d'un PoC public.

Aujourd'hui, en août 2026, nous sommes entrés dans l'ère du "même-jour exploit". CVE-2026-58231 sur SAP Commerce Cloud a été exploitée en production 72 heures après la publication du correctif de Patch Tuesday — avant même que la majorité des organisations aient pu planifier leur fenêtre de maintenance. CVE-2026-59310 sur VMware vCenter : 5 jours. CVE-2026-63520 sur SharePoint : moins d'une semaine. Ce n'est pas une coïncidence. C'est une tendance structurelle alimentée par plusieurs facteurs convergents qui rendent la situation durablement défavorable aux défenseurs.

Le premier facteur est la démocratisation des capacités d'analyse de vulnérabilités. Là où il fallait autrefois des mois de rétro-ingénierie pour développer un exploit fonctionnel, les LLMs et les outils de patch-diffing automatisés permettent aujourd'hui à n'importe quel groupe cybercriminel compétent de produire un exploit en quelques heures après l'analyse d'un correctif binaire. Les chercheurs de Google Project Zero ont documenté cette accélération : le temps de développement d'un exploit de qualité production a été divisé par 4 à 6 entre 2020 et 2026 pour les classes de vulnérabilités les plus communes.

Le deuxième facteur est l'industrialisation des campagnes d'exploitation. Les groupes ransomware modernes ne fonctionnent plus à l'artisanat. Ils disposent d'équipes dédiées à la veille sur les CVE, d'infrastructures de scanning massif (Shodan, Censys, outils propriétaires), et de playbooks d'exploitation pré-écrits pour les catégories de vulnérabilités les plus fréquentes. Dès qu'une CVE critique est publiée sur un produit majeur, ces équipes lancent des scans automatisés à la recherche d'instances vulnérables exposées et entament les tentatives d'exploitation en parallèle. La fenêtre de grâce n'existe plus.

Le modèle de patch management traditionnel : autopsie d'un processus dépassé

Le patch management tel qu'il a été codifié dans les années 2000-2010 repose sur un postulat désormais faux : le défenseur a le temps. Il peut identifier les vulnérabilités, évaluer leur criticité, tester les correctifs en pré-production, planifier une fenêtre de maintenance, et déployer dans un délai raisonnable de 30 à 90 jours pour les vulnérabilités critiques. Ce modèle était raisonnable quand les exploits prenaient des semaines ou des mois à se développer. Il est devenu suicidaire.

Le modèle traditionnel souffre de plusieurs dysfonctionnements structurels que j'observe régulièrement en mission d'audit :

La prioritisation par CVSS seul. Beaucoup d'organisations priorisent leurs patches uniquement sur la base du score CVSS. CVE-2026-68820 (Windows WinSock zero-day exploité par Lazarus) a un CVSS de 7.0 — score Élevé mais pas Critique. Un processus de patch management basé sur "on patch les CVSS >= 9 en priorité" aurait traité cette CVE comme secondaire, alors qu'elle était exploitée activement dans des campagnes étatiques. Le CVSS mesure la gravité intrinsèque d'une vulnérabilité dans le vide ; il ne mesure ni l'exploitation active, ni la présence dans le CISA KEV, ni l'exposition réelle de votre organisation.

Les fenêtres de maintenance rigides. "On ne touche pas la production un mardi soir, on attend le week-end prochain." Cette règle, héritée d'une époque où les déploiements étaient risqués et rares, est un luxe que l'on ne peut plus se permettre pour les vulnérabilités critiques activement exploitées. Quand VMware publie un patch un mardi et que les attaquants exploitent la CVE le dimanche suivant, attendre la prochaine fenêtre de maintenance du week-end après signifie exposer vos systèmes pendant une semaine entière après la disponibilité du correctif.

La dette de testing pré-production. L'argument classique contre le patching accéléré est le risque de régression : "On ne peut pas deployer sans tester". C'est légitime. Mais les organisations qui ont investi dans des environnements de test automatisés, du CI/CD pour leurs configurations système, et des procédures de rollback rapide peuvent déployer en quelques heures ce qui prenait des semaines auparavant. Celles qui n'ont pas fait cet investissement paient aujourd'hui un prix élevé — non pas en régressions de patch, mais en intrusions non évitées.

L'inventaire incomplet. On ne peut pas patcher ce qu'on ne connaît pas. J'ai réalisé des audits dans des organisations de taille intermédiaire (500 à 5000 postes) où 15 à 25 % des systèmes exposés à Internet n'apparaissaient pas dans l'inventaire officiel. Ces systèmes fantômes — serveurs oubliés, instances cloud créées manuellement, équipements réseau hors CMDB — restaient non patchés indéfiniment. Pour les attaquants qui scannent l'intégralité de l'espace d'adressage IPv4 quotidiennement, ces systèmes oubliés sont des cadeaux.

Ce que doit être le patch management moderne : un référentiel d'exigences

Face à l'effondrement du délai d'exploitation, le patch management doit être repensé non comme un processus périodique mais comme une capacité de réponse continue. Voici les exigences que j'applique dans mes recommandations d'audit :

Différenciation par tier de criticité. Tout n'est pas urgent, mais tout doit être traité. Je recommande trois niveaux :

• Tier 0 — Urgence absolue (< 24h) : CVE dans le CISA KEV ou exploitation active confirmée, CVSS >= 9.0 ET PoC public, systèmes exposés directement sur Internet. Déploiement d'urgence sans fenêtre de maintenance planifiée, rollback procedure activée en parallèle.
• Tier 1 — Priorité haute (< 7 jours) : CVSS >= 7.0 avec exploitation active probable (présence dans Threat Intel flux), systèmes en DMZ ou accessibles depuis partenaires. Déploiement dans la première fenêtre disponible après test accéléré (48-72h max).
• Tier 2 — Standard (< 30 jours) : tout le reste. Processus de test normal, fenêtre de maintenance planifiée.

Intégration du Threat Intelligence. Le CVSS seul ne suffit pas. La priorisation doit intégrer des sources de Threat Intelligence en temps réel : CISA KEV (mis à jour quotidiennement), flux ISAC du secteur, alertes CERT-FR, bulletins Broadcom, Microsoft MSRC et autres vendors. Un score CVSS 7.0 avec KEV et exploitation active Lazarus bat un CVSS 9.5 sur un composant obscur sans exploitation connue, chaque fois.

L'inventaire continu comme prérequis absolu. Aucun patch management efficace n'est possible sans un inventaire exhaustif et constamment mis à jour de votre surface d'attaque externe. Ce n'est pas un projet ponctuel — c'est une capacité opérationnelle continue. Des outils comme Shodan Monitor, Censys ASM, Tenable ASM, ou même des scans Nmap/Masscan automatisés vous permettent de surveiller votre empreinte externe et d'identifier rapidement les systèmes exposés qui nécessitent un patch en urgence.

L'automatisation du déploiement pour les postes de travail. Pour les flottes de postes de travail Windows, Microsoft Autopatch ou des outils équivalents (Ivanti, ManageEngine) permettent aujourd'hui de déployer les patches Tier 0 et Tier 1 de manière automatisée sans intervention humaine sur chaque poste. Les DSI qui résistent à l'automatisation au nom du contrôle doivent mesurer le risque réel que représente un parc de 2000 postes non patchés pendant 10 jours face à un groupe Lazarus ou BlackCat.

L'asymétrie fondamentale : attaquants et défenseurs ne jouent pas à jeu égal

Il faut accepter une réalité inconfortable : les attaquants ont des avantages structurels que les défenseurs n'auront jamais totalement. Un groupe ransomware peut cibler une vulnérabilité spécifique sur un produit spécifique et concentrer 100 % de ses ressources sur cette exploitation. Le défenseur doit gérer simultanément des milliers de CVEs, des centaines de produits, des contraintes opérationnelles, des budgets limités, et des exigences métier contradictoires. Cette asymétrie est intrinsèque et ne disparaîtra pas.

En août 2026, les données du rapport Black Kite sur les ransomwares montrent 7 551 victimes confirmées sur les 12 derniers mois, soit une hausse de 24,9 % en un an. La question n'est plus "si" une organisation sera ciblée, mais "quand" et "avec quel impact". Dans ce contexte, l'objectif du patch management n'est pas d'atteindre la perfection — c'est de rendre votre organisation suffisamment difficile à compromettre pour que les attaquants opportunistes passent à une cible plus facile, et de disposer des capacités de détection et réponse nécessaires pour limiter l'impact quand un groupe déterminé vous cible malgré tout.

Ce changement de paradigme — de la prévention totale à la résilience — implique une transformation profonde des indicateurs de performance. Un RSSI qui se mesure uniquement sur le "taux de conformité patches à 30 jours" rate les indicateurs qui comptent vraiment : temps de détection des intrusions (TTD), temps de réponse (TTR), couverture de l'inventaire, et maturité des procédures de reprise. Le patch management n'est pas une fin en soi — c'est un levier de réduction de la surface d'attaque dans une stratégie de sécurité globale.

Le cas particulier des petites et moyennes organisations : comment faire sans armée de spécialistes

Le discours sur le patch management accéléré est souvent perçu comme réservé aux grandes entreprises disposant de SOC 24/7 et d'équipes de sécurité dédiées. C'est un malentendu fréquent. Les TPE et PME peuvent et doivent adopter des pratiques de patch management réactives — mais leur approche doit être pragmatique et proportionnée à leurs capacités.

Pour une PME sans équipe sécurité dédiée, voici les pratiques minimales qui font une différence réelle :

• S'abonner aux alertes CERT-FR (gratuit, en français) et aux bulletins Microsoft Security Update Guide. Dix minutes de lecture hebdomadaire suffisent pour identifier les CVE critiques concernant vos produits.
• Activer les mises à jour automatiques Windows Update sur les postes de travail et serveurs Windows — au moins pour les mises à jour de sécurité. Le risque de régression est réel mais statistiquement bien inférieur au risque d'exploitation d'une CVE critique non patchée.
• Tenir à jour un inventaire simple (même un tableur) de tous vos logiciels exposés sur Internet : VPN, messagerie, serveurs web, applications métier. Chaque fois qu'une CVE critique touche l'un de ces produits, c'est votre Tier 0 — vous patchéz dans les 24 heures ou vous coupez l'accès en attendant.
• Externaliser la veille et le patch management critique à un MSSP ou à un prestataire de sécurité si vous n'avez pas les ressources internes. Le coût mensuel d'un service de patch management managé est sans commune mesure avec le coût moyen d'un incident ransomware (estimé entre 100 000 € et plusieurs millions selon la taille et le secteur, d'après les données Cybermalveillance.gouv.fr).

Conclusion : de la réactivité à l'anticipation

Le patch management du futur ne sera pas simplement plus rapide — il sera prédictif. Des outils comme Tenable VPR (Vulnerability Priority Rating), Qualys TruRisk, et les flux de Threat Intelligence prédictifs commencent à scorer les CVE non seulement sur leur gravité technique mais sur leur probabilité d'exploitation active dans les 30 prochains jours. Cette capacité prédictive permet de prioriser non pas ce qui est déjà exploité, mais ce qui sera exploité bientôt — redonnant aux défenseurs un avantage temporel que l'accélération des exploits avait supprimé.

En attendant la maturité généralisée de ces approches prédictives, la priorité immédiate est simple : abandonnez le modèle mensuel pour les systèmes exposés, intégrez le CISA KEV et les alertes CERT-FR dans votre processus de priorisation, et construisez une procédure de patch d'urgence testée et opérationnelle avant qu'elle ne soit nécessaire. Dans un monde où 72 heures séparent le patch du ransomware, chaque heure de retard a un coût mesurable.