La société de capital-risque a16z vient de publier un graphique qui a fait le buzz sur X ces derniers jours. Ce graphique montre que le nombre de vulnérabilités CVE « critiques » et « élevées » est passé de moins de 100 par mois à plus de 600 par mois depuis le printemps 2026, chez 21 grands éditeurs de logiciels. Ces données proviennent d’Epoch AI et incluent les chiffres d’Apple, d’AWS, de Microsoft, de Google et d’Adobe.
Et comme il s'agit de X, bien sûr, les gens n'ont pas manqué de donner leur avis (oui, nous faisons de même ici).
Les avis étaient partagés. D'un côté, certains y voyaient un véritable changement en matière de risque, tandis que de l'autre, on soulignait que le nombre de vulnérabilités connues et exploitées (KEV) n'avait pas évolué depuis 2024 ; ainsi, le simple fait qu'il y ait davantage de divulgations ne signifie pas nécessairement un danger accru.
Même le rapport d’a16z lui-même se montre prudent à ce sujet :
« Qu’il y ait réellement davantage de vulnérabilités ou qu’il s’agisse d’un changement dans la manière de les signaler ou de les définir, il est difficile de se prononcer en se contentant d’observer le graphique ; mais il est probable qu’au moins une partie (voire une grande partie) de cette croissance parabolique soit imputable à un changement majeur et substantiel, soit dans la manière dont les vulnérabilités sont découvertes, soit dans ce qui est encore considéré comme sûr. »
Mais les deux camps se trompent complètement sur ce point. Ni le nombre brut de nouvelles vulnérabilités (CVE), ni un chiffre KEV constant ne déterminent réellement le risque. Le risque dépend de la rapidité avec laquelle on parvient à identifier les vulnérabilités qui comptent, et de la rapidité avec laquelle elles sont corrigées une fois validées.
Il est évident que l'IA a considérablement facilité la détection des vulnérabilités (tant pour les attaquants que pour les défenseurs). Les modèles de pointe détectent les vulnérabilités plus rapidement que les vérificateurs ne peuvent les valider, y compris des bogues de longue date qui avaient échappé à des années de vérification manuelle.
Ainsi, la hausse observée sur le graphique d'a16z s'explique en effet mieux par le fait que l'IA permet de détecter plus rapidement des failles qui existaient déjà, 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 tente de s'adapter à une détection aisée ?
Le NIST, l'organisme que tout le monde considère comme la référence absolue en matière de données sur les vulnérabilités, est confronté exactement au même problème, mais à une échelle bien plus grande. Partant du principe qu'un nombre plus élevé de CVE était synonyme de danger accru, il s'efforçait d'attribuer une note à chaque CVE qui lui était signalée. Mais le volume considérable de CVE rendait cette tâche pratiquement impossible. Et finalement, le système a cédé.
Un audit fédéral mené en mai dernier a révélé que le nombre de cas en attente était passé de 13 000 à plus de 27 000 en dix-huit mois. La solution proposée par le NIST ? Cesser de tout classer. À la place, il s’agit de donner la priorité aux CVE liés à une utilisation fédérale, aux logiciels critiques ou à ceux figurant déjà sur la liste des vulnérabilités connues pour être exploitées établie par la CISA. Tout le reste est classé comme « non programmé », et il y a donc de fortes chances pour qu'il ne fasse plus l'objet d'un examen ultérieur.
Le défi du NIST consiste à faire en sorte qu'une vulnérabilité soit signalée et évaluée. Mais même pour celles qui répondent pleinement à ces critères — c'est-à-dire qui sont confirmées, évaluées et dont on sait qu'elles font l'objet d'une exploitation active —, c'est au moment de leur correction que les choses semblent encore se compliquer.
La fixation constitue le goulot d'étranglement
Le rapport 2026 de Verizon sur les enquêtes relatives aux fuites de données, qui s'appuie sur plus d'un milliard d'enregistrements de vulnérabilités, a révélé que seules 26 % des vulnérabilités confirmées et activement exploitées (figurant sur la liste KEV de la CISA) avaient été entièrement corrigées en 2025, contre 38 % l'année précédente. Le délai médian nécessaire pour corriger entièrement une vulnérabilité est passé à 43 jours, contre 32 auparavant.
Même les organisations disposant des meilleures ressources ne parviennent à corriger complètement que 30 à 40 % de ces failles au cours de la première semaine. Verizon qualifie ce phénomène de « paradoxe de la correction », ce qui revient simplement à dire que les vulnérabilités se multiplient tandis que leur correction ralentit.
On sait que ces failles sont activement exploitées et figurent sur une liste publique. Et pourtant, elles ne sont toujours pas corrigées assez rapidement.
À quoi ressemble concrètement une réparation rapide ?
Ce mois-ci, une vulnérabilité RCE sans authentification, baptisée « Stylesmuggler », a commencé à toucher Adobe Commerce et Magento Open Source. Elle ne faisait l'objet d'aucun identifiant CVE ni d'aucun avis de la part d'Adobe.
Une vulnérabilité n'a pas besoin d'un numéro CVE ni d'un avis du fournisseur pour être réelle ou pour être exploitée. Attendre l'un ou l'autre avant d'agir revient à laisser aux attaquants une longueur d'avance. La seule façon de contourner ce problème est de s'appuyer sur 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 sont identifiées.
Aikido Intel l’a signalée de manière indépendante, sans attendre qu’Adobe ou un numéro CVE confirme son existence. L’entreprise a suivi cette vulnérabilité sous trois entités distinctes, et les bibliothèques Aikido ont fourni un correctif opérationnel pour plusieurs versions concernées. Ce correctif a été intégré sous la forme d’une pull request « AutoFix » directement dans le flux de travail déjà utilisé par les équipes, plutôt que de nécessiter une migration manuelle fastidieuse et distincte. Tout cela avant même qu’Adobe ne publie son propre correctif, plus de 24 heures plus tard.
StyleSmuggle n'est toutefois pas un cas isolé. Au cours de la première année d'activité d'Intel, 67 % des paquets dans lesquels l'entreprise a détecté des vulnérabilités n'ont jamais été rendus publics dans aucune base de données (ni sur le NVD, ni sur GitHub Advisory, ni sur MITRE, ni nulle part ailleurs).
En fait, la véritable histoire, c'est que…
L'augmentation du nombre de vulnérabilités répertoriées dans la base CVE s'apparente à celle du nombre de paquets npm publiés chaque année : elle s'accumule, ce qui rend son observation quelque peu… dénuée de sens. Ce qui importe, c'est la rapidité avec laquelle une vulnérabilité réelle et confirmée est corrigée, et à l'heure actuelle, dans l'ensemble du secteur, ce n'est pas assez rapide.
À mesure que l'IA démocratise les capacités de détection et d'exploitation, la cybersécurité doit se réinventer en se concentrant sur ce qui se passe une fois qu'une faille a été détectée. Cela commence par déterminer lesquelles, parmi les vulnérabilités identifiées, sont réellement accessibles et exploitables. L'outil analyse d’accessibilité de Aikido filtre tout ce qui ne dispose pas d'un chemin d'exécution vers le code vulnérable, tandis que CVE analyse de l’exploitabilité va plus loin : il analyse la manière dont un paquet est réellement utilisé dans votre environnement afin de déterminer s'il vaut la peine d'agir sur une vulnérabilité accessible.
Aikido Il propose deux méthodes de correction. Pour les problèmes connus et pouvant faire l'objet d'un correctif, AutoFix peut générer directement la correction. Pour les paquets open source, il applique le correctif à la version exacte déjà épinglée dans le fichier de verrouillage d'une équipe, sans nécessiter de mise à niveau ni de migration. Il fonctionne de la même manière pour les images de base de conteneurs vulnérables et le code des applications. Lorsqu'une correction nécessite une décision humaine, la vulnérabilité est tout de même signalée avec une recommandation spécifique et concrète, afin que quelqu'un puisse agir immédiatement au lieu de devoir d'abord déterminer la marche à suivre. La prochaine étape, qui consistera à mener ce processus jusqu'à la production sans attendre qu'une personne s'en charge merge , n'est plus très loin.
Il n'a jamais été aussi facile de détecter les vulnérabilités. Désormais, l'accent doit être mis sur la manière de distinguer les vulnérabilités du bruit de fond et de les corriger rapidement.
