Pendant trente ans, la gestion des vulnérabilités a fonctionné avec ce qui ressemble aujourd’hui à un luxe impossible : un délai de plusieurs mois entre la découverte d’une faille et le moment où quelqu’un pouvait la transformer en arme. Le tri par gravité, la planification de la correction, la validation, on passait à autre chose.
Ce délai généreux est ce qui rendait l’ensemble du système viable.
L’intelligence artificielle a supprimé la lenteur manuelle qui freinait l’armement. Lire l’avis de sécurité, trouver la voie d’attaque, construire la chaîne, tester ce qui fonctionne : plus rien ne peut désormais se permettre d’avancer à la vitesse humaine. Aujourd’hui, le délai entre la divulgation et l’exploitation se compte en heures, et non en mois.
Le Zero Day Clock, qui suit cette métrique en temps réel, affiche actuellement une moyenne d’environ 8 heures pour 2026. Il y a deux ans, ce délai était d’environ 53 jours. Le chiffre fluctue avec l’arrivée de nouvelles données, mais il se maintient désormais fermement sous la barre des 24 heures.
Le correctif seul ne suffit plus
Le réflexe est généralement de vouloir corriger plus vite. Mais la remédiation n’est pas un simple interrupteur à actionner. Les correctifs dépendent de plusieurs contraintes : les tests de régression, les fenêtres de maintenance et les engagements de disponibilité. Aujourd’hui, chaque indicateur important évolue malheureusement dans la mauvaise direction.
Le rapport 2026 de Verizon sur les enquêtes liées aux violations de données, qui s’appuie sur plus de 13 000 organisations, révèle que :
- Le délai médian de correction pour les vulnérabilités déjà exploitées est désormais de 43 jours, contre 32 l’année dernière.
- La proportion d’organisations qui les corrigent entièrement est passée de 38% à 26%.
- Même les meilleurs acteurs ne ferment que 30 à 40% de ces failles durant la première semaine, un taux qui stagne depuis des années.
Quand l’attaque se joue en heures et la correction en semaines, la violation se produit entre les deux. Et cette période d’exposition ne fait que s’allonger.
Le volume le garantit : 48 185 CVE en 2025, dont moins de 0,6% ont été corrigés. La stratégie du « tout correctif » n’est plus mathématiquement tenable.
Pire encore, ces chiffres datent d’avant l’ère Mythos.
Mythos désigne le seuil à partir duquel les modèles d’IA peuvent découvrir et armer des vulnérabilités de manière autonome. Ce n’est pas théorique : le modèle de classe Mythos d’Anthropic a trouvé une faille qui était restée cachée dans OpenBSD, pourtant considéré comme l’un des systèmes d’exploitation les plus sécurisés au monde, pendant 27 ans.
Le niveau de 2025 est devenu un plancher, et non un plafond.
La question n’est plus « qu’est-ce qui est vulnérable ? » car sur une liste où tout obtient un score de 9 ou 10, cela ne permet de rien prioriser. La vraie question est devenue : « Qu’est-ce qui est réellement exploitable contre nous, ici et maintenant, compte tenu des contrôles que nous avons déjà déployés ? » Trouver l’exposition n’a jamais été la partie difficile. Démontrer la bonne décision (corriger, mitiger, surveiller ou accepter) est l’écart critique.
Votre test d’intrusion est plus rapide. Il ne couvre toujours pas l’essentiel.
La réponse populaire a été d’automatiser les tests d’intrusion.
Les outils de test d’intrusion automatisés prennent le test manuel qui se faisait une fois par trimestre et l’exécutent en continu, à grande échelle, en lançant de vraies chaînes d’exploitation contre de vrais actifs. Là où cela est possible, c’est la preuve la plus forte qui soit : vous voyez l’exploitation réussir. Picus le fait aussi, avec ses tests d’intrusion autonomes. Aucun doute là-dessus.
Mais, si l’automatisation du lancement vous rend plus rapide, elle ne change pas ce que ce lancement peut atteindre.
L’exploitation en direct ne fonctionne que là où déclencher une attaque est sans danger et là où un exploit fonctionnel existe. Cela laisse trois lacunes qu’aucun outil de test d’intrusion ne peut combler, et les additionner n’arrange rien. Pourquoi ?
- Sans exploit, rien à lancer. Une grande partie des CVE divulgués ne bénéficient jamais d’un exploit public ou sûr. Sans rien à exécuter, un test ne peut pas dire s’ils sont exploitables dans votre environnement.
- Les actifs que vous ne pouvez pas risquer. Les systèmes critiques pour l’activité, réglementés ou isolés sont précisément ceux contre lesquels vous ne pouvez pas déclencher une attaque en toute sécurité, et ce sont généralement les plus importants.
- La fenêtre du jour un. Armer un nouvel exploit et l’intégrer à vos outils prend du temps. Les attaquants sont déjà en mouvement pendant que votre lancement est encore au point mort.
Dans une entreprise typique, la portion que vous pouvez exploiter en direct en toute sécurité ne représente généralement que 10 à 15% de votre exposition totale. Pour les 85 à 90% restants, l’exécution d’un test ne fournit aucune réponse.
Tester au sol la fusée que vous ne pouvez pas lancer
La façon la plus sûre de prouver qu’une fusée volera est de la lancer. Mais aucun programme spatial ne valide sa flotte de cette manière.
Certaines fusées n’existent que sur papier, d’autres sont habitées et trop précieuses pour être risquées, d’autres sont encore en cours d’assemblage. Les ingénieurs les testent donc au sol : poussée du moteur sur un banc statique, test du système de carburant sous pleine pression, bouclier thermique contre sa charge thermique maximale. Si un composant requis échoue, la fusée ne peut pas voler, et ils le savent sans quitter le pas de tir.
C’est le même écart en trois parties auquel les équipes de sécurité sont confrontées.
- Le CVE sans exploit disponible est la fusée qui n’existe que sur papier.
- L’actif interdit est la fusée habitée que vous ne risquerez pas.
- Le CVE du jour un est le fuselage à moitié assemblé alors que votre fenêtre de lancement se referme.
Le lancement est la preuve que vous utilisez quand vous le pouvez ; le test au sol est la preuve sur laquelle vous vous appuyez quand vous ne le pouvez pas.
Casser la chaîne, casser l’exploit
Un exploit n’est pas de la magie. C’est une chaîne de techniques spécifiques, les TTP qu’un attaquant doit exécuter dans l’ordre : obtenir l’exécution, contourner une protection, élever les privilèges, extraire des identifiants, se déplacer vers la cible.
Chaque maillon dépend des conditions dans votre environnement, et chacun peut être testé individuellement contre vos contrôles réellement déployés, comme un ingénieur teste un moteur sur un banc statique sans avoir à lancer le véhicule entier.
C’est la validation par chaîne TTP. Vous cartographiez un CVE vers la chaîne de techniques que son exploitation nécessite, puis vous validez chaque technique par rapport à vos contrôles existants. Si votre environnement casse un maillon requis, l’exploit ne peut pas y réussir, et vous le savez sans avoir à déclencher une attaque en direct. Si chaque maillon tient, l’exposition est réellement exploitable, avec des preuves.
Quatre éléments distinguent ce verdict d’une simple étiquette statique comme le CVSS ou l’EPSS :
- Elle valide par inférence, et non par détonation. Elle fonctionne donc là où une exploitation en direct serait dangereuse ou impossible.
- Elle tient compte des contrôles. Le verdict reflète votre véritable EDR, vos GPO, la protection LSASS, le listage d’applications autorisées et votre pare-feu, et pas seulement un numéro sur une fiche technique.
- Elle évalue l’accessibilité. Les expositions contenues ne sont pas surévaluées.
- Elle fournit des preuves. La chaîne, les contrôles testés et le résultat : une piste d’audit qui peut être présentée à la direction.
À quoi cela ressemble sur un vrai CVE
Prenons CVE-2025-29824, une vulnérabilité de type use-after-free dans le CLFS de Windows qui permet une élévation de privilèges vers SYSTEM (observée dans la campagne Storm-2460 liée à RansomEXX).
Au lieu de déclencher un exploit, vous le décomposez en la chaîne qu’un attaquant doit exécuter et testez chaque étape contre votre pile de sécurité :
- Exécution via certutil et MSBuild – T1105 / T1127
- Contournement KASLR / Collecte SysInfo – T1082
- Exploitation de la faille CLFS UAF → exécution en espace noyau – T1068
- Modification de token et injection dans dllhost – T1134 / T1055
- Extraction LSASS via dllhost masqué – T1003
Chaque technique est testée contre la politique EDR, la configuration GPO et le durcissement, la protection LSASS, le listage d’applications autorisées et le pare-feu nouvelle génération.
Si votre listage d’applications bloque l’exécution de MSBuild, ou si votre protection LSASS empêche l’extraction des identifiants, la chaîne se rompt, le CVE n’est pas exploitable sur cet actif, et vous pouvez montrer exactement pourquoi. Aucun exploit certifié n’est nécessaire, et cela fonctionne sur la machine isolée que vous n’attaqueriez jamais en direct. Ce faisant, vous êtes passé d’un simple identifiant CVE à une décision justifiable en quelques heures, le jour de sa divulgation, et non des semaines plus tard.
Prouvez-le partout, pas seulement là où vous pouvez lancer
Le lancement et le test au sol ne sont pas rivaux, ils sont symbiotiques. Les programmes les plus solides exécutent les deux, et retestent continuellement à mesure que l’environnement évolue dans le temps et dans ses configurations.
C’est la boucle que Picus exécute : des chaînes d’exploitation en direct là où c’est sans danger, la chaînage TTP pour les actifs interdits et les CVE du jour un qu’un lancement ne peut atteindre, et une validation continue des contrôles pour que la décision « d’accepter » du trimestre dernier soit retestée, et non supposée.
Une seule plateforme, et une seule réponse à la seule question qui compte : « Qu’est-ce qui est réellement exploitable ici, maintenant ? »
Cet article a été écrit par Sıla Özeren Hacıoğlu, ingénieure en recherche en sécurité chez Picus Security.
Sponsorisé et écrit par Picus Security.