EPSS et CVE : utiliser la probabilité d’exploitation sans perdre le contexte métier

Le principal problème du patch management moderne n’est pas l’absence de données. C’est l’excès de données non hiérarchisées. Les scanners produisent des milliers de CVE, les dashboards se remplissent de rouge, et les équipes doivent choisir quoi corriger sans casser la production. EPSS apporte une réponse utile : une estimation de la probabilité d’exploitation.

Mais EPSS n’est pas une baguette magique. Il doit être lu avec CVSS, KEV, CPE, exposition réseau, criticité métier et signaux de threat intelligence. Bien utilisé, il réduit le bruit. Mal utilisé, il devient un nouveau score opaque.

Ce qu’EPSS mesure

EPSS estime la probabilité qu’une CVE soit exploitée dans un horizon proche. Le score évolue selon les données disponibles, l’observation de l’écosystème et les signaux publics. Il complète CVSS, qui mesure plutôt la sévérité technique potentielle.

Un CVSS élevé indique que l’impact peut être grave. Un EPSS élevé indique que la vulnérabilité a plus de chances d’être exploitée. Une CVE à la fois high/critical, EPSS élevé, KEV et exposée dans votre périmètre doit passer devant une longue liste de vulnérabilités théoriques.

Pourquoi EPSS améliore la priorisation

EPSS aide les équipes à répondre à une question opérationnelle : “parmi les CVE ouvertes, lesquelles risquent de devenir un incident avant notre prochaine fenêtre de maintenance ?” C’est particulièrement utile pour :

• les backlogs volumineux ;
• les parcs hétérogènes ;
• les environnements où les fenêtres de patch sont limitées ;
• les arbitrages entre applications critiques ;
• les alertes supply chain.

Dans isMalicious, EPSS alimente les filtres et métriques CVE. Il complète les vues globales de CVE Search et les findings de CVE Watch.

Les limites d’un seuil unique

Un seuil comme EPSS ≥ 70 % peut être utile pour un filtre rapide. Mais un programme mature évite de l’utiliser seul. Une CVE EPSS 0,65 sur une appliance exposée au public peut être plus urgente qu’une CVE EPSS 0,8 sur un composant absent du runtime. Le score doit être contextualisé.

Un modèle pratique :

• EPSS élevé + KEV : traitement accéléré ;
• EPSS élevé + exposition internet : traitement prioritaire ;
• EPSS moyen + actif critique : revue humaine ;
• EPSS faible + non exposé : suivi planifié ;
• EPSS inconnu : ne pas supposer l’absence de risque.

Les sources qui complètent EPSS

EPSS gagne en valeur lorsqu’il est combiné avec toutes les autres sources :

• NVD pour l’identifiant, la description, CVSS et dates ;
• OpenCVE pour les produits et changements ;
• CISA KEV et GCVE pour exploitation confirmée ;
• CERT-FR, MSRC, GHSA et advisories fournisseurs pour le contexte de correction ;
• Exploit-DB et Nuclei pour signaux PoC ;
• CPE et périmètres pour savoir si vous êtes réellement concerné.

L’article EPSS vs CVSS vs KEV propose un comparatif complet des trois signaux.

EPSS dans les workflows SOC

EPSS peut aussi guider le threat hunting. Une CVE à probabilité élevée qui touche un produit présent dans le périmètre mérite une recherche proactive : logs applicatifs, scans entrants, comportements post-exploitation, connexions sortantes vers des IP suspectes.

L’enrichissement avec IP reputation et domain reputation permet de transformer une hypothèse CVE en chasse plus concrète. Une tentative d’exploitation réussie peut se matérialiser par une infrastructure de commande et contrôle, pas seulement par une erreur HTTP visible.

EPSS et communication métier

EPSS est parlant si on l’explique correctement. Dire “score 0,82” ne suffit pas. Dire “cette vulnérabilité est statistiquement plus susceptible d’être exploitée et touche un service exposé” aide davantage. Les décisions de patch doivent rester compréhensibles par les équipes non spécialistes.

EPSS dans les tableaux de bord

Un dashboard utile ne montre pas seulement une moyenne EPSS. Il doit permettre de filtrer les CVE par seuil, produit, statut, exposition et présence KEV. Les équipes peuvent suivre le nombre de findings EPSS élevé, le délai de correction associé, et la part de ces findings qui touche des actifs critiques. Cette mesure est plus utile qu’un total brut de vulnérabilités.

Une bonne pratique consiste à afficher EPSS à côté de CVSS, jamais à la place. Le lecteur voit ainsi la différence entre impact potentiel et probabilité. Pour les équipes de direction, un indicateur comme “CVE exposées avec EPSS élevé non corrigées” est beaucoup plus lisible qu’une distribution de scores.

EPSS et exceptions

Les exceptions sont inévitables. Une application métier peut ne pas pouvoir être patchée immédiatement. Un composant peut être compensé par segmentation. Une dépendance peut être présente mais non atteignable. EPSS aide alors à décider si l’exception est acceptable et quand elle doit être réévaluée.

Chaque exception devrait contenir le score EPSS au moment de la décision, le statut KEV, l’exposition, le propriétaire, les contrôles compensatoires et une date d’expiration. Si le score EPSS grimpe ou si la CVE rejoint KEV, l’exception doit être automatiquement revue.

Erreurs fréquentes

La première erreur est d’utiliser EPSS comme un oracle. Un score faible ne garantit pas l’absence de risque. La deuxième est de l’appliquer sans périmètre : une CVE très probable mais absente de votre parc n’est pas prioritaire. La troisième est de figer le score dans un ticket ; EPSS évolue, et les décisions doivent pouvoir évoluer aussi.

Conclusion

EPSS est l’un des meilleurs outils pour sortir du patch management purement CVSS. Il aide à prioriser selon la probabilité d’exploitation, mais il ne remplace ni KEV, ni l’inventaire, ni le jugement. Sa vraie valeur apparaît lorsqu’il est intégré à une chaîne complète : catalogue CVE, enrichissements, CPE, périmètres, threat intelligence et suivi de remédiation.