Le paradoxe de la divulgation des vulnérabilités : pourquoi un correctif plus rapide ne peut pas échapper aux attaques générées par l’IA

Pendant des décennies, la gestion des correctifs reposait sur une seule hypothèse : si vous allez assez vite, vous battez les attaquants. Le rapport M-Trends 2026 de Mandiant montre que la race est terminée. La vulnérabilité moyenne est désormais exploitée sept jours avant même qu’une correction n’existe.

Le contraste avec le passé récent est frappant. En 2018, les défenseurs avaient environ deux mois après la publication d’une vulnérabilité avant que quelqu’un ne tente de l’exploiter — le temps de tester un correctif et de le déployer avant que quelqu’un ne vienne frapper. Cette fenêtre est maintenant négative.

Le Global Threat Report 2026 de CrowdStrike confirme cela, constatant que 42 % des vulnérabilités exploitées ont été attaquées avant même d’être rendues publiques.

Je me suis assis pour discuter de ces conclusions avec Jason Garbis, fondateur de Numberline Security et coprésident du groupe de travail Zero Trust à la Cloud Security Alliance, pour un récent épisode du podcast The Segment .  

Une fois qu’une vulnérabilité devient publique, soutenait-il, les attaquants n’ont plus besoin de chercher la faille. La divulgation elle-même leur fournit un plan, et construire un exploit à partir d’un avis publié demande bien moins de travail que de trouver la faiblesse à partir de rien.  

Ce changement explique pourquoi l’ancienne obsession de l’industrie de la sécurité pour la rapidité de patch ne cherche pas à se tromper d’arrivée. Les équipes qui tiennent le coup dans cette nouvelle chronologie partagent un trait. Ils supposent qu’ils seront violés quelque part entre la divulgation et le patch, et ils ont déjà limité la distance que cette faille peut parcourir.

Lorsque l’avis de patch devient le plan directeur de l’attaquant

Tout processus de divulgation responsable existe pour une bonne raison.  

Les fournisseurs doivent informer les clients de ce qui est défaillant pour pouvoir le réparer, et les régulateurs l’exigent de plus en plus. Mais cette même transparence fonctionne désormais dans les deux sens.  

Dès qu’un CVE devient public, les attaquants n’ont pas besoin de remonter un mystère. Ils n’ont qu’à lire l’avis. Ensuite, ils comparent le code patché avec la version vulnérable. À partir de cette différence, ils peuvent construire un exploit fonctionnel.

Des recherches menées par l’Initiative de sécurité de l’IA de la Cloud Security Alliance montrent à quel point ce processus a déjà été automatisé. Les systèmes d’IA multi-agents conçus pour reproduire les vulnérabilités divulguées ont recréé environ la moitié de tous les CVE publiés au cours des deux dernières années, beaucoup avec des exploits fonctionnels, pour un coût moyen inférieur à 3 $ par tentative.  

Ce qui nécessitait autrefois un rétro-ingénieur compétent et des jours d’efforts discrets se fait maintenant pour de la monnaie. Cela prend à peu près autant de temps que de lire l’avis deux fois.

C’est le mécanisme dont Jason et moi avons discuté dans le podcast. Un attaquant ayant accès à un modèle d’IA de pointe qui scanne les dépôts de code à la recherche de défauts non découverts représente un risque réel. 

Mais la menace plus immédiate est plus simple. Les attaquants attendent la divulgation, puis se précipitent pour construire l’exploit avant que les défenseurs n’aient fini de valider et déployer le correctif.  

La divulgation est discrètement devenue de la reconnaissance, et la plupart des programmes de gestion des patchs n’ont jamais été conçus pour survivre à cela.

Le tsunami de la patch post-Mythos

Jason a un terme créatif pour ce qu’il envisage dans un avenir proche : un tsunami de patch.

Les modèles d’IA Frontier révèlent désormais des vulnérabilités et provoquent des mises à jour de sécurité à un volume et à une vitesse que la plupart des équipes n’ont jamais rencontrés. Le débat autour des modèles de classe Mythos et du Projet Glasswing n’a fait qu’alimenter cette conversation.  

Mais selon Jason, peu importe à quel point le battage initial était du marketing. Ces modèles deviennent toujours meilleurs pour détecter les failles, et les défenseurs doivent se préparer à cette réalité, quel que soit le rythme.

Les chiffres le confirment. Les publications mondiales sur CVE ont dépassé les 48 000 en 2025, soit une hausse de 20 % par rapport à l’année précédente, selon une analyse des données officielles CVE par le chercheur de Cisco Jerry Gamblin. Son suivi de mi-année montre que la courbe s’est verticalisée : le premier semestre 2026 à lui seul a produit plus de 35 000 CVE, soit une hausse de près de 50 % par rapport à la même période de l’année dernière. C’est un nouveau CVE toutes les 7,4 minutes.  

Les fournisseurs de logiciels commerciaux compressent également la durée de support des anciennes versions, ce qui force à accélérer les cycles de mise à jour dans toute l’entreprise.  

Les bibliothèques open source deviennent également une source croissante de visibilité. Jason a souligné qu’ils comportent souvent beaucoup moins de rigueur concernant l’emballage et la gestion des versions que les logiciels commerciaux. Tellement de logiciels d’entreprise personnalisés en dépendent, parfois sans être touchés depuis des années.

Jason a soutenu que les fondamentaux de la sécurité de l’information n’ont pas changé. L’industrie sait déjà comment se défendre contre toutes les catégories d’attaques auxquelles elle est confrontée aujourd’hui.  

Ce qui change, c’est le volume et la rapidité avec lesquels les risques connus arrivent. Ce changement expose des équipes qui n’ont jamais développé la discipline nécessaire pour suivre le rythme, même avant l’arrivée de l’IA.

La mesure qui compte est la portée d’une faille

Si la vitesse de patch seule ne peut pas dépasser un temps négatif pour exploiter, les responsables de la sécurité ont besoin d’un autre indicateur. La vraie question est de savoir quelle partie du réseau un attaquant peut atteindre une fois qu’il est connecté.  

Jason a donné un exemple concret issu de son travail de conseil. Imaginez une application financière fonctionnant sur un réseau d’entreprise plat, où n’importe lequel des 5 000 employés et appareils peut y accéder directement. Imaginez maintenant cette même application limitée aux quelque 200 personnes qui travaillent réellement dans la finance. 

La vulnérabilité doit encore être corrigée dans tous les cas. Mais la population qui pouvait l’exploiter avant les terres de patch vient de diminuer de plus de 95 %.

C’est le cas pour le traitement de la segmentation comme un contrôle fondamental. Cela n’élimine pas le besoin de patcher et n’exige pas une politique parfaite et granulaire dès le premier jour. La segmentation grossière, appliquée autour de vos systèmes à plus grande valeur, apporte toujours des bénéfices.  

Avec la bonne segmentation en place, une vulnérabilité qui aurait pu devenir une catastrophe majeure se transforme en un petit incident que votre équipe peut gérer en un après-midi.

Les recommandations elles-mêmes sont constantes depuis des années. Ce qui a changé, c’est le coût de l’ignorer, étant donné à quelle vitesse une nouvelle divulgation peut désormais devenir un exploit fonctionnel.

Trois décisions qui valent la peine d’être faites avant votre prochain cycle de divulgation

Quelques étapes concrètes sont ressorties de ma conversation avec Jason. J’encourage chaque responsable de la sécurité à peser ces questions par rapport à sa feuille de route actuelle.

Faites un véritable inventaire de ce qui est en cours et de qui devrait y accéder

Jason était catégorique à ce sujet. La technologie de segmentation n’apporte de la valeur que lorsqu’elle reçoit des données précises et lisibles par machine sur vos charges de travail et les identités qui y ont besoin. Sauter cette étape est la façon la plus rapide d’obtenir une politique qui semble bonne sur le papier et qui interrompt la production.

Segmentez dès maintenant vos systèmes de plus grande valeur, même grossièrement

Attendre une politique parfaite et entièrement cartographiée avant d’agir, c’est la paralysie de l’analyse contre laquelle Jason avait mis en garde directement. Un premier passage approximatif de vos actifs critiques l’emporte sur un plan magnifiquement documenté qui ne se livre jamais.

Mettez un minuteur de rafraîchissement sur vos systèmes hérités

Jason recommande d’exiger que tous les nouveaux systèmes suivent la gouvernance moderne dès le premier jour. Chaque système existant devrait bénéficier d’un cycle obligatoire de reconstruction ou de révision, disons une fois tous les 12 à 18 mois. Répartir ce travail sur le calendrier évite qu’il devienne un tas qu’aucune équipe ne peut jamais gérer.

Le moment d’agir est avant la prochaine divulgation, pas après

En juin, l’Agence de cybersécurité et de sécurité des infrastructures (CISA) a officiellement officiellé cette politique. La Directive opérationnelle contraignante 26-04 exige désormais que les agences fédérales remédient aux vulnérabilités les plus dangereuses (exposées publiquement, exploitées activement et automatisables) en trois jours, en baisse par rapport à la norme précédente de deux semaines. CISA a cité directement l’IA comme la raison, notant qu’elle augmente considérablement le rythme de découverte des vulnérabilités tant pour les attaquants que pour les défenseurs.

La directive ne lie que les agences fédérales, mais la CISA encourage le secteur privé à adopter la même approche. Les attentes de base du secteur concernant le temps de réponse ont déjà été réécrites.

La bonne nouvelle, c’est que rien de tout cela ne nécessite de réinventer votre programme de sécurité à partir de zéro. Il faut accepter qu’une faille survenant quelque part entre la divulgation et le patch soit désormais le scénario à prévoir. Et cela nécessite de construire une segmentation autour de vos systèmes les plus importants, de sorte que lorsqu’une faille survient, cela coûte un après-midi au lieu d’un titre.  

Les équipes qui considèrent cela comme urgent maintenant, alors qu’il y a encore un écart entre le paysage actuel des menaces et ce qui arrivera avec la prochaine génération de modèles, sont celles qui continueront à raconter une bonne histoire dans un an. Attendre un moment plus clair est un risque que les données ne supportent plus.

Écoutez l’épisode complet de The Segment : Un podcast sur le leadership zéro trust sur Apple Podcasts,  Spotifyou notre site web.