Un scan de vulnérabilités d’un réseau typique de PME fournit des dizaines, souvent des centaines de résultats. Chaque finding possède un score CVSS, et la réaction instinctive est claire : corriger d’abord les 9.8 et les 10.0. Mais est-ce vraiment la bonne stratégie ? Pas nécessairement. Le CVSS seul ne raconte qu’une partie de l’histoire, et parfois la moins importante.
CVSS : ce qu’il mesure et ce qu’il ne mesure pas
Le Common Vulnerability Scoring System (CVSS) est le standard de facto pour l’évaluation des vulnérabilités. La version actuelle CVSS 4.0 évalue une vulnérabilité selon plusieurs métriques :
- Attack Vector : Quelle proximité l’attaquant doit-il avoir ? (Réseau, adjacent, local, physique)
- Attack Complexity : Quel est le niveau de complexité de l’exploitation ?
- Privileges Required : L’attaquant a-t-il déjà besoin d’identifiants ?
- User Interaction : Un utilisateur doit-il effectuer une action ?
- Impact : Quels dégâts l’exploitation cause-t-elle ? (Confidentialité, intégrité, disponibilité)
Le CVSS répond donc à la question : « Quel pourrait être le degré de gravité si cette vulnérabilité est exploitée ? » C’est incontestablement important. Mais il manque une dimension décisive : Quelle est la probabilité qu’elle soit réellement exploitée ?
Le problème du CVSS comme seul critère de priorisation
Prenons un exemple concret. La National Vulnerability Database (NVD) recense actuellement plus de 64’000 CVEs avec un score CVSS de 7.0 ou plus, c’est-à-dire classées comme « élevées » ou « critiques ». Si chaque vulnérabilité avec un CVSS de 9.0+ doit être corrigée immédiatement, les PME font face à une tâche insurmontable.
S’y ajoute un problème statistique : seule une infime fraction de toutes les vulnérabilités connues est effectivement exploitée. Diverses études avancent des chiffres entre 2 et 5 pour cent. Cela signifie que 95 à 98 pour cent de toutes les CVEs restent des risques théoriques qui ne sont jamais attaqués en conditions réelles.
Parallèlement, il existe des vulnérabilités avec un score CVSS « modéré » de 6.0 ou 7.0 qui sont massivement exploitées par des groupes d’attaquants, parce qu’elles sont facilement automatisables, concernent des logiciels largement répandus ou parce que des exploits fiables sont publiquement disponibles.
Ceux qui priorisent exclusivement selon le CVSS investissent du temps et des ressources dans des vulnérabilités que personne n’attaque, tandis que des vulnérabilités effectivement exploitées avec un score plus bas restent sans traitement.
EPSS : la probabilité d’exploitation
L’Exploit Prediction Scoring System (EPSS) est un modèle relativement récent, développé par FIRST (Forum of Incident Response and Security Teams), qui comble exactement la lacune laissée par le CVSS. L’EPSS répond à la question : « Quelle est la probabilité que cette vulnérabilité soit activement exploitée dans les 30 prochains jours ? »
L’EPSS utilise pour cela des modèles de machine learning qui analysent une multitude de facteurs :
- Disponibilité de code d’exploit (par ex. sur GitHub, Exploit-DB, Metasploit)
- Activité sur les forums underground et les marketplaces du dark web
- Caractéristiques de la vulnérabilité (vecteur d’attaque, complexité)
- Diffusion du logiciel concerné
- Schémas d’exploitation historiques de vulnérabilités similaires
- Renseignement sur les menaces actuel
Le résultat est un pourcentage entre 0 et 1 (soit 0% et 100%). Un score EPSS de 0.95 signifie : avec une probabilité de 95 pour cent, cette vulnérabilité sera exploitée par des attaquants dans les 30 prochains jours. Un score de 0.001 signifie : la probabilité est de 0.1 pour cent.
L’EPSS en pratique
La distribution des scores EPSS est révélatrice : la grande majorité des CVEs ont un score EPSS inférieur à 0.1 (10%). Seule une petite fraction atteint des valeurs supérieures à 0.5 (50%). Cette distribution confirme ce que les chercheurs en sécurité savent depuis des années : la plupart des vulnérabilités ne sont jamais exploitées.
Cela devient intéressant lorsqu’on observe le CVSS et l’EPSS ensemble :
- CVSS élevé, EPSS faible : Théoriquement dangereux, mais pratiquement improbable. Exemple : une vulnérabilité complexe dans une fonction rarement utilisée d’un logiciel de niche. Le CVSS évalue l’impact théorique comme élevé, mais les attaquants n’ont aucune incitation à développer un exploit.
- CVSS faible, EPSS élevé : Théoriquement moins critique, mais en pratique très pertinent. Exemple : une vulnérabilité Cross-Site-Scripting (CVSS ~6.0) dans un plugin WordPress très répandu, pour lequel un exploit automatisé existe.
- CVSS élevé, EPSS élevé : Les cas les plus urgents. Théoriquement critique ET activement exploité. Ces vulnérabilités nécessitent des mesures immédiates.
- CVSS faible, EPSS faible : Priorité la plus basse. Théoriquement moins critique et pratiquement non exploité.
CISA KEV : les vulnérabilités confirmées comme activement exploitées
Alors que l’EPSS fournit une prévision, le catalogue Known Exploited Vulnerabilities (KEV) de la Cybersecurity and Infrastructure Security Agency (CISA) américaine fournit des faits : il répertorie les vulnérabilités qui sont effectivement exploitées activement par des attaquants.
Le catalogue KEV comprend actuellement plus de 1’100 vulnérabilités et est régulièrement mis à jour. Pour chaque vulnérabilité répertoriée, la CISA fixe un délai de remédiation contraignant — obligatoire pour les agences fédérales américaines, mais aussi un repère clair pour le secteur privé.
Les critères d’inclusion sont stricts :
- La vulnérabilité doit avoir un identifiant CVE
- Des preuves crédibles d’exploitation active doivent exister
- Une mesure de remédiation claire (patch ou contournement) doit être disponible
Lorsqu’une vulnérabilité figure dans le catalogue KEV, la question n’est plus « si », mais « à quelle vitesse » elle doit être corrigée. L’urgence est maximale.
C’est la combinaison qui fait la différence
Pris individuellement, chaque système a ses forces et ses faiblesses :
- CVSS évalue l’impact théorique, mais pas la probabilité d’exploitation
- EPSS prédit la probabilité d’exploitation, mais pas l’impact
- KEV confirme l’exploitation active, mais ne couvre qu’une fraction de toutes les vulnérabilités
Seule la combinaison des trois sources produit une priorisation intelligente qui prend en compte à la fois l’impact et la menace réelle.
Un modèle de priorisation pratique
Sur la base de la combinaison de CVSS, EPSS et KEV, un modèle de priorisation en quatre niveaux peut être défini :
Priorité 1 — Immédiat (dans les 24-48 heures) :
- Répertorié dans le catalogue CISA KEV (indépendamment du CVSS ou de l’EPSS)
- CVSS 9.0+ ET EPSS > 0.5
Priorité 2 — Urgent (dans les 7 jours) :
- CVSS 7.0+ ET EPSS > 0.3
- CVSS 9.0+ ET EPSS > 0.1
Priorité 3 — Planifié (dans les 30 jours) :
- CVSS 7.0+ ET EPSS < 0.3
- CVSS 4.0-6.9 ET EPSS > 0.1
Priorité 4 — Prochain cycle (dans les 90 jours) :
- CVSS < 7.0 ET EPSS < 0.1
- Findings informationnels
Ce modèle réduit considérablement la charge de travail : au lieu de devoir traiter simultanément 200 vulnérabilités « critiques », l’équipe informatique se concentre sur les 15 à 20 vulnérabilités qui représentent réellement le risque le plus élevé.
Exemples pratiques
Exemple 1 : Haute priorité malgré un CVSS modéré
CVE-2023-22515 (Atlassian Confluence) — CVSS 9.8, EPSS 0.97, dans le catalogue KEV. Ici, tous les indicateurs concordent : vulnérabilité grave, exploitation quasi certaine, attaque active confirmée. Priorité 1, mesures immédiates requises.
Exemple 2 : CVSS élevé, mais faible menace réelle
Certaines vulnérabilités reçoivent un score CVSS de 9.0 ou plus, mais ont un score EPSS inférieur à 0.01. Typique pour : les vulnérabilités dans des logiciels peu répandus, les vulnérabilités nécessitant des prérequis très spécifiques, ou les vulnérabilités pour lesquelles aucun code d’exploit n’existe. Celles-ci peuvent être traitées en priorité 3 — importantes, mais pas urgentes.
Exemple 3 : CVSS modéré, mais activement exploité
Les vulnérabilités dans les plugins CMS très répandus (WordPress, Joomla) ont souvent des scores CVSS entre 6.0 et 7.5, mais sont massivement attaquées de manière automatisée, car des kits d’exploitation sont disponibles. Des scores EPSS supérieurs à 0.5 avec un CVSS « seulement » moyen signalent : ce finding mérite plus d’attention que le score CVSS ne le laisse supposer.
MITRE ATT&CK : comprendre le contexte
Une dimension supplémentaire de la priorisation est offerte par le framework MITRE ATT&CK. Il classe les vulnérabilités et les techniques d’attaque dans une matrice qui représente l’ensemble du déroulement d’une attaque — de la compromission initiale jusqu’à l’exfiltration de données.
ATT&CK aide à répondre à des questions telles que :
- Cette vulnérabilité est-elle utilisée pour l’accès initial, ou l’attaquant a-t-il déjà besoin d’une présence dans le réseau ?
- Quels groupes d’attaquants sont connus pour utiliser cette technique ?
- Quelles étapes suivent typiquement après l’exploitation ?
Lorsqu’une vulnérabilité est classée comme technique d’« Initial Access » et utilisée par des groupes de ransomware connus, la priorité augmente indépendamment du score CVSS.
Mise en oeuvre au quotidien dans les PME
La théorie est convaincante — mais comment une PME aux ressources limitées met-elle en pratique cette priorisation combinée ?
Manuellement, c’est quasi impossible. Les scores CVSS figurent dans le rapport de scan, mais les scores EPSS doivent être consultés séparément via l’API FIRST, et le catalogue KEV est une source de données distincte. Croiser manuellement ces trois sources pour 200 findings n’est pas réaliste.
La solution réside dans la plateforme. Les plateformes modernes de gestion des vulnérabilités intègrent automatiquement CVSS, EPSS et KEV et affichent pour chaque finding une évaluation combinée du risque. Au lieu de consulter trois sources différentes, l’équipe informatique voit d’un seul coup d’oeil quelles vulnérabilités ont réellement la priorité.
Conclusion
Le CVSS seul n’est pas un critère de priorisation suffisant. Il évalue le pire cas théorique, mais ne dit rien sur la situation de menace réelle. L’EPSS complète avec la probabilité d’exploitation, le CISA KEV fournit des données d’attaques confirmées. Seule la combinaison des trois sources permet une priorisation qui déploie les ressources limitées là où elles produisent la plus grande réduction du risque.
ExposIQ intègre CVSS, EPSS et le catalogue CISA KEV directement dans les résultats de scan. Chaque finding est automatiquement évalué selon les trois sources, complété par un mapping MITRE ATT&CK. Vous voyez ainsi d’un seul coup d’oeil quelles vulnérabilités sont théoriquement critiques et lesquelles sont réellement attaquées. Le tout avec plus de 35 moteurs de scan, 64’000+ CVEs, 11’700+ templates Nuclei et 112 modules de validation d’exploits. Hébergé en Suisse, conforme à la nLPD, à partir de CHF 99 par mois. En savoir plus sur exposiq.ch.
