CVSS, EPSS, KEV : trois nombres pour ne pas corriger les vulnérabilités dans le mauvais ordre

Une équipe qui corrige ses vulnérabilités par score CVSS décroissant travaille beaucoup et réduit peu son risque. Voici pourquoi, et quoi faire à la place.

CVSS : la gravité, pas le risque

Le score CVSS (de 0 à 10) décrit une faille dans l’absolu : vecteur d’attaque (réseau, adjacent, local, physique), complexité, privilèges requis, interaction de l’utilisateur, impact sur la confidentialité, l’intégrité et la disponibilité. Il est publié par le NVD et par l’éditeur, et ne change presque jamais.

Ce qu’il ne dit pas : si quelqu’un exploite réellement cette faille, et si votre installation l’expose. Des milliers de CVE notées 9 ou 10 n’ont jamais été exploitées. Et une CVE notée 7,5 exploitable à distance sans authentification peut être bien plus urgente qu’une 9,8 qui demande un accès local.

Le vecteur d’attaque est la partie la plus utile du score. Une faille « réseau » sur un service exposé à internet n’a rien à voir avec une faille « locale » sur une machine sans utilisateur interactif.

EPSS : la probabilité d’exploitation

L’EPSS (Exploit Prediction Scoring System, publié par le FIRST) donne pour chaque CVE une probabilité, de 0 à 1, qu’elle soit exploitée dans les trente prochains jours. Il est recalculé chaque jour à partir de signaux réels : code d’exploitation public, mentions, activité observée.

La distribution est très inégale : la grande majorité des CVE ont un EPSS inférieur à 1 %, et quelques centaines concentrent l’essentiel des exploitations. Trier par EPSS décroissant est donc un filtre très efficace : il isole les failles qui ont une chance raisonnable d’être utilisées contre vous.

Sa limite : il mesure l’intérêt des attaquants pour une faille, pas votre exposition à elle.

KEV : ce qui est déjà exploité

Le catalogue KEV (Known Exploited Vulnerabilities, tenu par la CISA) liste les CVE pour lesquelles une exploitation réelle a été confirmée, avec une date limite de correction pour les administrations américaines. Il signale aussi celles utilisées par des rançongiciels.

Une CVE au KEV n’est plus une hypothèse. Si elle touche un composant que vous exposez, elle passe en tête, quel que soit son CVSS.

Les trois ensemble, puis le contexte

Une règle simple tient en quatre lignes.

1. Au KEV et joignable depuis internet : à corriger aujourd’hui.
2. EPSS élevé et vecteur réseau : cette semaine.
3. CVSS critique mais EPSS faible et vecteur local : à planifier avec les mises à jour courantes.
4. Le reste : au rythme des cycles de maintenance.

Les lignes 1 et 2 contiennent deux mots que les trois scores ne connaissent pas : « joignable depuis internet ». C’est là que le contexte entre en jeu. La même CVE sur un serveur web public et sur une machine de traitement par lots dans un sous-réseau privé n’a pas la même urgence. Et si la machine publique porte un rôle qui lit une base de données clients, l’urgence monte encore.

C’est le principe des chemins d’attaque : la vulnérabilité est un maillon, et son importance dépend des maillons qui l’entourent. Log4Shell sur un serveur isolé est une mise à jour ; Log4Shell sur un serveur public qui peut assumer un rôle d’accès aux données est une porte ouverte.

En pratique

• Importez EPSS et KEV dans votre inventaire de vulnérabilités, pas seulement CVSS. Les deux sont publics et gratuits.
• Ajoutez l’exposition réseau réelle de chaque machine, pas celle du schéma d’architecture : adresse publique, groupe de sécurité, équilibreur devant.
• Ajoutez ce que la machine peut atteindre : rôle, identité, bases, buckets.
• Traitez d’abord les failles qui cumulent exploitation connue, exposition et accès à quelque chose de précieux.

Dans Ctadel, le scanner de vulnérabilités lit les paquets installés sur une copie des disques, attache à chaque CVE son CVSS, son EPSS et sa présence au KEV, et le moteur de chemins d’attaque ajoute l’exposition et la cible pour produire un score de risque de 1 à 100. Le détail est dans Sévérité et score.