La société de capital-risque a16z vient de partager un graphique qui fait sensation sur X ces derniers jours. Le graphique montre que les CVE critiques et élevées sont passées de moins de 100 par mois à plus de 600 par mois depuis le printemps 2026 auprès de 21 grandes entreprises de logiciels. Les données proviennent d'Epoch AI et incluent des décomptes provenant d'Apple, AWS, Microsoft, Google et Adobe.
Et comme nous sommes sur X, les réactions n'ont évidemment pas tardé (oui, nous faisons la même chose ici).
Elles se sont divisées en deux camps. L'un y a vu un réel changement de risque, tandis que l'autre a souligné que les vulnérabilités connues et exploitées (KEV) n'avaient pas bougé depuis 2024, ce qui signifie que ce n'est pas parce qu'il y a plus de divulgations qu'il y a nécessairement plus de danger.
Même le rapport d'a16z nuance ce point :
« Qu'il y ait réellement plus de vulnérabilités, ou qu'il s'agisse d'un changement dans les rapports ou les définitions, il est difficile de le dire rien qu'en regardant le graphique, mais il est probable qu'au moins une partie (et peut-être une grande partie) de cette croissance parabolique soit attribuable à un changement de fond majeur, soit dans la manière dont les vulnérabilités sont découvertes, soit dans ce qui est encore considéré comme sécurisé. »
Mais les deux camps font fausse route. Ni le nombre brut de nouvelles CVE ni un chiffre KEV stable ne déterminent réellement le risque. Le risque dépend de la rapidité avec laquelle vous pouvez identifier les vulnérabilités qui comptent, et de la rapidité avec laquelle elles sont corrigées une fois validées.
Il est clair que l'IA a grandement facilité la découverte de vulnérabilités (tant pour les attaquants que pour les défenseurs). Les modèles de pointe trouvent les vulnérabilités plus rapidement que les réviseurs ne peuvent les valider, y compris des bogues de longue date qui ont résisté à des années de révision manuelle.
Le bond constaté dans le graphique d'a16z s'explique donc mieux par le fait que l'IA permet de trouver plus rapidement des bogues préexistants, plutôt que par une baisse soudaine de la sécurité des logiciels. Mais ce n'est qu'une partie de l'histoire.
Que se passe-t-il lorsqu'une institution essaie de suivre le rythme d'une détection facilitée
Le NIST, l'institution considérée par tous comme la référence absolue en matière de données sur les vulnérabilités, fait face exactement au même problème à plus grande échelle. Partant du principe que plus de CVE signifiait plus de danger, il s'était efforcé d'évaluer chaque CVE reçue. Mais le volume considérable de CVE a rendu la tâche pratiquement impossible. Et le système a fini par céder.
Un audit fédéral réalisé en mai dernier a révélé que le retard accumulé était passé de 13 000 à plus de 27 000 en dix-huit mois. La solution suggérée par le NIST ? Arrêter d'évaluer tout. À la place, il priorise les CVE liées à l'usage fédéral, aux logiciels critiques ou figurant déjà sur la liste des vulnérabilités connues et exploitées de la CISA. Tout le reste est étiqueté « non planifié », et il est donc probable qu'on ne s'y attarde plus.
La difficulté du NIST concerne la divulgation et l'évaluation des vulnérabilités. Mais même pour celles qui franchissent cette étape haut la main — c'est-à-dire confirmées, évaluées et reconnues comme activement exploitées —, c'est au moment de la correction que les choses semblent encore bloquer.
La correction est le goulet d'étranglement
Le rapport 2026 de Verizon sur les enquêtes sur les violations de données, qui s'appuie sur plus d'un milliard d'enregistrements de vulnérabilités, a révélé que seulement 26 % des vulnérabilités confirmées et activement exploitées (présentes sur la liste KEV de la CISA) ont été entièrement corrigées en 2025, contre 38 % l'année précédente. Le délai médian pour corriger entièrement une vulnérabilité est passé de 32 à 43 jours.
Même les organisations les mieux dotées en ressources ne corrigent entièrement que 30 à 40 % d'entre elles au cours de la première semaine. Verizon appelle cela le « paradoxe de la remédiation », ce qui est une façon polie de dire que les vulnérabilités s'accélèrent tandis que la correction ralentit.
Ces vulnérabilités sont reconnues comme étant activement exploitées et figurent sur une liste publique. Et pourtant, elles ne sont toujours pas corrigées assez rapidement.
À quoi ressemble une correction rapide en pratique
Ce mois-ci, une vulnérabilité d'exécution de code à distance (RCE) non authentifiée baptisée Stylesmuggler a commencé à frapper Adobe Commerce et Magento Open Source. Elle ne disposait d'aucun identifiant CVE ni d'aucun bulletin de sécurité de la part d'Adobe.
Une vulnérabilité n'a pas besoin d'un numéro CVE ou d'un avis de l'éditeur pour être réelle ou exploitée. Attendre l'un ou l'autre avant d'agir, c'est donner une longueur d'avance aux attaquants. La seule façon d'y parer est de s'en remettre à un outil capable de détecter et de confirmer les vulnérabilités de manière autonome, puis de les corriger rapidement dès qu'elles le sont.
Aikido Intel l'a signalée de manière indépendante, sans attendre qu'Adobe ou un numéro CVE ne confirme sa véracité. Elle a suivi la vulnérabilité sous trois entités distinctes, et Aikido Libraries a déployé un correctif fonctionnel pour de multiples versions affectées. Celui-ci a été livré sous forme de pull request AutoFix directement intégrée au flux de travail des équipes, plutôt que sous la forme d'une migration manuelle distincte et laborieuse. Tout cela avant qu'Adobe ne publie son propre correctif d'urgence plus de 24 heures plus tard.
StyleSmuggle n'est pourtant pas un cas isolé. Au cours de la première année d'activité d'Intel, 67 % des paquets dans lesquels des vulnérabilités ont été détectées n'avaient jamais fait l'objet d'une divulgation publique dans aucune base de données (ni NVD, ni GitHub Advisory, ni MITRE, nulle part ailleurs).
La véritable histoire est donc…
La hausse du volume des CVE s'apparente au nombre de paquets npm publiés chaque année : elle s'accumule, ce qui rend sa surveillance en quelque sorte... dénuée de sens. Ce qui importe, c'est la rapidité avec laquelle une vulnérabilité réelle et avérée est corrigée, et actuellement, à l'échelle de l'industrie, ce n'est pas assez rapide.
À l'ère où l'IA banalise les capacités de détection et d'exploitation, la cybersécurité doit se réinventer autour de ce qui se passe après qu'une anomalie a été découverte. Cela commence par identifier lesquelles des vulnérabilités recensées sont réellement accessibles et exploitables. L'analyse d'accessibilité d'Aikido élimine tout ce qui ne présente aucun chemin d'exécution vers le code vulnérable, et l'analyse de l'exploitabilité des CVE va plus loin en évaluant la manière dont un paquet est réellement utilisé dans votre environnement pour déterminer si une vulnérabilité accessible mérite d'être traitée.
Aikido propose deux méthodes de correction. Pour les problèmes connus et corrigeables, AutoFix peut générer la correction directement. Pour les paquets open source, l'outil corrige la version exacte déjà épinglée dans le fichier de verrouillage d'une équipe, sans nécessiter de mise à niveau ni de migration. Cela fonctionne de la même manière pour les images de base de conteneurs vulnérables et le code applicatif. Lorsqu'une correction requiert une décision humaine, la vulnérabilité est tout de même signalée avec une recommandation spécifique et exploitable, permettant d'agir immédiatement au lieu de chercher par où commencer. L'étape suivante, qui consiste à automatiser ce processus jusqu'en production sans attendre qu'un membre merge la modification, n'est plus très loin.
Détecter des vulnérabilités n'a jamais été aussi simple. Désormais, l'accent doit être mis sur la manière de filtrer les vulnérabilités pour éliminer les faux positifs et de les corriger rapidement.
