Points clés
- La plupart des organisations ne corrigent qu'environ 10 % de leurs vulnérabilités ouvertes par mois, quelle que soit leur taille ou leur maturité (Cyentia).
- Sur plus de 48 000 CVE publiées en 2025, environ 800 ont été exploitées dans la nature. Seulement 58 environ étaient atteignables et susceptibles d'être ciblées (Black Kite).
- CVSS et EPSS évaluent Internet, pas votre environnement. Aucun des deux ne peut classer votre backlog.
- Le score EPSS évolue généralement après la confirmation de l'exploitation, pas avant (Nucleus Security).
- L'automatisation IA intégrale perd du terrain : de 29 % à 9 % en un an, et 78 % des répondants signalent des failles critiques manquées (Cobalt).
- Le seul signal fiable est une tentative d'exploitation menée depuis l'extérieur et validée par un humain.
Une RSSI m'a confié récemment qu'elle n'avait pas besoin d'aide pour trouver des vulnérabilités. Elle en a déjà des milliers. Ce qu'il lui faut, c'est savoir lesquelles, parmi elles, comptent vraiment ce trimestre. Une douzaine, tout au plus.
Voilà ce qu'est devenue la priorisation des vulnérabilités. Non plus une fonction de reporting enfouie dans un scanner, mais la décision qui détermine si un budget sécurité produit une réelle réduction du risque ou simplement un backlog plus long. Et les données qui sous-tendent cette décision sont implacables.
Ce qu'est réellement la priorisation des vulnérabilités
La priorisation des vulnérabilités consiste à décider quelles vulnérabilités connues de votre environnement doivent être corrigées en premier, en fonction de la probabilité que chacune soit exploitée contre vous en particulier, et non de sa seule gravité théorique. En pratique, c'est un problème de filtrage : réduire des dizaines de milliers de CVE publiées à la courte liste de celles qu'un attaquant pourrait réellement utiliser contre vos actifs exposés.
En résumé : les scores de gravité décrivent une vulnérabilité, les preuves d'exploitabilité décrivent votre exposition, et seules les secondes permettent de classer un backlog.
Un plafond de remédiation qu'aucun recrutement ne fait sauter
Une étude du Cyentia Institute, portant sur 3,6 milliards d'observations de vulnérabilités, montre qu'une organisation type ne peut corriger qu'environ 10 % de ses vulnérabilités ouvertes par mois. Ce chiffre bouge à peine, que vous soyez une startup de cinq personnes ou une banque internationale dotée d'un programme mature. Ce n'est pas un manque de ressources que l'on comble en embauchant. C'est un plafond structurel.
Pendant ce temps, le volume ne cesse d'augmenter. Le premier semestre 2026 a produit à lui seul 35 364 nouvelles CVE, soit une toutes les 7,4 minutes, en hausse d'environ 50 % sur un an. Selon Tenable, le backlog moyen dépasse les 100 000 vulnérabilités ouvertes dans deux tiers des organisations. Les statistiques 2025 d'Edgescan indiquent que 45 % des vulnérabilités découvertes ne sont toujours pas corrigées au bout de douze mois.
La détection a largement dépassé la capacité à agir sur ce qui est détecté. Certains acteurs du secteur parlent de crise du « find but never fix », trouver sans jamais corriger. Le nom est juste.
48 000 CVE publiées, 58 qui comptaient vraiment
Voici le chiffre qui change toute la lecture du problème. Sur les plus de 48 000 CVE publiées en 2025, Black Kite estime qu'environ 800 ont été exploitées dans la nature. Si l'on ne garde que les vulnérabilités à la fois détectables depuis l'extérieur de votre périmètre et présentant une probabilité réellement élevée d'exploitation ciblée, il n'en reste que 58.
Quarante-huit mille publiées. Cinquante-huit qui comptaient vraiment.
Le problème n'a donc jamais été le volume. Le problème, c'est que presque rien dans la boîte à outils standard ne permet de savoir de manière fiable lesquelles, parmi ces 48 000, vous visent.
Pourquoi CVSS et EPSS ne peuvent pas prioriser les vulnérabilités de votre environnement
CVSS mesure la gravité théorique. Il ignore si vos contrôles spécifiques bloqueraient le chemin d'exploitation, et le FIRST lui-même précise que les scores de base ne doivent pas être utilisés seuls pour prioriser.
EPSS, l'Exploit Prediction Scoring System, fait mieux. Il estime la probabilité d'exploitation réelle à l'échelle d'Internet. Mais il n'a jamais vu votre environnement, et il arrive plus tard que la plupart des équipes ne le pensent.
Nucleus Security a étudié les CVE ajoutées au catalogue Known Exploited Vulnerabilities de la CISA et constaté que la variation médiane du score EPSS était 121 fois plus importante après la confirmation de l'exploitation qu'avant. Dans plusieurs cas, l'exploitation active était déjà en cours avant qu'EPSS n'envoie le moindre signal significatif.
| Signal |
À quelle question il répond |
Ce qu'il ne peut pas vous dire |
| CVSS |
Quelle est la gravité théorique de cette vulnérabilité ? |
Si elle est atteignable ou bloquée dans votre stack |
| EPSS |
Quelle est la probabilité d'exploitation quelque part sur Internet ? |
Si c'est vous la cible, et il évolue souvent après coup |
| CISA KEV |
A-t-elle été exploitée contre quelqu'un, de façon confirmée ? |
Si vous y êtes exposé en ce moment |
| Tentative d'exploitation externe |
Peut-elle être exploitée contre votre périmètre aujourd'hui ? |
Rien d'utile pour classer votre backlog |
Les systèmes de scoring globaux répondent à une question globale : à quel point cette vulnérabilité est-elle dangereuse, en général, sur Internet ? Ils n'ont jamais été conçus pour répondre à la seule question qui compte pour vous : est-elle exploitable, précisément, dans votre environnement, maintenant ?
Il n'existe qu'un moyen fiable d'y répondre : essayer, depuis l'extérieur, avec les mêmes outils et la même perspective qu'un véritable attaquant.
Pourquoi la réponse a encore besoin d'un humain
C'est là que les données récentes du secteur deviennent intéressantes. Le rapport 2026 AI and Pentesting Pulse de Cobalt, basé sur une enquête auprès de 455 professionnels de la sécurité, montre que la part des organisations s'appuyant entièrement sur l'automatisation IA pour leurs tests est passée de 29 % à 9 % en un an. La raison : 78 % ont vu des outils de scan entièrement automatisés passer complètement à côté de vulnérabilités critiques. Des faux négatifs, pas seulement des faux positifs bruyants.
Une étude de Stanford (ARTEMIS) comparant des agents IA de pentest autonomes à des testeurs humains a montré que le meilleur agent soumettait encore 18 % de résultats invalides. Les meilleurs testeurs humains atteignaient 100 % de résultats valides. Les outils d'agents génériques, non conçus pour cette tâche, faisaient bien pire : le meilleur d'entre eux ne dépassait pas 55 % de soumissions valides.
Rien de tout cela ne signifie que l'IA n'a pas sa place dans le processus. Cela signifie que l'IA excelle à générer des candidats et qu'elle est très mauvaise, seule, pour trancher si un candidat est réel. Quelqu'un doit combler cet écart, et aujourd'hui, ce quelqu'un est un humain qui engage son jugement professionnel.
Comment prioriser les vulnérabilités : quatre règles pour acheter des tests de sécurité
En assemblant ces éléments, une autre manière d'acheter des tests de sécurité s'impose naturellement.
- Tester depuis l'extérieur, comme le ferait réellement un attaquant. Pas seulement ce que voient les scanners internes, mais ce qui est visible et atteignable pour quelqu'un qui ne connaît rien de votre architecture.
- Faire valider chaque résultat par un humain avant qu'il n'arrive à votre équipe, pour que votre backlog devienne une liste de problèmes confirmés et exploitables, et non une liste encore plus longue de peut-être.
- Payer pour les résultats confirmés, pas pour le processus. Si le volume de découverte n'est pas le goulot d'étranglement, il n'y a aucune raison de continuer à payer pour du volume. Vous payez quand quelque chose de réel est trouvé, rien dans le cas contraire.
- Conserver la trace de tout ce qui a été tenté sans succès, pas seulement de ce qui a fonctionné. Cela compte presque autant que les résultats eux-mêmes. Quand un régulateur ou un auditeur vous demande comment vous savez que vos décisions de priorisation étaient fondées, répondre « voici tout ce que la boîte à outils d'un attaquant externe a tenté contre notre périmètre, et voici ce qui a tenu » est bien plus solide qu'un rapport de scanner. Avec des cadres comme NIS2 et DORA, cette distinction fait la différence entre un processus défendable et une simple affirmation.
Comment UNGUESS Security applique cette approche
UNGUESS Security est la branche sécurité offensive d'UNGUESS, avec un réseau de plus de 200 chercheurs en sécurité européens qui travaillent aux côtés d'agents IA spécialisés. Le modèle reprend directement les quatre règles ci-dessus.
La plateforme cartographie votre exposition comme la voit un hacker : même perspective de l'extérieur vers l'intérieur, aucune hypothèse sur une architecture interne que vous n'avez pas confirmée. Chaque résultat candidat est ensuite testé et validé par un hacker éthique qualifié avant de devenir une action pour votre équipe. Vous payez pour les vulnérabilités qui s'avèrent réelles, et rien pour les autres, car le modèle commercial repose par conception sur la rémunération au succès.
Vous obtenez aussi un compte rendu complet de tout ce qui a été tenté sur le reste, c'est-à-dire exactement la preuve qu'un auditeur ou un régulateur veut voir lorsqu'il demande comment vous saviez que vos priorités étaient les bonnes.
Pour voir le point de départ de cette analyse sur votre propre domaine, le scan de vulnérabilités en libre-service sur security.unguess.io/app cartographie vos actifs exposés à l'extérieur et fournit un rapport en quelques heures.
Le backlog ne va pas raccourcir
Le volume de CVE ne ralentit pas, et aucune organisation ne parviendra à zéro vulnérabilité ouverte à force de correctifs. Là n'a jamais été l'enjeu. L'enjeu, c'est de savoir avec certitude laquelle, parmi un grand nombre, un attaquant utiliserait réellement, et de pouvoir prouver, plus tard, que vous le saviez.
Voyez ce que voit un hacker : security.unguess.io/app