Prioriser les vulnérabilités : CVSS, EPSS et KEV expliqués simplement

Le premier scan des dépendances d'une application donne souvent un choc : 80, 150, parfois 300 vulnérabilités. Une petite équipe ne peut pas tout corriger cette semaine, et elle n'en a pas besoin. La vraie question est : lesquelles d'abord ? Trois indicateurs publics suffisent à y répondre sérieusement.

Pensez à un service d'urgences. Le CVSS dit à quel point une blessure peut être grave. L'EPSS dit la probabilité qu'elle s'aggrave dans les prochains jours. Le KEV dit que le patient saigne déjà. On soigne d'abord celui qui saigne, même si un autre a une blessure théoriquement plus grave.

CVSS : la gravité potentielle

Le CVSS (Common Vulnerability Scoring System) note chaque vulnérabilité de 0 à 10 selon ses caractéristiques techniques : exploitable à distance ou non, avec ou sans authentification, avec ou sans action de l'utilisateur, et l'impact sur la confidentialité, l'intégrité et la disponibilité.

Sa limite : le CVSS mesure ce qui pourrait arriver dans le pire cas, pas ce qui arrive réellement. Une bonne partie des vulnérabilités publiées sont classées élevées ou critiques. Trier uniquement par CVSS, c'est se retrouver avec 60 urgences, donc aucune.

EPSS : la probabilité d'exploitation

L'EPSS (Exploit Prediction Scoring System) est publié chaque jour par le FIRST, l'association mondiale des équipes de réponse à incident. Il estime la probabilité qu'une vulnérabilité soit exploitée dans les 30 prochains jours, à partir des tentatives d'attaque observées et des caractéristiques de la faille.

Les ordres de grandeur sont parlants : la très grande majorité des CVE ont un EPSS inférieur à quelques pour cent, et une petite fraction concentre l'essentiel de l'activité des attaquants. Une CVE de CVSS 9,8 avec un EPSS de 0,2 % est rarement attaquée. Une CVE de CVSS 7,5 avec un EPSS de 70 % l'est massivement.

KEV : l'exploitation confirmée

Le catalogue KEV (Known Exploited Vulnerabilities), tenu par l'agence américaine CISA, liste les vulnérabilités dont l'exploitation réelle est confirmée. Les administrations fédérales américaines ont l'obligation de les corriger dans un délai fixé. Pour tout le monde, c'est le signal le plus fiable : ce n'est plus une hypothèse, des attaquants s'en servent.

Le catalogue compte quelques milliers d'entrées sur plus de 250 000 CVE publiées : c'est un filtre extrêmement sélectif.

La méthode en quatre niveaux

Voici une règle simple, applicable dès demain par une équipe de deux à dix développeurs :

1. Urgent, dans la semaine : toute vulnérabilité présente dans le catalogue KEV, et tout paquet malveillant (dans ce cas, le jour même).
2. Prioritaire, dans le mois : CVSS élevé ou critique et EPSS significatif (par exemple au-dessus de 10 %), ou composant exposé directement sur Internet.
3. Planifié, dans le trimestre : le reste des vulnérabilités élevées et critiques, traitées lors des montées de version régulières.
4. Suivi : les sévérités moyennes et faibles, corrigées au fil de l'eau, ou documentées comme risque accepté si le composant n'est pas atteignable.

Ces délais ressemblent à ceux qu'utilisent de nombreuses politiques de sécurité. Lysbor propose par défaut 7 jours pour une critique, 30 pour une élevée, 90 pour une moyenne et 180 pour une faible, modifiables par organisation. L'important n'est pas le chiffre exact mais qu'il soit écrit, appliqué et mesuré, car c'est ce qu'un auditeur NIS2 ou ISO 27001 vous demandera.

Corriger par mise à jour, pas par CVE

Deuxième levier, souvent plus puissant que le tri : raisonner en mises à jour plutôt qu'en vulnérabilités. Une seule montée de version d'un framework peut fermer quinze CVE d'un coup. Classer les mises à jour disponibles par la part de risque qu'elles retirent transforme une liste de 150 lignes en un plan de cinq commandes.

C'est le principe du plan de correction de Lysbor : chaque mise à jour est classée par le risque qu'elle retire, avec la commande à lancer et la version cible.

Documenter ce que vous ne corrigez pas

Certaines vulnérabilités ne vous concernent pas réellement : fonction vulnérable jamais appelée, composant utilisé seulement en développement, protection en place en amont. Les ignorer en silence est une mauvaise idée. Les documenter (qui a décidé, pourquoi, jusqu'à quand) est une bonne pratique, et c'est exactement l'objet d'un document VEX.

Une décision documentée doit aussi pouvoir se rouvrir : si le contexte change ou si un correctif sort enfin, elle doit revenir dans la liste.

Questions fréquentes

Faut-il corriger toutes les vulnérabilités critiques ?

Il faut toutes les traiter, c'est-à-dire corriger, atténuer ou documenter un risque accepté. Mais l'ordre compte : une vulnérabilité KEV de sévérité élevée passe avant une critique jamais exploitée.

Où trouver les scores EPSS et le catalogue KEV ?

Le FIRST publie les scores EPSS chaque jour sur first.org, et la CISA publie le catalogue KEV sur cisa.gov, tous deux gratuitement, y compris en format lisible par machine. Les outils de suivi comme Lysbor les synchronisent automatiquement.

Un EPSS faible veut-il dire qu'on peut ignorer la vulnérabilité ?

Non. Il veut dire qu'elle n'est pas la plus urgente aujourd'hui. L'EPSS évolue chaque jour : une vulnérabilité peut devenir exploitée du jour au lendemain lorsqu'un code d'exploitation est publié. C'est pourquoi le suivi doit être continu.

Comment présenter cette priorisation à un auditeur ?

Avec une politique écrite (les délais par niveau), des indicateurs mesurés (délai moyen de correction, respect des délais) et la trace des décisions. Le rapport de posture de Lysbor réunit ces trois éléments.