Prioriser les vulnérabilités avec EPSS et KEV : méthode pour PME

Un scan de vulnérabilités mensuel sur un parc PME de taille moyenne remonte facilement 300 à 800 CVE ouvertes, réparties sur les serveurs, les postes, les équipements réseau et les applications tierces. Le RSSI à temps partagé qui reçoit ce rapport n'a ni l'équipe ni les heures pour instruire chaque ligne. La question n'est pas "combien de vulnérabilités avons-nous ?", elle est "lesquelles dois-je traiter cette semaine, avec les deux personnes que j'ai ?". EPSS et KEV répondent précisément à cette question, à condition de les utiliser comme un filtre opérationnel et non comme une case de conformité.

Ce que mesurent EPSS et KEV, et pourquoi ils se complètent

KEV (Known Exploited Vulnerabilities) est le catalogue tenu par la CISA qui recense les CVE dont l'exploitation active a été confirmée sur le terrain, remontée par des incidents réels, des rapports de threat intelligence ou des honeypots. Une entrée dans KEV n'est pas une hypothèse : c'est un fait constaté. Le catalogue est mis à jour au fil de l'eau, généralement accompagné d'une échéance de correction pour les administrations fédérales américaines, échéance qui fait aussi référence pour le secteur privé.

EPSS (Exploit Prediction Scoring System) est un score probabiliste, produit par le FIRST, qui estime la probabilité qu'une CVE soit exploitée dans les 30 prochains jours, sur une échelle de 0 à 1. Le modèle s'appuie sur des dizaines de variables (présence de code d'exploitation public, mentions sur les réseaux sociaux et forums, type de vulnérabilité, exposition du produit) et il est recalculé chaque jour pour l'ensemble des CVE publiées.

La complémentarité tient en une phrase : KEV vous dit ce qui s'est déjà passé, EPSS vous dit ce qui risque de se passer. KEV a une couverture étroite mais une fiabilité totale (si c'est dedans, c'est exploité). EPSS a une couverture large (toutes les CVE ont un score) mais une fiabilité probabiliste (un score élevé n'est pas une certitude). Utiliser l'un sans l'autre laisse un angle mort : se fier uniquement à KEV revient à réagir après coup sur les vulnérabilités les plus médiatisées ; se fier uniquement à EPSS revient à ignorer que certaines CVE à score modéré sont pourtant activement exploitées dans des campagnes ciblées et déjà avérées.

La règle de priorisation en trois niveaux

Pour un SOC sans astreinte 24/7, la règle doit tenir sur une seule diapositive et ne pas demander d'arbitrage au cas par cas :

1. CVE présente dans KEV : patch immédiat. Pas de discussion, pas de fenêtre de maintenance standard. C'est une exploitation confirmée quelque part dans le monde, sur un produit que vous exploitez aussi. Traitement en urgence, y compris hors fenêtre de changement habituelle si l'actif est exposé.
2. Score EPSS au-dessus d'un seuil (typiquement 0,10 à 0,20 selon l'appétence au risque) : fenêtre courte. Traitement sous 7 à 14 jours, dans la prochaine fenêtre de maintenance planifiée, sans attendre le cycle de patch mensuel classique.
3. Le reste : backlog. Ces CVE existent, sont documentées, mais rejoignent le cycle de correction standard (patch mensuel, mise à jour de version). Elles ne justifient ni astreinte ni escalade.

Le seuil EPSS n'est pas universel : une PME exposée sur internet avec des actifs critiques accessibles publiquement devrait retenir un seuil plus bas (0,05 à 0,10) qu'une PME dont le périmètre est essentiellement interne et segmenté.

Exemple chiffré : de 412 CVE à 6 actions

Prenons un cas représentatif observé sur un parc de 60 serveurs et 120 postes de travail après un scan mensuel :

412 CVE ouvertes (scan brut, tous produits confondus)
  -> 88 CVE concernent un produit ou une version déjà déployée et exposée
  -> 24 CVE ont un score EPSS >= 0,10 OU figurent dans KEV
     - dont 3 présentes dans KEV (exploitation confirmée)
     - dont 21 avec EPSS >= 0,10 mais hors KEV
  -> après contextualisation par exposition d'actif (internet-facing,
     segment critique, données sensibles) : 6 CVE retenues en action
     immédiate ou fenêtre courte

Sur 412 CVE brutes, 6 déclenchent une action concrète cette semaine. Les 3 CVE KEV partent en correctif dans les 48 heures. Les 3 autres, EPSS élevé sur des actifs exposés, sont planifiées sous 10 jours. Le reste (406 CVE) rejoint le cycle de patch mensuel sans mobiliser l'équipe en urgence. C'est la différence entre un rapport de 40 pages que personne ne lit et une liste de 6 lignes qu'on traite dans la semaine.

Automatiser : enrichir le feed de vulnérabilités

La méthode ne tient dans la durée que si l'enrichissement est automatique. L'API EPSS et le flux KEV sont publics et interrogeables sans authentification, ce qui permet de construire un pipeline simple d'enrichissement quotidien :

# Récupération du score EPSS pour une CVE donnée
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-31337" | jq '.data[0].epss'
 
# Vérification de la présence dans le catalogue KEV (CISA)
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | jq --arg cve "CVE-2026-31337" '.vulnerabilities[] | select(.cveID == $cve)'

Sur cette base, une règle de scoring quotidienne peut s'exprimer simplement :

scoring_rules:
  - condition: "cve.in_kev == true"
    priority: immediate
    sla_hours: 48
  - condition: "cve.epss_score >= 0.10"
    priority: short_window
    sla_days: 10
  - condition: "default"
    priority: backlog
    sla_days: 30

Le point critique : EPSS varie dans le temps, parfois fortement d'un jour à l'autre après la publication d'un code d'exploitation public. Une CVE scorée à 0,03 la semaine dernière peut passer à 0,40 du jour au lendemain. Un enrichissement figé au moment du scan initial devient rapidement obsolète. Le re-scoring doit être quotidien, sur l'ensemble du stock de CVE ouvertes, pas seulement sur les nouvelles.

Les pièges à éviter

Trois écueils reviennent systématiquement dans les déploiements de cette méthode :

• EPSS n'est pas figé. Un score consulté une seule fois au moment du scan mensuel donne une photo qui se périme en quelques jours. Sans re-scoring quotidien, on manque les CVE qui basculent en zone critique après une publication d'exploit.
• KEV n'est pas exhaustif. Le catalogue recense l'exploitation confirmée et rapportée, pas toute l'exploitation réelle. De nombreuses campagnes ciblées ne remontent jamais dans KEV, ou avec un délai. L'absence d'une CVE dans KEV ne signifie pas qu'elle est sans risque, elle signifie seulement qu'aucune exploitation n'a été formellement rapportée à ce jour.
• Le score seul ne suffit pas, il faut contextualiser par exposition et par actif. Une CVE avec EPSS à 0,25 sur un serveur interne isolé, sans accès réseau externe, ne mérite pas le même traitement que la même CVE sur un serveur exposé à internet avec des données clients. La priorisation EPSS/KEV donne le tri générique, l'inventaire d'actifs et leur exposition donnent le tri final.

Un feed déjà priorisé plutôt qu'un flux brut à trier

Construire ce pipeline (récupération EPSS, suivi KEV, seuils, re-scoring quotidien, croisement avec l'inventaire d'actifs) représente un investissement d'ingénierie que peu de PME peuvent maintenir en interne dans la durée. La logique reste simple à énoncer, mais la tenir à jour, jour après jour, sur des centaines de CVE, est un travail de fond.

C'est exactement ce que livre le flux de vulnérabilités ThreatClaw : les CVE remontées sont déjà enrichies EPSS et KEV, déjà triées selon la règle des trois niveaux, et re-scorées quotidiennement. Le RSSI reçoit une liste courte d'actions réelles, pas un export brut de scanner à dépouiller seul.