EPSS vs CVSS vs KEV : comment prioriser les CVE quand tout semble critique

Les outils de scan étiquettent des milliers de constats en « élevé » ou « critique », les dirigeants réclament un score de risque unique et les ingénieurs veulent un ordre de correctifs qui respecte la disponibilité. Pendant ce temps, les bases de CVE grossissent chaque jour. La réponse du secteur a été une notation en couches : CVSS pour la sévérité, EPSS pour la probabilité d'exploitation et KEV pour l'exploitation confirmée dans la nature. Cet article compare ces référentiels sans mythifier aucun chiffre en particulier, puis propose un processus de décision que les responsables de la gestion des vulnérabilités et les responsables SOC peuvent adopter, aligné sur la threat intelligence relative aux acteurs malveillants et à l'activité d'exploitation.

CVSS : une base de sévérité, pas une boule de cristal

Le Common Vulnerability Scoring System exprime la gravité potentielle d'une faille si elle est exploitée avec succès, à partir de métriques comme le vecteur d'attaque, la complexité, les privilèges requis, l'interaction utilisateur et les impacts sur la confidentialité, l'intégrité et la disponibilité. Les versions CVSS v3 et v4 affinent la façon dont les métriques environnementales et supplémentaires peuvent adapter les scores, même si tous les éditeurs n'affichent pas clairement la chaîne de vecteur complète dans leurs tableaux de bord.

Points forts :

• Interopérabilité : presque tous les scanners exportent du CVSS, ce qui permet un tri grossier entre outils de différents éditeurs.
• Transparence : les chaînes de vecteur expliquent pourquoi un score est élevé, ce qui facilite la relecture par les pairs.

Limites :

• Sévérité ≠ exploitabilité réelle. Une faille théoriquement dévastatrice peut ne jamais donner lieu à une exploitation fiable, tandis qu'un problème de sévérité moyenne devient catastrophique sur votre déploiement précis.
• Cécité environnementale par défaut. Les scores de base ne connaissent pas votre architecture.

Côté SEO, les pages qui définissent clairement les composantes du CVSS se positionnent bien, car les débutants recherchent en permanence « qu'est-ce que le CVSS » et « CVSS vs sévérité ». Ajoutez des exemples avec des fragments de vecteur pour améliorer la qualité des extraits affichés.

EPSS : la probabilité, pas la douleur

L'Exploit Prediction Scoring System produit une probabilité comprise entre 0 et 1 (souvent affichée en pourcentage) qu'une CVE soit exploitée dans les 30 prochains jours (définition susceptible d'évoluer avec les mises à jour du modèle — citez toujours la version officielle de la spécification dans votre politique interne). L'EPSS complète le CVSS en répondant aux questions de prévalence et d'intérêt des attaquants, à partir de télémétrie observée.

Points forts :

• Priorisation à l'échelle : lorsque des dizaines de milliers d'éléments s'accumulent en backlog, l'EPSS permet de classer au-delà de la sévérité statique.
• Signal dynamique : les scores évoluent à mesure que la connaissance des tendances d'exploitation progresse.

Limites :

• Opacité du modèle pour certains utilisateurs : les praticiens doivent comprendre les intervalles de confiance et les limites des données, et ne pas considérer l'EPSS comme une vérité déterministe.
• Actifs rares : des CVE peu répandues peuvent rester critiques pour vous si vous êtes précisément la cible de niche.

Combinez l'EPSS avec la criticité des actifs : un EPSS modéré sur une infrastructure d'authentification exposée sur Internet peut passer devant un EPSS plus élevé sur un cluster de laboratoire isolé.

KEV : la vérité terrain sur l'exploitation

Le catalogue CISA Known Exploited Vulnerabilities recense les CVE dont l'exploitation est confirmée, souvent avec des échéances imposées aux agences fédérales civiles américaines par des directives opérationnelles contraignantes — et le secteur privé s'aligne de plus en plus volontairement sur ces délais.

Points forts :

• Clarté pour la direction : « c'est dans le KEV » est un déclencheur clair pour ouvrir une fenêtre de changement d'urgence.
• Alignement sur le comportement adverse : si des acteurs malveillants exploitent activement une faille, les débats théoriques sur les subtilités du CVSS comptent moins.

Limites :

• Non exhaustif : l'absence du KEV ne prouve pas l'innocuité, en particulier juste après une divulgation.
• Effet de latence : certains exploits circulent dans des canaux fermés avant toute confirmation large.

Traitez le KEV comme un palier impératif de votre politique, tout en maintenant des processus de réaction rapide pour les zero-day ou les chaînes d'exploitation privées qui ne sont pas encore cataloguées.

Combiner les trois : une matrice opérationnelle

Envisagez un modèle à deux axes :

1. Sévérité technique (CVSS) — l'ampleur des dégâts en cas d'exploitation.
2. Urgence réelle (EPSS + KEV + threat intel) — la probabilité de subir une exploitation à court terme.

Exemple de paliers de politique :

• P0 — Urgence : CVE inscrite au KEV affectant des systèmes exposés, ou threat intelligence confirmant des campagnes actives contre votre secteur utilisant cette CVE, quel que soit l'EPSS si des observations internes existent.
• P1 — Accéléré : CVSS élevé et EPSS élevé, même sans inscription au KEV, sur des actifs sensibles.
• P2 — Planifié : scores moyens avec mesures compensatoires et correctifs disponibles dans les cycles mensuels.
• P3 — Backlog : risque immédiat faible ; suivi des mises à jour éditeur.

Documentez les exceptions par des acceptations de risque formelles ; les auditeurs préfèrent des dérogations explicites à une négligence silencieuse.

La threat intelligence enrichit la notation

Les flux peuvent signaler des modules d'exploitation dans Metasploit, des observations sur des honeypots ou des adresses IP scannant des services vulnérables. Lorsque ces signaux convergent vers une CVE, remontez la priorité même si l'EPSS est en retard. À l'inverse, si la threat intelligence montre que l'exploitation se limite à des piles technologiques sans rapport avec la vôtre, vous pouvez abaisser l'urgence après validation.

Les plateformes exposant la réputation des IP et des domaines aident à corréler les vagues de scan avec les calendriers de déploiement des correctifs — utile pour décider de règles de pare-feu temporaires pendant la propagation des mises à jour.

Enjeux organisationnels : gestion du changement et interruptions de service

Même une priorisation correcte échoue sans fenêtres de maintenance ni tests. Les cultures DevOps devraient intégrer les mises à jour de dépendances dans la CI/CD avec des tests automatisés ; les environnements legacy peuvent exiger des déploiements par phases. Expliquez que le CVSS n'impose pas à lui seul un délai de correctif : votre SLA découle de la politique bâtie par-dessus.

Spécificités éditeurs et cloud

Les produits SaaS peuvent être corrigés de manière transparente ; votre responsabilité se déplace alors vers les revues de configuration et l'hygiène des clés d'API. Les utilisateurs d'IaaS doivent suivre les CVE des images d'OS invité, des pools de nœuds Kubernetes et des couches d'hyperviseur — chacune avec des propriétaires différents. Centralisez la responsabilité dans un comité vulnérabilités réunissant des représentants applicatifs, plateforme et métiers.

Les métriques qui comptent

• MTTR des CVE inscrites au KEV comparé aux autres.
• Pourcentage d'actifs critiques conformes au SLA.
• Récurrence après des tentatives de correctif échouées — signe de pipelines défaillants ou de lacunes d'inventaire.

Évitez d'inciter les équipes uniquement sur la baisse du « nombre de CVE ouvertes » sans contexte ; cela encourage à masquer des constats ou à truquer les scanners.

Communication avec les développeurs

Les développeurs supportent mal les tickets « critiques » sans contexte. Fournissez les descriptions de CVE, les vecteurs CVSS, les instantanés EPSS et des instructions de reproduction. Renvoyez vers les avis officiels et les versions corrigées recommandées. Lorsque les empreintes de fichiers des bibliothèques vulnérables importent (par exemple pour des problèmes de chaîne d'approvisionnement), incluez les identifiants SHA-256 pour lever toute ambiguïté.

Considérations juridiques et de divulgation

Publier vos référentiels de priorisation internes à l'extérieur (par exemple sur un blog d'entreprise) peut servir le SEO et la confiance des clients, mais évitez de révéler des expositions critiques non corrigées. Des méthodologies génériques — comme dans cet article — sont plus sûres que des calendriers propres à votre infrastructure.

Erreurs courantes

• Considérer qu'un CVSS 10 est automatiquement plus urgent qu'un CVSS 8 inscrit au KEV — le contexte l'emporte sur un chiffre isolé.
• Ignorer les mesures compensatoires comme des règles WAF qui font gagner du temps : documentez-les explicitement.
• Ne pas réexaminer les priorités après des correctifs éditeurs majeurs ou la publication de nouveaux exploits.

Exercice sur table : quand les scores se contredisent

Simulez un scénario où le CVSS est modéré, l'EPSS grimpe du jour au lendemain et l'inscription au KEV est en attente. Entraînez les parties prenantes à décider dans l'incertitude : isolation réseau temporaire, journalisation renforcée, tests de correctif accélérés. Ces exercices réduisent la panique lors des événements réels.

Conclusion

Le CVSS, l'EPSS et le KEV répondent à des questions différentes ; les programmes matures les combinent avec la connaissance des actifs et la threat intelligence. Cessez de débattre pour savoir quel score est « le bon » et commencez à les intégrer dans des politiques transparentes que développeurs et exploitants peuvent appliquer. Les organisations gagnantes mesurent des résultats — réduction de la surface exploitable et remédiation plus rapide — et non des positions de vanité au classement du nombre de vulnérabilités.

Côté SEO, un positionnement durable vient de la mise à jour de ces recommandations lorsque les spécifications de notation évoluent, et de liens vers des références faisant autorité. Les lecteurs qui recherchent « EPSS vs CVSS » veulent des tableaux comparatifs et des conseils de mise en œuvre : donnez-leur les deux.

État d'esprit d'annexe : amélioration continue

Réévaluez vos pondérations chaque année : à mesure que les attaquants automatisent l'exploitation, les distributions EPSS se déplacent. À mesure que votre parc devient cloud-native, les sources de CVE dans les orchestrateurs et les service meshes gagnent en importance. Restez attentif aux rapports sur les acteurs malveillants — les affiliés ransomware se concentrent souvent sur une poignée de CVE fiables jusqu'à ce que les défenses rattrapent leur retard. Votre modèle de priorisation est un document vivant, pas un tableur figé.

Faire le lien avec les registres de risques élargis

Alignez vos paliers de CVE sur le langage de la gestion des risques d'entreprise : rattachez les problèmes P0 aux catégories de risque opérationnel suivies par le conseil d'administration lorsque c'est pertinent. Cet alignement sécurise les budgets d'outillage et de recrutement — bien plus efficacement que des plaintes purement techniques.

CVSS v4 et métriques supplémentaires : anticiper la mise à niveau de votre chaîne d'outils

À mesure que les écosystèmes adoptent le CVSS v4, les interfaces éditeurs exposeront des groupes de métriques supplémentaires destinés à une communication plus fine de la sévérité. Les équipes d'architecture sécurité doivent planifier la mise à niveau des parseurs pour que les systèmes de ticketing continuent d'ingérer les chaînes de vecteur sans perdre le contexte supplémentaire. Testez la non-régression des intégrations chaque fois que les scanners changent de version de CVSS : des scores mal interprétés faussent silencieusement les tableaux de bord.

Les supports de formation doivent expliquer les concepts de la v4 en langage simple pour les responsables d'ingénierie qui arbitrent le travail de sprint face aux backlogs de CVE ; des articles internes consultables réduisent les explications répétitives.

SSVC et priorisation spécifique aux parties prenantes

La Stakeholder-Specific Vulnerability Categorization (SSVC) de la CISA propose des arbres de décision intégrant l'impact sur la mission, la sûreté et l'exposition — précieux lorsque le CVSS seul semble déconnecté des conséquences sociétales ou opérationnelles. Vous pouvez faire correspondre les résultats SSVC aux mêmes paliers P0–P3 utilisés pour les flux pilotés par le KEV et l'EPSS, créant ainsi un vocabulaire unifié entre les équipes infrastructure, OT et sécurité produit.

Documentez les cas où la SSVC prime sur le CVSS brut : dispositifs médicaux, lignes de production et systèmes de sécurité publique justifient souvent une logique sur mesure.

Réduire le bruit des scanners sans masquer le risque

Les constats en double entre outils gonflent les compteurs. Dédupliquez par identifiant CVE normalisé plus instance de composant affecté. Excluez les environnements de développement des SLA de production tout en continuant à suivre les problèmes : la transparence vaut mieux que des backlogs fantômes qui explosent au moment des audits.

L'automatisation du tri peut étiqueter les constats à la fois avec l'EPSS et des tags d'unité métier, afin que les responsables produit reçoivent des files filtrées plutôt que des exports bruts de scanner.

La qualité de la CMDB comme multiplicateur de force

Même une logique CVSS/EPSS/KEV parfaite échoue si la base de gestion des configurations liste des serveurs fantômes. Investissez dans la précision de la découverte ; reliez les champs de responsabilité aux rotations d'astreinte. Quand un correctif KEV d'urgence tombe, la première question est « où sommes-nous vulnérables ? » — l'inventaire répond plus vite que des tableurs improvisés.

Coordination avec le threat hunting

Les hunters recherchent de manière proactive des artefacts d'exploitation liés aux CVE à fort EPSS touchant votre pile, avant même que les scanners ne prouvent l'absence de correctifs. Croisez les hypothèses de hunt avec les pics de réputation d'IP relevés dans les journaux de périmètre. C'est là que les plateformes de threat intelligence et les données de vulnérabilités se rejoignent, au-delà du ticketing.

Publier de la transparence pour les clients et partenaires

Les fournisseurs SaaS publient de plus en plus des déclarations de trust center résumant leur traitement des CVE émergentes : délai moyen de remédiation, seuils de notification client, et déclenchement ou non de fenêtres de maintenance automatiques pour les problèmes KEV. Si vous exploitez une plateforme, alignez le discours marketing sur la réalité de l'ingénierie ; les prospects venus du SEO comparent ces déclarations côte à côte au moment de choisir un fournisseur.

Revisitez ce récit après les incidents majeurs du secteur ; la fraîcheur signale votre compétence aux lecteurs comme aux moteurs de recherche. De petites mises à jour valent mieux que des « guides ultimes » périmés qui ne reflètent jamais les nouvelles versions de notation.