Le Brief/Guide

KEV : un indicateur qui vaut plus qu'un CVSS 10

Le Known Exploited Vulnerabilities (KEV) compte près de 1 680 entrées. Chaque ajout signifie une chose : cette faille est exploitée dans la nature.

Mickaël Walter
Known exploited vulnerabilities web page

1 680 entrées, une seule certitude

Le Known Exploited Vulnerabilities (KEV) de la CISA compte aujourd’hui près de 1 680 entrées. Chaque ajout signifie une chose, et une seule : cette faille est activement exploitée dans la nature. Ce n'est pas un score ni une criticité. Juste la preuve concrète qu’un attaquant, quelque part, a déjà utilisé cette vulnérabilité pour compromettre un système. Si votre priorisation repose exclusivement sur des scores théoriques, il est temps de revoir votre approche.

KEV : Définition et fondements

Qu’est-ce que le KEV ?

Le Known Exploited Vulnerabilities (KEV) est un catalogue maintenu par l'agence gouvernementale de la cybersécurité aux Etats-Unis : le Cybersecurity and Infrastructure Security Agency (CISA). Son objectif est simple : lister les vulnérabilités pour lesquelles une exploitation active a été confirmée.

Contrairement aux bases de données traditionnelles (comme le NVD), le KEV ne se base ni sur la gravité technique (CVSS), ni sur la probabilité d’exploitation (EPSS). Il repose sur un critère binaire : l’exploitation est avérée.

Par qui et pour qui ?

Le CISA remplit le rôle d'agence de référence en matière de sécurité informatique aux Etats-Unis. Ses directives sont en particulier contraignantes pour les administrations américaines (via les Binding Operational Directive - BOD).

Mais ces directives ont également été massivement adoptées par le secteur privé car la position unique du CISA lui donne une vision globale des attaques qui ciblent les Etats-Unis.

Comment et à quelle fréquence consulter le KEV ?

Le KEV est accessible publiquement dans différents formats :

Ce flux contient des informations de premier ordre pour qualifier l'exploitation d'une vulnérabilité. La présence même de la vulnérabilité au catalogue indique qu'elle a été ou est exploitée ou par exemple si elle est exploitée par des groupes de rançongiciels.

Il est mis à jour tous les jours en fonction des incidents observés par le CISA. Les administrations américaines ont en outre une obligation de conduire des activités de remédiation avant des dates butoirs définies par l'agence. Ces dates donnent par ailleurs un bon indicateur du niveau d'urgence associé à la vulnérabilité.

En particulier le BOD26-04 (voir notre article à ce sujet), permet de connaître rapidement la posture attendue par l'agence envers les administrations américaines et donc la réponse qu'il conviendrait d'avoir même en temps qu'entreprise privée.

KEV vs CVSS vs EPSS : Trois métriques, une seule vérité

Beaucoup d'équipes sécurité, infrastructure ou SecOps utilisent encore le score CVSS (Common Vulnerability Scoring System) de base pour prioriser leurs vulnérabilités. C'est une erreur qui a lourdes conséquences sur l'efficacité des processus de gestion des vulnérabilités.

Le CVSS a une utilité : évaluer la criticité intrinsèque d'une vulnérabilité. Il n'a cependant jamais eu vocation à prioriser les vulnérabilités. C'est donc un indicateur parmi d'autres qui permet d'évaluer la réponse qu'une équipe de centre de gestion de vulnérabilités va avoir.

Bien que plus ancré dans la réalité du terrain, l'EPSS (Exploit Probability Scoring System), est également une évaluation et est à ce titre imprécise. C'est toutefois un bon indicateur pour anticiper une exploitation future d'une vulnérabilité.

De ces trois indicateurs, seul le KEV reflète une réalité terrain. Il est d'ailleurs sans faux-positif ou presque. Il a tout de même le défaut d'être réactif contrairement aux deux autres métriques qui permettent une posture proactive.

Pourquoi le KEV est plus important que le CVSS pour la priorisation ?

Le CVSS tel qu'il est présenté dans la plupart des sources ne tient pas compte de la réalité ou de la probabilité d'une exploitation. Il tient principalement compte des propriétés intrinsèques à la vulnérabilité : ce qu'elle permet à un acteur malveillant de faire, sous quelles conditions et avec quel impact.

Ainsi une vulnérabilité peut avoir un impact très grand... mais ne pas être exploitée du tout.

Comme le KEV exprime la réalité de l'exploitation, il existe une décorrélation entre le CVSS et le catalogue. Un CVSS élevé ne garantit pas l'ajout au KEV. Et la réciproque est vraie aussi : l'ajout au KEV n'est pas un indicateur de CVSS élevé.

En évaluant les combinaisons entre CVSS et KEV on en déduit que :

  • Une vulnérabilité peut avoir un score maximal sans être ciblée et donc ne pas apparaître au KEV ;
  • Une vulnérabilité avec un score moyen mais exploitée massivement apparaîtra au KEV. Les acteurs de menace peuvent obtenir un gain significatif même avec des vulnérabilités de faible criticité (pour mener l'attaque plus loin ou parce que le contexte d'exploitation la rend plus intéressante) ;
  • Le KEV est une preuve terrain : Si une CVE est dans le KEV, c’est qu’un attaquant a déjà réussi à l’exploiter. Peu importe le score.

Le KEV n'est pas un outil magique

Le KEV, comme le système CVE, est un outil américain, et a été largement adopté au niveau mondial comme standard de facto. C'est donc un outil sûr et éprouvé.

Il faut toutefois prendre en compte ses limites avant de considérer son intégration dans les processus de gestion des vulnérabilités.

Le KEV ne couvre pas tout

Le CISA se concentre sur les vulnérabilités exploitées contre des infrastructures américaines. Certaines attaques ciblées (par exemple contre des entreprises françaises) peuvent ne pas y figurer. Cela est d'autant plus vrai pour les pays en-dehors de la sphère occidentale.

Il faut aussi prendre en compte le fait que malgré sa position dominante, le CISA n'est pas une agence omnisciente ou totalement transparente. Elle est de plus alignée avec les intérêts américains, ce qui biaise inévitablement la ligne éditoriale du catalogue.

Il ne faut donc jamais considérer l'absence d'une vulnérabilité au KEV comme équivalente à une absence d'exploitation. Le faire créera de nombreux faux-négatifs qui auront un impact tout aussi important.

C'est là que d'autres métriques permettent de prendre une décision. Il est aussi important de varier les sources :

  • Les sources officielles : des sources existent hors de la sphère américaine, notamment au niveau des agences nationales. En France l'Agence Nationale de la Sécurité des Systèmes d'Information publie les alertes du CERT-FR. En Allemagne, le Bundesamt für Sicherheit in der Informationstechnik a aussi son propre dispositif. Il en existe même un à l'échelle de l'Union Européenne ;
  • Les sources d'actualité : de nombreuses revues spécialisées en ligne apportent du contexte sur des événements particuliers ;
  • Les signaux faibles : plus difficiles à capter en raison de leur diversité et de l'évaluation de la confiance qu'on peut y accorder, ils permettent une meilleure réactivité en évaluant les vulnérabilités à la source. Ces signaux peuvent provenir de forums d'acteurs malveillants ou encore des discussions d'équipes de développement.

Un biais géographique dans les délais annoncés

Même si sur Internet les attaques sont généralement ciblées par blocs en opposition (occidental, asiatique, etc.), chaque pays a ses propres spécificités. Ainsi les délais annoncés par le CISA le sont en fonction des contraintes et des biais américains.

Une vulnérabilité peut être ajoutée au KEV bien avant que l'Europe ne soit touchée ou inversement elle peut apparaitre d'abord en Europe et ne toucher les Etats-Unis que plus tard.

La réactivité nécessaire n'est donc pas la même en fonction de la situation. Il convient de se tenir au courant des alertes locales voire même parfois sectorielles.

Vieilles CVE ajoutées tardivement

Le KEV est un catalogue constamment mis à jour et pas nécessairement à la suite de la publication d'une vulnérabilité. Il existe des ajouts réalisés bien après la sortie de la vulnérabilité, généralement après une actualité particulière la concernant.

Par exemple, la CVE-2019-1068 (touchant Microsoft SQL Server) a été ajoutée au KEV le 26 août 2026, soit 7 ans après sa publication. La raison est simple : des groupes de ransomware l’ont réutilisée massivement en 2026.

La conséquence peut être importante si vous avez décidé à l'époque d'accepter le risque et clore la correction de la vulnérabilité sans possibilité de retour en arrière.

Dans votre processus de gestion des vulnérabilités, il convient de ne jamais supprimer une vulnérabilité de l'inventaire. Préférez l'archivage qui vous permet de revenir en arrière en cas de nouvel événement.

Open Source et composants partagés : Un angle mort

Le KEV se concentre sur les produits commerciaux (Microsoft, Adobe, Cisco…). Les vulnérabilités dans les bibliothèques open source (Log4j, OpenSSL, Spring…) y apparaissent moins fréquemment, alors qu’elles sont également des sources de vulnérabilités activement exploitées.

Ce que NIS2 attend

La directive NIS2 (applicable depuis octobre 2024 dans l'ensemble de l'Union Européenne) impose aux opérateurs de services essentiels (OSE) et grands fournisseurs de services numériques de :

  • Surveiller activement les vulnérabilités ;
  • Appliquer les correctifs dans des délais raisonnables ;
  • Signaler les incidents significatifs.

Cela signifie que suivre les ajouts au KEV est une forme de veille active sur les vulnérabilités. Mais elle ne doit pas être aveugle : surveiller les recommandations de son autorité nationale de sécurité des systèmes d'information est également essentiel.

Les délais préconisés par le KEV ne sont en principe pas opposables à ce qui est considéré comme un délai raisonnable. Cela étant, NIS2 demande généralement une réaction dans les 72h pour les vulénrabilités critiques, ce qui est compatible avec les BOD imposées aux administrations par le CISA pour la même catégorie.

Passez à l’action

Le KEV n’est pas une liste de plus. C’est le signal le plus fiable pour savoir qu’une vulnérabilité est active dans la nature. Mais son vrai pouvoir réside dans son croisement avec votre parc.

Le KEV et d'autres sources sont nativement intégrées à notre solution VulnPilot avec des conséquences directes sur la priorité remontée par notre solution de renseignement sur les vulnérabilités.

Vous recevez alors automatiquement et dans le délai approprié les actions à réaliser dans les délais les plus courts, en tenant compte de la situation réelle du terrain.


Partager

Restez informé

Recevez nos derniers articles et analyses directement dans votre boîte mail.