CVSS, EPSS, KEV : quelle vulnérabilité corriger en premier ?

Introduction

Un rapport de scan sur un périmètre de taille moyenne, c'est facilement quelques centaines de lignes. Une équipe d'exploitation normale en corrige quelques dizaines par mois, entre deux mises en production. L'écart entre les deux ne se comble pas en travaillant plus : il se gère en choisissant.

Et la manière dont la plupart des organisations choisissent est restée la même depuis quinze ans : on trie par score CVSS décroissant, on traite les « critiques », puis les « élevées » si le trimestre le permet. C'est simple et défendable en comité. C'est aussi, chiffres à l'appui, une des façons les moins efficaces de dépenser du temps de correction.

Cet article explique ce que mesurent réellement les trois indicateurs publics dont tout le monde parle (CVSS, EPSS, KEV), ce qu'aucun des trois ne sait, et la règle de tri que nous appliquons nous-mêmes. Elle tient en un tableau, et elle commence par une question qui n'est dans aucun des trois : est-ce que c'est joignable depuis Internet ?

Le problème : trop de CVE, et presque toutes sans conséquence

Plus de 40 000 CVE ont été publiées en 2024, et 2025 a encore battu ce record. Personne ne lit ça. Personne ne corrige ça non plus.

Le point important est ailleurs : seule une petite minorité de ces vulnérabilités sera un jour exploitée pour de vrai. Les études que cite FIRST dans la documentation d'EPSS situent cette part entre 2 et 7 % des vulnérabilités publiées. La même documentation rappelle qu'une organisation parvient à corriger, selon les mois, entre 5 et 20 % de ses vulnérabilités connues.

Mettez les deux chiffres côte à côte. La capacité de correction est du même ordre que le volume réellement dangereux. Le problème n'est donc pas de manquer de bras, il est de les pointer au bon endroit. Une équipe qui corrige 10 % de son stock en visant juste est mieux protégée qu'une équipe qui en corrige 40 % en suivant l'ordre du rapport.

CVSS : la gravité, pas le risque

Le CVSS (Common Vulnerability Scoring System) est maintenu par FIRST. La version 4.0 date du 1er novembre 2023, mais l'immense majorité des scores que vous croiserez sont encore en 3.1. L'échelle est connue : de 0 à 10, « critique » à partir de 9.

Ce qu'on oublie, c'est ce que le score mesure. Le guide d'utilisation de FIRST l'écrit noir sur blanc : le score de base mesure la sévérité, pas le risque. Il répond à la question « si cette faille est exploitée, dans le pire cas raisonnable, à quel point est-ce grave, et à quel point est-ce facile ? ». Il ne répond pas à « quelqu'un est-il en train de l'exploiter ? », encore moins à « est-ce grave chez moi ? ».

Le standard prévoit pourtant de quoi répondre. CVSS 4.0 distingue quatre groupes de métriques :

• Base : les caractéristiques intrinsèques de la faille. C'est le chiffre publié par la NVD et par les éditeurs.
• Threat : la maturité de l'exploitation (aucune trace, preuve de concept publique, attaques observées).
• Environmental : votre contexte. Le composant est-il exposé ? La confidentialité compte-t-elle sur ce système ?
• Supplemental : des informations complémentaires (automatisable, effort de récupération) qui ne changent pas la note.

La version 4.0 a même introduit une nomenclature pour qu'on sache de quoi on parle : CVSS-B pour le score de base seul, CVSS-BT avec la menace, CVSS-BTE avec menace et environnement. L'intention est transparente. FIRST voudrait qu'on arrête de piloter avec un CVSS-B.

Dans les faits, presque personne ne renseigne les deux autres groupes, parce que cela demande de connaître son parc et de suivre l'actualité de chaque CVE. On pilote donc avec le score de base, c'est-à-dire avec une note de gravité théorique, identique pour toutes les entreprises du monde.

KEV : ce qui est exploité, preuve à l'appui

Le catalogue KEV (Known Exploited Vulnerabilities) est tenu par la CISA, l'agence américaine de cybersécurité, depuis novembre 2021. Il accompagne une directive (BOD 22-01) qui oblige les agences fédérales civiles à corriger chaque entrée avant une date limite, en général deux à trois semaines après l'ajout.

Pour entrer au catalogue, une vulnérabilité doit remplir trois conditions : avoir un identifiant CVE, faire l'objet de preuves fiables d'exploitation active, et disposer d'une action corrective claire (un correctif, une mesure de contournement, ou le retrait du produit). Le catalogue compte aujourd'hui plus de 1 500 entrées. Rapporté aux centaines de milliers de CVE existantes, c'est minuscule, et c'est tout son intérêt.

Deux choses le rendent directement utilisable. Il est publié en JSON et en CSV, sans clé ni inscription. Et chaque entrée porte un champ knownRansomwareCampaignUse, qui signale les failles vues dans des campagnes de rançongiciel. Pour une PME française, c'est probablement le champ le plus parlant de tout l'écosystème.

Ses limites, maintenant. Le KEV est un signal binaire et tardif : une faille y entre quand l'exploitation est établie, donc après les premières victimes. Il reflète aussi les priorités de son auteur. Les produits très présents dans l'administration américaine y sont mieux couverts qu'un CMS français ou un ERP sectoriel. L'absence d'une CVE du catalogue ne prouve rien. Sa présence, en revanche, clôt le débat : si c'est au KEV et que c'est chez vous, la question n'est plus de savoir s'il faut corriger.

EPSS : la probabilité que ça arrive

EPSS (Exploit Prediction Scoring System) est l'autre projet de FIRST, plus récent et beaucoup moins connu des comités de direction. C'est un modèle statistique, recalculé chaque jour pour l'ensemble des CVE publiées, qui estime la probabilité qu'une tentative d'exploitation soit observée dans les 30 jours à venir. Le modèle en est à sa quatrième version, publiée en mars 2025.

Chaque CVE reçoit deux valeurs, et il ne faut pas les confondre :

• la probabilité, entre 0 et 1. Un EPSS de 0,42 signifie 42 % de chances d'observer de l'exploitation dans le mois ;
• le percentile, qui situe la CVE par rapport aux autres. Un percentile de 0,95 veut dire que 95 % des CVE ont un score inférieur.

La distribution est très déséquilibrée : l'écrasante majorité des CVE a un score proche de zéro. Une probabilité de 0,1 paraît faible dans l'absolu. Elle place pourtant la vulnérabilité dans les tout premiers pour cent du classement.

L'argument qui nous a convaincus se trouve dans l'article de recherche qui accompagne la version 3 du modèle (Jacobs et al., 2023). Les auteurs comparent deux stratégies sur les mêmes données. Corriger tout ce qui a un CVSS de base d'au moins 7 couvre 82 % des vulnérabilités effectivement exploitées, au prix d'un effort portant sur 58 % de toutes les CVE. Obtenir la même couverture avec EPSS (seuil à 0,088) demande de traiter 7,3 % des CVE. Huit fois moins de travail pour le même résultat.

Reste à bien lire ce que le score dit. EPSS estime la probabilité que les partenaires du projet observent de l'exploitation avec leurs capteurs. Une exploitation discrète et ciblée, qui ne déclenche aucune signature réseau, y sera sous-représentée. Une CVE publiée hier aura un score bas, simplement parce que le modèle n'a encore aucun signal : ce n'est pas un certificat d'innocuité. Et EPSS ne dit rien de l'impact. FIRST le répète dans sa FAQ, le score ignore votre contexte et vos mesures compensatoires.

Ce qu'aucun des trois ne sait : votre exposition

CVSS décrit la faille. KEV et EPSS décrivent ce qu'en font les attaquants. Aucun ne vous décrit, vous.

Or la variable qui pèse le plus lourd dans un tri est locale : le composant vulnérable est-il joignable, et par qui ? Une exécution de code à distance notée 9.8 sur un outil interne accessible à douze personnes derrière un VPN est un vrai sujet, à traiter dans le cycle normal. La même sur un service qui répond à toute la planète est une urgence, parce que les scanners de masse l'auront trouvée avant la fin de la journée.

Cela suppose de savoir ce qu'on expose, et c'est là que la plupart des démarches de priorisation s'enlisent. On ne peut pas marquer un actif « exposé » si l'on ignore son existence. Le sous-domaine de préproduction monté par un prestataire il y a trois ans n'est dans aucune CMDB, donc dans aucun tri. Nous avons détaillé la construction de cet inventaire dans notre article sur la cartographie du système d'information. C'est le prérequis de tout ce qui suit.

La règle de tri que nous appliquons

Voici l'ordre dans lequel nous posons les questions. Il n'a rien d'original, il ressemble de près à ce que la CISA formalise dans son arbre de décision SSVC. Son mérite est de tenir sur une demi-page et de pouvoir être appliqué par quelqu'un qui n'a pas assisté à la réunion où il a été décidé.

Trois remarques sur ce tableau.

Les délais sont les nôtres, pas une norme. Une équipe de deux personnes peut légitimement écrire 5 jours au rang 1. Ce qui compte, c'est que le chiffre soit écrit, tenu et mesuré.

Le seuil EPSS à 0,1 est un point de départ. S'il remonte trop de lignes pour votre capacité, montez-le. S'il n'en remonte presque aucune, descendez-le. Un seuil se règle sur ce que vous pouvez réellement traiter, pas sur ce qui rassure.

Et le rang 5 n'est pas une poubelle. « Cycle normal » suppose qu'il existe un cycle normal, c'est-à-dire des mises à jour régulières qui emportent la longue traîne sans qu'on ait à l'examiner ligne à ligne. Sans ce cycle, le rang 5 grossit jusqu'à fournir les rangs 1 de l'année suivante.

Exemple : cinq lignes d'un même rapport

Prenons un rapport fictif mais réaliste, trié comme il sort de l'outil, par CVSS décroissant.

Avec un tri par CVSS, l'équipe commence par A et B. Deux failles graves sur le papier, que personne n'exploite et que seul un attaquant déjà entré pourrait atteindre.

Avec la règle ci-dessus, l'ordre devient D, C, E, puis A et B. La passerelle VPN passe en tête malgré son 7.5 : elle est exposée, exploitée activement, et c'est typiquement la porte d'entrée d'un rançongiciel. Le serveur d'intégration suit. Et la ligne E, que le tri par CVSS aurait laissée dormir un an avec son 5.3, remonte en troisième position. Une fuite d'informations exposée, que les attaquants sondent déjà, sert souvent de première marche vers autre chose.

A et B ne disparaissent pas. Elles attendent la semaine suivante, ce qui est très différent de ne jamais être traitées.

Récupérer les données, sans rien acheter

Les deux sources sont publiques et gratuites. Pour interroger EPSS sur une CVE :

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" \
  | jq '.data[0] | {cve, epss, percentile}'

Pour savoir si une CVE est au catalogue KEV, avec sa date limite et le marqueur rançongiciel :

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[]
      | select(.cveID == "CVE-2021-44228")
      | [.cveID, .dateAdded, .dueDate, .knownRansomwareCampaignUse] | @tsv'

Sur Log4Shell, la première commande renvoie une probabilité collée à 1 et la seconde une entrée datée du 10 décembre 2021. Rien de surprenant, mais cela permet de vérifier que la plomberie fonctionne avant de la brancher sur un export de scanner.

Car c'est l'étape suivante : une boucle sur la liste des CVE de votre dernier rapport, une jointure avec votre inventaire pour la colonne « exposé », et le tri se fait tout seul. Une demi-journée de script pour qui est à l'aise, et la plupart des scanners du marché proposent désormais ces colonnes nativement. Si le vôtre ne le fait pas, nous avions listé les critères de choix dans quel scan de vulnérabilités choisir.

Les pièges qu'on rencontre

Croire qu'un EPSS bas veut dire « sans danger ». Le score est une probabilité sur 30 jours, à l'échelle mondiale. Une faille à 0,03 sur un produit de niche que vous êtes trois en France à utiliser peut très bien être celle qu'un attaquant ciblé choisira. EPSS sert à ordonner une file d'attente, pas à fermer des tickets.

Oublier que les scores bougent. Un EPSS peut passer de 0,02 à 0,8 en une semaine quand un exploit est publié. Un tri fait le jour du scan et jamais rafraîchi est faux au bout d'un mois. Le recalcul doit être automatique, sinon il ne sera pas fait.

Dépendre d'une seule source. Depuis février 2024, la NVD accumule un retard important dans l'analyse des CVE, et beaucoup d'entrées récentes n'ont ni score ni liste de produits affectés côté NIST. La CISA compense en partie avec son projet Vulnrichment. En avril 2025, le financement du programme CVE lui-même a failli s'interrompre, à quelques heures près. L'ENISA a ouvert sa propre base européenne, l'EUVD, le mois suivant. La leçon pour un RSSI : ne pas construire sa chaîne de priorisation sur une source unique, et vérifier ce que fait son outil quand la NVD ne répond rien.

Prendre le CVSS de l'éditeur pour celui de la NVD, ou l'inverse. Les deux divergent régulièrement, parfois de plusieurs points. L'éditeur connaît mieux son produit, mais il a aussi intérêt à ne pas afficher un 9.8. Quand ils diffèrent, retenez le plus élevé pour trier, et lisez le vecteur plutôt que la note.

Trier sans jamais mesurer. Une règle de priorisation sans indicateur finit en affiche dans un couloir. Deux chiffres suffisent : le délai médian de correction par rang, et le nombre de lignes de rang 1 et 2 ouvertes hors délai. Si le second n'est pas à zéro, c'est le sujet de la prochaine réunion.

Et la conformité, dans tout ça ?

Bonne nouvelle, les référentiels vont dans le même sens. Le contrôle A.8.8 de l'ISO 27001

Dans les deux cas, ce qu'un auditeur veut voir n'est pas un stock à zéro, qu'il sait impossible. C'est une règle écrite, des preuves qu'elle est suivie, et une explication pour chaque exception. Un tableau à cinq rangs, des délais mesurés et une liste d'exceptions signées valent mieux, en audit, qu'une politique qui promet de corriger toutes les critiques sous 30 jours et que les chiffres contredisent. Nous avons décrit la forme que prennent ces preuves dans le guide du rapport de conformité NIS2.

Ce que nous en faisons chez Flawfence

Disons d'où nous parlons. Flawfence surveille en continu la surface externe de ses clients, ce qui nous place par construction sur les rangs 1, 2 et 4 du tableau : ce qui est exposé. Notre parti pris est que la colonne « exposé » ne doit pas être déclarée par le client mais constatée de l'extérieur, parce que l'actif oublié est précisément celui que personne n'aurait coché. Et nous cherchons à valider qu'une faille est réellement exploitable avant de la remonter, ce qui retire du tri une bonne partie du bruit d'un scanner classique.

Ce que nous ne faisons pas : votre parc interne, vos postes, votre Active Directory. La règle de tri s'y applique tout autant, avec d'autres outils.

FAQ

Faut-il abandonner le CVSS ?

Non. Le CVSS reste la meilleure description disponible de la gravité d'une faille, et son vecteur (accès réseau ou local, privilèges requis, interaction utilisateur) est une mine d'informations. Ce qu'il faut abandonner, c'est son usage comme unique critère de tri. Il garde sa place au rang 4 de notre tableau : à exposition égale et sans signal d'exploitation, le plus grave passe devant.

Quel seuil EPSS choisir ?

Partez de 0,1 et ajustez selon votre capacité de traitement. Les travaux publiés avec EPSS v3 montrent qu'un seuil proche de 0,09 couvre autant de vulnérabilités exploitées qu'un tri « CVSS ≥ 7 », pour environ huit fois moins de corrections. Si votre équipe peut absorber davantage, descendre le seuil augmente la couverture.

Le catalogue KEV est américain. Est-il pertinent pour une entreprise française ?

Oui, avec une réserve. Les attaquants opportunistes ne regardent pas les frontières, et les équipements de bordure, VPN, messageries et hyperviseurs listés au KEV sont les mêmes des deux côtés de l'Atlantique. La réserve porte sur les produits très locaux, moins bien couverts. Complétez avec les alertes et avis du CERT-FR, qui signalent eux aussi les exploitations actives.

Que faire d'une vulnérabilité sans score du tout ?

C'est de plus en plus fréquent depuis le retard pris par la NVD. Regardez le score de l'éditeur ou de l'autorité qui a attribué la CVE, l'enrichissement Vulnrichment de la CISA, et la fiche EUVD. En l'absence de tout, revenez aux deux questions qui ne dépendent d'aucune base : le composant est-il exposé, et existe-t-il un exploit public ?

À quelle fréquence refaire le tri ?

Les scores EPSS changent tous les jours et le KEV s'enrichit plusieurs fois par semaine. Un recalcul hebdomadaire automatisé est un minimum raisonnable. Pour les actifs exposés sur Internet, une vérification quotidienne a du sens : le délai entre la publication d'un correctif et les premières exploitations de masse se compte désormais en jours.

Conclusion

CVSS dit si c'est grave, KEV dit si c'est exploité, EPSS dit si ça va probablement l'être. Aucun ne dit si c'est joignable chez vous, et c'est pourtant cette réponse qui réordonne tout le reste.

Si vous ne devez faire qu'une chose cette semaine, prenez votre dernier rapport de scan, ajoutez-y deux colonnes (KEV, exposé), et regardez ce qui remonte en tête. Il y a de bonnes chances que ce ne soit pas une « critique ».