Le record de CVE de MITRE montre que l’IA détecte les failles de sécurité plus vite que les équipes ne peuvent les traiter

MITRE a enregistré un nombre record de 48 244 vulnérabilités en 2025, et le record de CVE de MITRE a continué de grimper au cours du premier semestre 2026. Les recherches assistées par IA ont permis de découvrir les failles plus rapidement, mais le volume des divulgations dépasse désormais la capacité de nombreuses équipes de sécurité à vérifier, prioriser et corriger chaque découverte.

Plus de 35 000 vulnérabilités avaient été enregistrées en juin 2026, selon les totaux rapportés. Cela représentait déjà près des trois quarts du précédent record annuel. Cette croissance ne prouve pas simplement que les développeurs se sont soudainement mis à produire des logiciels bien moins sûrs.

Le changement profond concerne la découverte. Les systèmes d’IA peuvent inspecter de vastes bases de code, comparer des versions logicielles, proposer des scénarios d’attaque et faire remonter des comportements suspects à une échelle inaccessible aux chercheurs humains. Anthropic, OpenAI, Google, Microsoft et des fournisseurs de sécurité ont tous investi dans des modèles ou programmes de recherche axés sur la cybersécurité.

Cela crée une tension nette. Découvrir les faiblesses cachées plus tôt donne aux défenseurs le temps de les éliminer. Pourtant, chaque nouvelle divulgation entre aussi dans un système déjà sous pression, composé de mainteneurs, de coordinateurs, d’équipes de sécurité et de propriétaires d’actifs.

Le résultat n’est pas une simple explosion des attaques réussies. Les données disponibles montrent une forte hausse des divulgations, une augmentation plus limitée de l’exploitation observée, et un écart opérationnel croissant entre les deux.

Le record de CVE de MITRE progresse plus vite que les prévisions

Le changement déterminant n’est pas une vulnérabilité spectaculaire isolée. C’est l’accélération durable de tout le système de divulgation.

Un identifiant Common Vulnerabilities and Exposures, ou CVE, est une étiquette standardisée attribuée à une faille de sécurité divulguée publiquement. Les CVE permettent aux fournisseurs, chercheurs, gouvernements et outils de sécurité de désigner le même problème sans dépendre de noms incohérents.

Le nombre de cas enregistrés est resté de l’ordre de plusieurs dizaines de milliers par an entre 2017 et 2020. Il a atteint 20 161 en 2021, puis est passé à 40 077 en 2024 et à 48 244 en 2025. Plus de 35 000 avaient déjà été enregistrés en juin 2026.

Le Forum of Incident Response and Security Teams, connu sous le nom de FIRST, prévoyait un nouveau record avant même le début de l’année. Sa prévision de février situait l’estimation médiane pour 2026 à 59 427 CVE.

Les divulgations réelles ont rapidement dépassé cette trajectoire. La prévision de mi-année de FIRST a établi que le volume de publications jusqu’en avril était supérieur de 46,3 % à sa projection précédente. L’organisation a relevé son estimation annuelle à environ 66 000 CVE.

Cette réévaluation recensait 6 420 CVE de plus que le modèle initial ne l’avait prévu jusqu’en avril. Elle attribuait cet écart à plusieurs facteurs, notamment la découverte assistée par IA, l’élargissement des signalements et des changements au sein de l’écosystème CVE.

Le volume des GitHub Security Advisories avait augmenté de 449 % sur un an. L’activité du CNA of Last Resort de VulnCheck avait progressé de 3 119 %, l’organisation traitant un important arriéré de vulnérabilités dépourvues d’une autre autorité d’attribution.

Ces détails comptent, car le record de CVE de MITRE ne mesure pas un seul phénomène. Il regroupe de nouvelles recherches, d’anciennes découvertes entrant dans le système, les cycles de divulgation des fournisseurs, une couverture élargie et des évolutions administratives. Considérer chaque CVE supplémentaire comme une preuve de logiciels nouvellement moins sûrs reviendrait à mal interpréter les données.

Le nombre de produits logiciels représentés dans le suivi des vulnérabilités s’est lui aussi considérablement accru. Les chercheurs en sécurité examinent désormais davantage d’applications, d’appareils, de bibliothèques, de services cloud et de composants open source. Une meilleure visibilité révèle naturellement des failles qui restaient auparavant non documentées.

Les publications de grands fournisseurs peuvent provoquer de brusques pics mensuels. Une entreprise peut divulguer ensemble des centaines de problèmes connexes après avoir achevé un examen coordonné. Le graphique qui en résulte reflète donc le calendrier de publication autant que le rythme sous-jacent des découvertes.

Ces réserves n’effacent toutefois pas le changement. L’IA élargit la quantité de code que les chercheurs peuvent examiner et réduit le temps nécessaire pour identifier des faiblesses plausibles. Cette nouvelle capacité arrive alors que l’infrastructure de signalement fait déjà face à une charge de travail croissante.

Le record mesure donc à la fois les progrès et la pression. Davantage de failles deviennent visibles avant que les attaquants ne les trouvent, mais chaque signalement valide crée du travail pour les mainteneurs et les défenseurs.

La découverte de vulnérabilités par IA a changé l’échelle de la recherche de bugs

La découverte de vulnérabilités par IA transforme la revue de code, autrefois une activité manuelle rare, en un processus pouvant être exécuté à répétition sur d’immenses patrimoines logiciels.

La recherche traditionnelle de vulnérabilités exige que des spécialistes comprennent une application, identifient les comportements dangereux, élaborent des tests et confirment si une attaque est réalisable. Les scanners automatisés apportent leur aide, mais s’appuient souvent sur des modèles connus et génèrent des faux positifs.

Les modèles d’IA de pointe ajoutent une couche supplémentaire. Ils peuvent raisonner à travers les fichiers, suivre les données dans un programme, comparer des versions corrigées et non corrigées, générer des cas de test et suggérer des combinaisons de faiblesses. Les chercheurs humains doivent toujours valider les résultats importants, mais la phase de recherche peut couvrir davantage de terrain.

Claude Mythos Preview d’Anthropic est devenu un exemple marquant en 2026. L’entreprise a indiqué avoir commencé à utiliser un premier instantané du modèle en février pour examiner des logiciels open source. Des sociétés de sécurité externes ont ensuite contribué au triage, à la validation et au signalement des découvertes de gravité élevée ou critique.

Le tableau de bord de divulgation public d’Anthropic recensait 462 identifiants attribués dans un instantané d’août. Ils comprenaient 177 enregistrements CVE et 285 GitHub Security Advisories, bien qu’une même découverte puisse recevoir les deux identifiants.

Les affirmations plus générales étaient beaucoup plus importantes. Anthropic a déclaré que Project Glasswing avait découvert plus de 10 000 vulnérabilités de gravité élevée ou critique. Les archives publiques ne couvraient qu’une partie de ce total déclaré, empêchant les chercheurs d’évaluer la plupart des découvertes individuelles.

Epoch AI a examiné les données de divulgation de 21 grandes organisations technologiques, dont Microsoft, Google, Apple, Oracle, Cisco, Linux, Mozilla et Apache. Ses données de gravité ont montré qu’environ 1 550 CVE de gravité élevée et critique avaient été publiées en juin.

Ce total de juin dépassait trois fois le record mensuel observé avant l’annonce de Mythos Preview par Anthropic. Juillet a atteint environ 2 500 divulgations de gravité élevée et critique, soit près de cinq fois le record antérieur.

Epoch a averti que ces chiffres couvrent les divulgations publiques, et non toutes les failles découvertes en privé. L’organisation a également souligné que les évaluations de gravité évoluent à mesure que les enregistrements reçoivent de nouvelles informations. Les totaux mensuels historiques peuvent changer après la révision de CVE individuels par les analystes.

Le calendrier soutient néanmoins la conclusion selon laquelle les modèles de pointe sont devenus des outils de recherche significatifs. Les programmes d’IA ont commencé à fonctionner parallèlement à l’élargissement des audits internes, à de nouvelles initiatives de divulgation et à des investissements accrus de la part des grands fournisseurs.

Google a décrit son propre volume récent de découvertes comme inédit par son ampleur et sa rapidité. Les données des fournisseurs indiquaient que bon nombre des nouvelles failles signalées provenaient de recherches internes plutôt que d’attaquants externes. Cette distinction donne aux défenseurs l’occasion de corriger les faiblesses avant que des groupes criminels ne les transforment en armes.

L’IA aide aussi les chercheurs à réexaminer d’anciens logiciels. Du code ancien peut contenir des erreurs ayant survécu à des années de tests, faute de temps suffisant pour examiner chaque chemin d’exécution. Un modèle qui recherche continuellement les comportements suspects peut découvrir des vulnérabilités sans lien avec les développements récents.

Cet avantage dépasse les grandes entreprises technologiques. Les mainteneurs open source, les petits fournisseurs et les cabinets de conseil en sécurité peuvent utiliser l’analyse automatisée pour examiner des composants auxquels une attention limitée était auparavant accordée.

La découverte n’est toutefois que la première étape. Une faille plausible doit être reproduite, évaluée, signalée de manière sécurisée, recevoir un identifiant, être corrigée, testée et déployée. L’IA accélère le début de cette chaîne sans renforcer automatiquement chaque équipe qui intervient à sa fin.

Ce déséquilibre explique pourquoi davantage de découvertes ne produisent pas instantanément des systèmes plus sûrs. Le bénéfice dépend de la capacité des mainteneurs à transformer les résultats en correctifs fiables avant que les attaquants ne les transforment en exploits.

Davantage de divulgations ne signifient pas que chaque faille est une urgence

Le problème central de la cybersécurité est passé de la découverte d’un nombre suffisant de vulnérabilités à l’identification des résultats qui créent un risque immédiat et accessible.

Le record brut de CVE de MITRE est un décompte, et non une file de priorités. Une vulnérabilité dans une passerelle exposée à Internet et activement exploitée mérite une réponse différente d’une faille locale dans un composant inutilisé.

FIRST a examiné cette distinction à travers les données d’exploitabilité. Son évaluation de mi-année a filtré les vulnérabilités en utilisant le catalogue Known Exploited Vulnerabilities de la Cybersecurity and Infrastructure Security Agency et les résultats de l’Exploit Prediction Scoring System supérieurs à 10 %.

L’organisation a constaté que l’exploitabilité actionnable restait globalement stable malgré la hausse du volume total. Dans sa terminologie, les défenseurs faisaient face à davantage de pluie, mais pas nécessairement à une inondation proportionnellement plus importante.

Cette conclusion remet en cause une interprétation courante de la découverte de vulnérabilités par IA. Les modèles aident clairement les chercheurs à produire davantage de résultats. Les données actuelles ne montrent pas que chaque faiblesse trouvée par IA devienne plus facile ou plus attrayante à exploiter.

VulnCheck a analysé 1 061 découvertes publiques attribuées à l’IA, liées au Project Glasswing d’Anthropic et à la Berkeley Vulnerability Research Initiative. L’entreprise a constaté que 14 d’entre elles, soit 1,3 %, avaient été confirmées comme exploitées dans la nature.

Ce taux était proche du taux d’exploitation observé dans l’ensemble plus large de données de VulnCheck. La comparaison suggère que les découvertes assistées par IA n’étaient pas intrinsèquement plus susceptibles de devenir de véritables attaques que les vulnérabilités découvertes par des méthodes conventionnelles.

L’écart est encore plus net dans les résultats publiés par Anthropic. VulnCheck a rapporté que Claude Mythos avait identifié 23 019 candidats de vulnérabilités, tandis que seulement 126 étaient apparus comme des CVE dans son analyse. Une seule avait été confirmée comme exploitée.

Ces chiffres ne prouvent pas que les candidats restants étaient inoffensifs. Beaucoup pourraient encore être en cours d’examen, faire l’objet d’une divulgation coordonnée, attendre des correctifs ou être retenus parce que leur publication créerait un risque. Ils montrent que les décomptes de candidats et les CVE validés ne sont pas interchangeables.

Google Threat Intelligence Group est parvenu à une conclusion comparable à partir d’un ensemble de données différent. Son analyse de l’exploitation a recensé 141 vulnérabilités à la fois divulguées et exploitées entre janvier et août 2026.

Ce total dépassait les 127 recensées sur l’ensemble de l’année 2025. L’exploitation mensuelle moyenne est passée de 10,5 cas en 2025 à 18 en 2026.

Toutefois, seulement 0,23 % de toutes les vulnérabilités divulguées en 2026 semblaient faire l’objet d’une exploitation observée. Cela représentait environ une vulnérabilité activement exploitée pour 431 divulgations.

Ce faible pourcentage ne doit pas encourager la complaisance. Une seule vulnérabilité peut toucher des milliers d’organisations, notamment lorsqu’elle se trouve dans un produit largement déployé et exposé à Internet. Les attaquants n’ont pas besoin d’exploiter chaque CVE pour causer des dommages considérables.

Les données d’exploitation sont également devenues plus préoccupantes plus tard dans l’année. Google a constaté qu’après mai, la croissance des divulgations et celle des exploitations évoluaient étroitement. Le volume indexé de divulgations a augmenté de 128 %, tandis que l’exploitation indexée a progressé de 127 %.

L’exploitation à haut risque a plus que doublé. Google a recensé 75 vulnérabilités à haut risque exploitées de janvier à août 2026, contre 28 sur l’ensemble de l’année 2025.

L’activité liée aux zero days est restée plus stable. Un zero day est une vulnérabilité exploitée avant que l’éditeur ou les utilisateurs ne disposent d’un correctif efficace. La moyenne mensuelle est passée de huit en 2025 à 11 en 2026, bien qu’août ait atteint 22.

Google a suggéré que les attaquants pourraient tirer davantage de valeur immédiate de l’armement rapide de failles connues, appelées n-days, que de l’utilisation de l’IA pour découvrir des zero days entièrement nouveaux. Les modèles peuvent comparer les correctifs, les notes de version, les versions de produits et le code de preuve de concept afin d’accélérer ce processus.

C’est pourquoi les équipes de sécurité ont besoin de contexte sur les risques, et pas seulement de listes de vulnérabilités plus longues. Le catalogue des vulnérabilités exploitées de la CISA identifie les failles pour lesquelles il existe des preuves d’exploitation active. EPSS estime la probabilité qu’une CVE publiée soit prochainement exploitée.

Ces signaux sont imparfaits, mais ils aident les organisations à distinguer les faiblesses documentées des voies d’attaque urgentes. L’exposition des actifs, les privilèges, les systèmes accessibles et les mesures d’atténuation disponibles restent des éléments essentiels de cette décision.

Le véritable goulot d’étranglement est la capacité de triage et de correction

L’IA peut produire des constats de sécurité plus vite que les organisations ne peuvent déterminer les responsabilités, tester les correctifs et déployer les mises à jour en toute sécurité.

Chaque vulnérabilité valide déclenche un processus opérationnel. Un responsable de maintenance doit reproduire le problème, évaluer sa gravité, identifier les versions concernées, créer un correctif, tester les régressions, préparer un avis et coordonner la publication.

Les clients sont ensuite confrontés à leur propre chaîne d’actions. Ils doivent localiser le produit concerné, comprendre si une fonctionnalité vulnérable est active, évaluer les contrôles compensatoires, planifier une mise à jour et confirmer que le correctif a réussi.

Ce travail devient difficile lorsqu’une organisation ne dispose pas d’un inventaire logiciel précis. Une équipe de sécurité ne peut pas prioriser une vulnérabilité avec confiance si elle ignore où le composant affecté s’exécute ou quels services métier en dépendent.

Les dépendances tierces compliquent encore le problème. Une bibliothèque vulnérable peut se trouver plusieurs couches sous une application et rester invisible pour son opérateur. Les conteneurs, plugins, micrologiciels et services managés peuvent encore davantage obscurcir les responsabilités.

Les pénuries de main-d’œuvre intensifient la pression. Yukimi Sota, de la branche japonaise de Proofpoint, a déclaré au service d’information d’origine que de nombreuses entreprises prenaient du retard dans leurs contre-mesures, faute de travailleurs en nombre suffisant dans le secteur de la sécurité.

De récents accès non autorisés et fuites d’informations chez des entreprises japonaises ont donné une urgence supplémentaire à ce constat. Les incidents auraient notamment concerné Times Car, un important service d’autopartage, et ont conduit le gouvernement japonais à exhorter les entreprises à renforcer leurs défenses.

Le risque immédiat n’est pas que chaque nouvelle CVE exige un déploiement d’urgence. Le risque est qu’une file non structurée conduise les équipes à manquer le petit nombre de failles que les attaquants exploitent déjà.

Corriger toutes les vulnérabilités dans l’ordre de publication gaspillerait un temps précieux. Cela pourrait également provoquer des interruptions lorsque des changements précipités affectent des systèmes de production complexes. Les défenseurs doivent combiner le renseignement sur les menaces avec leur propre contexte d’actifs et d’activité.

Une séquence de priorisation pratique commence par l’exploitation active. Les équipes doivent ensuite prendre en compte l’exposition à Internet, les exigences d’authentification, la complexité de l’attaque, les privilèges obtenus, la sensibilité des données et l’importance du service concerné.

La gravité attribuée par l’éditeur ne peut à elle seule répondre à ces questions. Une vulnérabilité critique dans un système de test isolé peut présenter un danger moins immédiat qu’une faille de gravité élevée sur une passerelle publique.

Les équipes de sécurité ont également besoin d’un moyen fiable de conserver les décisions. Les avis, les dossiers d’exception, les notes sur les systèmes affectés et les preuves d’atténuation se retrouvent souvent dispersés entre tickets, discussions, feuilles de calcul et e-mails.

Une base de connaissances technique consultable peut aider les équipes à relier les avis de vulnérabilité aux documents d’architecture et aux travaux de remédiation antérieurs. Elle ne remplace ni l’analyse ni la correction, mais réduit les investigations répétées.

L’IA peut également aider à ce stade. Un modèle peut résumer les avis, faire correspondre les noms de produits aux inventaires, comparer les versions, rédiger des instructions de remédiation et aider les analystes à regrouper les rapports en double.

Ces usages exigent des contrôles. Les équipes de sécurité doivent vérifier les conclusions générées, protéger les informations confidentielles sur les systèmes et éviter d’envoyer des identifiants ou des détails d’architecture sensibles à des services non autorisés.

Les correctifs automatisés créent un risque distinct. Un patch qui supprime un chemin de code vulnérable peut introduire un autre défaut ou perturber le comportement en production. Les responsables de maintenance ont toujours besoin de tests, de revue et d’un déploiement progressif.

La pression se répartit inégalement dans l’écosystème logiciel. Les grands éditeurs peuvent disposer d’équipes dédiées à la sécurité des produits et coordonner des cycles de divulgation de masse. Les petits projets open source peuvent dépendre de quelques bénévoles pour gérer des milliers d’utilisateurs.

La recherche assistée par IA peut donc transférer des coûts des développeurs de modèles et laboratoires de sécurité bien financés vers des responsables de maintenance aux ressources limitées. Trouver davantage de bogues est utile, mais les programmes de divulgation doivent tenir compte de la capacité de réponse des destinataires.

Un signalement responsable nécessite une déduplication, des étapes de reproduction claires, des preuves de gravité et des délais de remédiation raisonnables. Soumettre des milliers d’alertes à faible niveau de confiance consommerait de l’attention sans produire des gains de sécurité équivalents.

Le meilleur résultat est une chaîne équilibrée. L’IA recherche largement, les humains valident les constats conséquents, les responsables de maintenance reçoivent des rapports utiles et les défenseurs classent les déploiements selon l’exposition réelle.

Sans cette discipline, un volume de découvertes plus élevé devient une nouvelle source de fatigue liée aux alertes. Les équipes voient davantage d’avertissements, tandis que les quelques plus dangereux restent enfouis.

L’IA transforme les deux camps de la course aux vulnérabilités

La compétition stratégique n’oppose pas des défenseurs utilisant l’IA à des attaquants traditionnels. Les deux camps peuvent exploiter des capacités similaires à différentes étapes du même cycle de vie des vulnérabilités.

Les défenseurs obtiennent actuellement un avantage significatif lorsque des programmes internes d’IA trouvent et corrigent des failles avant leur publication. Google a indiqué que 401 des 433 vulnérabilités Chrome d’une importante mise à jour avaient été découvertes en interne.

Cette tendance suggère que la hausse des divulgations comprend des travaux préventifs. Une découverte contrôlée par l’éditeur permet aux ingénieurs de développer un correctif, de coordonner sa publication et de préparer les clients avant que des informations techniques détaillées ne se diffusent.

Les attaquants gagnent en levier après la divulgation. L’IA peut assimiler un avis, comparer les changements de code, générer une preuve de concept, rechercher des systèmes exposés et adapter du code d’exploitation public. Ces activités réduisent le délai entre publication et tentative d’exploitation.

Recorded Future a indiqué que le délai moyen nécessaire aux attaquants pour exploiter des vulnérabilités était passé de 72 heures en 2025 à 24 heures en 2026. Cette estimation renforce la nécessité de prioriser immédiatement les failles accessibles, même si la plupart des CVE n’apparaissent jamais dans les attaques observées.

Les systèmes d’IA pourraient à terme découvrir et exploiter de manière autonome des failles inconnues. Des cas publics et des affirmations de fournisseurs montrent des progrès vers des chaînes de travail de cybersécurité plus longues, mais les preuves disponibles restent inégales.

Certaines démonstrations ont lieu dans des environnements contrôlés, avec des cibles soigneusement sélectionnées, d’importantes ressources informatiques, des instructions personnalisées et une supervision experte. Leurs résultats n’établissent pas que des criminels ordinaires puissent reproduire les mêmes performances à grande échelle.

Palo Alto Networks a déclaré que des modèles avancés d’Anthropic et d’OpenAI l’avaient aidé à trouver 75 vulnérabilités dans ses produits, soit plus de sept fois son nombre mensuel habituel. Son directeur produit a également reconnu que l’effort nécessitait une personnalisation importante et une expertise humaine.

Cette réserve est importante. La capacité d’un modèle n’est qu’une partie d’une attaque opérationnelle. Les adversaires ont encore besoin d’un accès à la cible, d’infrastructure, de validation, de discrétion, de persistance et d’un moyen de transformer l’accès technique en résultat utile.

Les défenseurs disposent aussi d’avantages structurels. Les éditeurs contrôlent le code source, les tests internes, la télémétrie produit et la distribution des correctifs. Ils peuvent orienter les modèles vers leurs propres systèmes et valider les résultats avec des ingénieurs qui comprennent l’architecture.

Les attaquants bénéficient d’une asymétrie. Il leur suffit d’une voie utile vers une cible, tandis que les défenseurs doivent gérer tous les systèmes importants. L’IA ne crée pas ce déséquilibre, mais une recherche plus rapide peut l’intensifier.

La divulgation elle-même relie les deux camps. La publication d’une CVE donne aux défenseurs un identifiant commun et des informations de remédiation. Elle peut aussi indiquer aux attaquants où concentrer leurs efforts, particulièrement lorsqu’un correctif révèle le code vulnérable.

Retarder indéfiniment la divulgation n’est pas une solution. Des failles non signalées peuvent rester exploitables sans offrir aux clients de voie de protection. L’objectif est une coordination qui donne aux responsables de maintenance le temps de publier un correctif tout en limitant l’exposition technique inutile.

Les preuves les plus solides à ce jour étayent une conclusion plus limitée que les affirmations optimistes ou alarmistes. L’IA accroît déjà la capacité de découverte des vulnérabilités. Elle aide aussi à l’analyse et au développement d’exploits, mais l’exploitation n’a pas augmenté en proportion directe des divulgations brutes.

Cet équilibre peut changer. Les modèles s’améliorent, la formation centrée sur la cybersécurité s’étend et davantage d’organisations intègrent des agents dans leurs flux de recherche. Les contrôles d’accès autour des systèmes les plus capables influeront sur la vitesse à laquelle ces capacités se diffuseront.

Les responsables de la sécurité devraient éviter de planifier autour d’une seule prédiction spectaculaire. Ils devraient supposer que la découverte et l’armement vont tous deux s’accélérer, puis bâtir des processus qui resteront utiles selon plusieurs calendriers possibles.

Cela implique des cycles plus courts d’identification des actifs, des procédures d’urgence de correction testées, une meilleure segmentation et une surveillance plus robuste de l’exploitation. Cela implique aussi d’utiliser l’IA défensive là où ses résultats peuvent être vérifiés par rapport à des données faisant autorité.

Ce que les équipes de sécurité devraient surveiller ensuite

Trois signaux montreront si la hausse des vulnérabilités reste gérable ou se transforme en crise d’exploitation plus vaste.

Le premier signal est la relation entre le nombre total de CVE et l’exploitation confirmée. Les volumes bruts de divulgation continueront probablement à battre des records, mais ils ne déterminent pas à eux seuls le risque opérationnel.

Les équipes devraient suivre le catalogue de la CISA, la télémétrie d’exploitation et les scores de probabilité à forte confiance. Si les vulnérabilités exploitées restent une faible part des divulgations, la priorisation peut contenir une grande partie de la charge de travail.

Si l’exploitation commence à croître plus rapidement que les divulgations, l’argument central change. Cela indiquerait que les attaquants convertissent une part plus importante des découvertes en opérations fonctionnelles, et ne profitent pas simplement d’un bassin plus vaste.

Le deuxième signal est le délai entre découverte, validation et disponibilité d’un correctif. Les programmes assistés par IA peuvent revendiquer des milliers de candidats, alors que seule une fraction apparaît dans les avis publics accompagnés de correctifs.

Une réduction du délai de conversion montrerait que les éditeurs et coordinateurs développent leur capacité en parallèle de la découverte. Un arriéré croissant signifierait que l’IA a accéléré le début de la chaîne sans résoudre le goulot d’étranglement plus difficile de la remédiation.

Les registres publics devraient faciliter cette évaluation. Un rapport utile distinguerait les candidats, les vulnérabilités validées, les identifiants attribués, les correctifs finalisés et les correctifs déployés.

Le troisième signal est la vitesse d’exploitation après la publication d’un correctif ou d’un avis de sécurité. Les défenseurs mesuraient autrefois les délais de réaction en semaines pour de nombreuses vulnérabilités. Des preuves d’une mise en arme systématique en moins d’une journée pousseraient davantage d’organisations à automatiser les contrôles d’exposition et les corrections d’urgence.

Ce signal compte davantage que des démonstrations de laboratoire spectaculaires. Une réduction répétable du délai de mise en arme dans le monde réel affecterait toutes les entreprises utilisant des logiciels courants, même si les attaquants n’acquièrent jamais une capacité pleinement autonome de découverte de vulnérabilités zero-day.

L’enregistrement CVE de MITRE devrait donc inciter à revoir les processus, et non à céder à une panique indiscriminée. Les organisations doivent savoir quels systèmes elles exploitent, lesquels sont exposés à internet et qui prend les décisions de correction.

Elles doivent également vérifier que les mises à jour urgentes peuvent passer de l’avis de sécurité au déploiement sans se retrouver bloquées dans des circuits d’approbation. Des procédures d’urgence qui n’existent que sur le papier ne seront pas adaptées à une fenêtre d’exploitation de 24 heures.

La découverte de vulnérabilités par l’IA demeure une opportunité pour la défense. Elle peut révéler d’anciennes faiblesses avant que des criminels ne les trouvent et aider les responsables de maintenance à examiner du code qui n’a pas reçu une revue suffisante.

Le bénéfice dépend de ce qui se passe après la découverte. Une découverte que personne ne valide génère du bruit. Une CVE validée sans correctif disponible crée une exposition. Un correctif que les clients ne peuvent pas déployer laisse le risque sous-jacent en place.

Pour les développeurs, les responsables de la sécurité et les acheteurs de technologies, la question essentielle n’est plus de savoir si l’IA peut trouver davantage de failles. Les preuves indiquent que oui. La question est de savoir si votre organisation peut transformer ce flot de découvertes en une courte liste d’actions hiérarchisées avant qu’un attaquant ne fasse de même.