Chaque mois, les équipes sécurité voient tomber des centaines de nouvelles CVE, alors que leurs capacités de remédiation restent, elles, parfaitement stables. Le CVSS, seul, ne résout pas ce problème : il indique une gravité théorique, pas une menace réelle. C’est là qu’intervient l’EPSS, un score conçu pour répondre à une question opérationnelle très concrète : quelle est la probabilité que cette vulnérabilité soit exploitée dans les 30 prochains jours ? Utilisé correctement, il permet de transformer une liste ingérable de failles en un plan d’action réaliste, aligné sur les contraintes réelles de patching.
- L’EPSS estime une probabilité d’exploitation à 30 jours, sur une échelle de 0 à 1, complétée par un percentile comparatif.
- Le CVSS mesure la gravité potentielle d’une faille, l’EPSS mesure la probabilité réelle qu’elle soit exploitée : les deux indicateurs se complètent, ils ne se substituent pas l’un à l’autre.
- Moins de 6 % des CVE publiées font l’objet d’une exploitation avérée, ce qui justifie une priorisation fondée sur la probabilité plutôt que sur le seul volume de failles.
- Une méthode de priorisation efficace combine seuils EPSS, score CVSS, exposition internet, criticité métier et signaux KEV (CISA).
- L’EPSS doit être réévalué régulièrement et croisé avec la threat intelligence, car un score peut évoluer rapidement selon l’apparition d’un exploit public.
Score EPSS : définition et ce qu’il mesure vraiment
L’Exploit Prediction Scoring System (EPSS) est un score développé sous l’égide du FIRST (Forum of Incident Response and Security Teams), présenté pour la première fois lors de la conférence Black Hat en 2019. Son objectif initial partait d’un constat simple : les équipes de sécurité faisaient face à un volume de vulnérabilités publiées largement supérieur à leur capacité de traitement, alors que moins de 5 % de ces failles étaient réellement exploitées par des attaquants. Corriger « tout, partout, tout de suite » n’a jamais été une stratégie tenable.
Le score EPSS répond donc à une question précise : quelle est la probabilité d’exploitation d’une vulnérabilité donnée dans un horizon court, fixé à 30 jours ? Il ne s’agit pas d’une mesure de gravité, mais d’une estimation statistique fondée sur des données observées. C’est ce qui distingue fondamentalement l’EPSS du CVSS : l’un parle de probabilité, l’autre de sévérité potentielle.
Un score pensé pour l’action, pas pour la théorie
Contrairement à une note d’impact figée, l’EPSS est conçu pour guider une décision opérationnelle : faut-il corriger cette CVE cette semaine, ce mois-ci, ou peut-elle attendre ? Cette orientation « action » explique pourquoi le score est recalculé en continu, et pourquoi il constitue un outil naturel de priorisation dans la gestion des vulnérabilités.
Comprendre cette finalité est essentiel avant d’entrer dans le détail du fonctionnement du modèle, de ses données sources et de la lecture correcte du score.
Comment fonctionne l’EPSS : données, modèle et lecture du score

Le score EPSS est une valeur comprise entre 0 et 1 : plus il se rapproche de 1, plus la probabilité d’exploitation dans les 30 jours est élevée ; plus il se rapproche de 0, plus elle est faible. À ce score s’ajoute un percentile EPSS, qui indique la position relative d’une vulnérabilité par rapport à l’ensemble des CVE analysées. Un percentile de 85 % signifie que la faille est plus susceptible d’être exploitée que 85 % des autres vulnérabilités connues à cet instant.
Les signaux utilisés par le modèle
Le modèle s’appuie sur un ensemble de facteurs observables, parmi lesquels :
- les caractéristiques techniques de la vulnérabilité (type de faille, gravité, nombre de logiciels affectés) ;
- l’historique d’exploitation connu et les renseignements de threat intelligence ;
- la disponibilité d’un exploit public ou d’un code de démonstration ;
- le vecteur d’attaque, en particulier l’accessibilité à distance ;
- l’impact potentiel sur des systèmes critiques ou des données sensibles.
La version initiale du modèle reposait sur 16 variables, incluant la présence d’un exploit mature, l’exécution à distance, l’usage local, le type de service exposé (par exemple un service web), certaines familles de vulnérabilités (corruption mémoire, exécution de code, déni de service), ainsi que des indicateurs liés à des éditeurs spécifiques. Le modèle a depuis évolué : une version 4 a succédé à la première génération, avec une architecture affinée, sans que cela remette en cause la logique générale du score.
Un score vivant, à réévaluer régulièrement
Point d’attention essentiel : les caractéristiques qui alimentent le calcul peuvent évoluer dans le temps. L’apparition d’un exploit public change immédiatement la donne, tout comme une vague d’activité observée sur le terrain. Le score EPSS n’est donc jamais définitif : une CVE jugée peu risquée un mois peut voir son score bondir le mois suivant. Cette dynamique impose une actualisation régulière des scores dans les outils de scan de vulnérabilités, plutôt qu’une lecture figée à un instant donné.
Cette logique probabiliste, mouvante et fondée sur des données réelles, s’oppose frontalement à l’approche statique du CVSS, qu’il convient à présent de détailler pour mieux comprendre leur complémentarité.
EPSS vs CVSS : probabilité d’exploitation contre gravité
Le CVSS (Common Vulnerability Scoring System), notamment dans sa version CVSS v3.1, mesure la sévérité intrinsèque d’une vulnérabilité : facilité d’exploitation technique et impact potentiel sur la confidentialité, l’intégrité et la disponibilité d’un système. L’échelle CVSS va de 0 à 10, et se répartit généralement en plusieurs niveaux :
| Score CVSS | Niveau de gravité |
|---|---|
| 0.0 | Aucun |
| 0.1 à 3.9 | Faible |
| 4.0 à 6.9 | Moyen |
| 7.0 à 8.9 | Élevé |
| 9.0 à 10.0 | Critique |
Une limite structurelle du CVSS
Le CVSS ne prend pas en compte la disponibilité effective d’un exploit, la motivation réelle des attaquants, ni la spécificité de l’environnement cible. Deux CVE notées 9.8 en CVSS peuvent ainsi avoir des probabilités d’exploitation radicalement différentes : l’une jamais exploitée en pratique, l’autre massivement ciblée par des campagnes automatisées. C’est précisément ce vide que l’EPSS comble, en s’appuyant sur des données issues des CVE elles-mêmes et sur des informations concernant des exploits réels observés sur le terrain.
Pourquoi opposer les deux scores est une erreur
Utiliser uniquement le CVSS conduit à traiter en urgence des failles critiques mais jamais exploitées, au détriment de vulnérabilités moins « graves » sur le papier mais activement attaquées. À l’inverse, se fier uniquement à l’EPSS revient à ignorer l’impact potentiel réel d’une exploitation réussie. Une recherche conjointe menée par le Cyentia Institute et le FIRST, sponsorisée par Tenable, rappelle qu’environ 250 000 CVE ont été publiées au total, avec une croissance annuelle de 16 % sur les sept dernières années. Dans ce volume, seuls 6 % des CVE publiées auraient fait l’objet d’une exploitation avérée, un taux resté stable dans le temps, avec un cumul proche de 13 800 CVE exploitées recensées et une estimation avoisinant les 15 000 vulnérabilités exploitées connues.
Ces chiffres confirment la nécessité de croiser gravité et probabilité pour bâtir une priorisation crédible, ce qui amène naturellement à la construction d’une méthode opérationnelle combinant les deux indicateurs et le contexte métier.
Méthode de priorisation : combiner EPSS, CVSS et contexte
Deux usages simples de l’EPSS sont couramment cités : classer les vulnérabilités par score décroissant et traiter en priorité les plus élevées, ou fixer un seuil EPSS au-delà duquel toute CVE doit être corrigée. Ces approches sont un bon point de départ, mais elles restent incomplètes si elles ne sont pas croisées avec d’autres critères.
Construire une matrice de décision réaliste
Une méthode robuste combine plusieurs axes :
- le score EPSS (probabilité d’exploitation) et son percentile ;
- le score CVSS (gravité potentielle) ;
- la présence dans le catalogue KEV (Known Exploited Vulnerabilities) de la CISA, signal fort d’exploitation active ;
- l’exposition internet de l’actif concerné (accessible depuis l’extérieur ou uniquement en interne) ;
- le contexte métier : criticité du système, sensibilité des données traitées.
Exemple de matrice de priorisation
| Profil de la CVE | Action recommandée |
|---|---|
| EPSS élevé + CVSS élevé + exposée sur internet + présente au KEV | Correction immédiate, SLA de remédiation court (24-72h) |
| EPSS élevé + CVSS moyen + système interne critique | Correction prioritaire, SLA sous 7 à 15 jours |
| EPSS faible + CVSS élevé + système peu exposé | Surveillance, correction planifiée dans le cycle normal |
| EPSS faible + CVSS faible | Traitement différé, revue périodique |
Ce type de grille permet de fixer des SLA de remédiation différenciés, plutôt qu’un délai unique appliqué sans distinction à des milliers de CVE. Une présentation de 2013 avait déjà démontré l’intérêt de cette logique ciblée : corriger les vulnérabilités de niveau élevé ou moyen disposant de kits d’attaque automatiques améliorait la sécurité de 62,81 %, contre 19,64 % pour de simples démonstrations d’exploit, et seulement 3,2 % pour une correction non ciblée des vulnérabilités élevées ou moyennes sans distinction de contexte d’exploitation. Ces écarts illustrent, avec vingt ans d’avance sur l’EPSS moderne, la supériorité d’une priorisation fondée sur la probabilité réelle d’exploitation.
Reste à savoir comment industrialiser cette méthode dans les outils et processus quotidiens des équipes de remédiation.
Intégrer l’EPSS dans les outils et les processus de remediation

Le FIRST publie les scores EPSS en accès ouvert, mis à jour quotidiennement, ce qui permet de les intégrer facilement aux flux existants de gestion des vulnérabilités. En pratique, l’intégration suit généralement plusieurs étapes.
Récupérer et enrichir les données
Les résultats bruts d’un scan de vulnérabilités listent des CVE associées à des actifs. L’étape suivante consiste à enrichir chaque ligne avec le score EPSS correspondant, son percentile, la présence éventuelle au KEV, et les métadonnées de contexte (exposition internet, criticité de l’actif). Cet enrichissement peut être automatisé via des API, en s’appuyant sur des flux régulièrement mis à jour plutôt que sur des exports ponctuels.
Automatiser le tri et la création de tickets
Une fois les données enrichies, des règles automatiques peuvent générer des tickets de remédiation classés selon la matrice de décision définie précédemment. Un seuil EPSS élevé combiné à une exposition internet peut par exemple déclencher automatiquement un ticket avec priorité maximale, sans intervention manuelle initiale.
Piloter par la réduction du risque, pas par le volume
L’indicateur de succès ne devrait pas être « nombre de CVE corrigées », mais plutôt la réduction effective du risque d’exploitation : proportion de vulnérabilités à fort EPSS traitées dans les délais, respect des SLA différenciés, évolution du score de risque global de l’organisation. Ce changement de focale évite de valoriser des corrections faciles mais peu utiles, au détriment de failles réellement dangereuses.
Cette intégration opérationnelle, bien qu’efficace, comporte des limites qu’il convient d’anticiper pour éviter tout excès de confiance dans le score.
Limites de l’EPSS et bonnes pratiques pour l’optimiser
L’EPSS reste un score probabiliste, pas une certitude. Il ne doit jamais être utilisé seul lors d’une priorisation : c’est une limite explicitement reconnue, y compris par ses concepteurs.
Les pièges à éviter
- traiter l’exploitation comme une variable binaire, alors que l’intensité et la durée de l’activité varient fortement selon les CVE, allant d’une exploitation brève et faible à une activité quotidienne continue sur plusieurs trimestres ;
- ignorer les vulnérabilités peu télémétrées, pour lesquelles le modèle dispose de moins de signaux ;
- se reposer sur un score figé sans réévaluation, alors qu’un exploit public peut apparaître du jour au lendemain ;
- négliger le contexte métier au profit d’un seuil unique appliqué mécaniquement.
Bonnes pratiques opérationnelles
Il est recommandé de croiser systématiquement l’EPSS avec la threat intelligence propre à son secteur, de documenter des exceptions justifiées pour les actifs critiques non exposés, et de revoir les scores à fréquence rapprochée plutôt qu’une fois par trimestre. La combinaison EPSS, CVSS, KEV et contexte métier reste, à ce jour, l’approche la plus équilibrée pour transformer un flux massif de CVE en un plan de remédiation réaliste et défendable.
FAQ
Qu’est-ce que le score EPSS et comment est-il défini ?
L’EPSS est un score compris entre 0 et 1 qui estime la probabilité qu’une vulnérabilité soit exploitée dans les 30 jours suivant son évaluation, à partir de signaux comme l’historique d’exploitation, la disponibilité d’un exploit public et le vecteur d’attaque.
Quelle est la définition de l’EPSS ?
L’Exploit Prediction Scoring System est un système développé par le FIRST qui produit, pour chaque CVE, une probabilité d’exploitation ainsi qu’un percentile comparatif, utilisé pour prioriser les actions de remédiation.
Quelle est l’échelle de score CVSS ?
Le CVSS va de 0 à 10 et se découpe en niveaux : faible (0,1 à 3,9), moyen (4,0 à 6,9), élevé (7,0 à 8,9) et critique (9,0 à 10,0), une échelle qui mesure la gravité potentielle, non la probabilité réelle d’exploitation.
Face à un volume de CVE qui continue de croître chaque année, l’EPSS offre un levier concret pour prioriser sans se noyer dans la masse, à condition de le croiser systématiquement avec la gravité, l’exposition et le contexte métier.






