TL;DR — Un score CVSS élevé ne signifie pas qu’une vulnérabilité sera exploitée demain. Un score EPSS faible ne signifie pas qu’elle ne le sera jamais. La vraie priorisation naît de la combinaison des deux — contextualisée par votre exposition réelle. Ce guide vous explique tout, avec une calculette interactive pour calculer vos score CVSS !
Pourquoi ce guide ?
Chez BZHunt, nos pentesters publient régulièrement des CVE. À chaque publication, la même question revient de la part des RSSI : “9.8, c’est grave ?”. La réponse honnête est : ça dépend. Pas de votre infrastructure en premier lieu, mais de ce que vous lisez réellement dans ce score.
Le CVSS est un outil de communication, pas de décision. L’EPSS est un outil de probabilité, pas de gravité. Utilisés ensemble intelligemment, ils constituent un socle solide pour arbitrer vos campagnes de patching. Utilisés séparément ou mal compris, ils génèrent soit de la panique, soit de la complaisance.
Ce guide s’adresse aux RSSI, DSI et équipes sécurité qui veulent comprendre ces métriques de l’intérieur — sans avoir à lire les 80 pages de spécification du FIRST.
Qui attribue les CVE ? Le rôle croissant des CNA
Avant de plonger dans les scores, un mot sur qui attribue les numéros de CVE. Historiquement, c’était principalement le MITRE qui jouait ce rôle de coordination. Mais la croissance exponentielle des vulnérabilités découvertes a rendu ce modèle centralisé insuffisant.
C’est là qu’interviennent les CNA — CVE Numbering Authorities. Ce sont des organisations autorisées à attribuer directement des identifiants CVE dans leur périmètre, sans passer par le MITRE. On compte aujourd’hui plus de 400 CNA dans le monde, et leur nombre ne cesse de croître.
Parmi les CNA les plus actifs :
- Éditeurs logiciels : Microsoft, Google, Apple, Red Hat attribuent les CVE de leurs propres produits
- Plateformes de bug bounty : GitHub a largement automatisé le processus via les Security Advisories
- Et côté français : YesWeHack est devenu CNA en 2025, une belle reconnaissance pour l’écosystème cyber européen 🇫🇷
La démocratisation des CNA est une bonne nouvelle pour l’écosystème : elle accélère la publication des CVE et réduit le goulot d’étranglement du MITRE. En revanche, elle implique aussi des disparités dans la qualité des scores CVSS attribués — chaque CNA ayant sa propre interprétation des métriques. Raison de plus pour comprendre ce que ces scores signifient réellement.
Calculette CVSS v3.1 interactive
Calculez votre propre score CVSS v3.1 et visualisez l’impact de chaque métrique en temps réel.
Le score CVSS v3 : anatomie d’un langage universel
Ce que CVSS mesure (et ce qu’il ne mesure pas)
Le Common Vulnerability Scoring System (CVSS) est un standard ouvert maintenu par le FIRST. Son objectif est de fournir un score normalisé qui caractérise la sévérité intrinsèque d’une vulnérabilité, indépendamment de votre environnement.
C’est là le premier malentendu fondamental : le score CVSS de base ne prend pas en compte votre SI. Il décrit la vulnérabilité dans des conditions idéales pour l’attaquant. C’est une note de gravité potentielle, pas de risque opérationnel.
Les trois groupes de métriques
CVSS v3 est structuré en trois couches :
1. Score de base (Base Score) C’est le score publié dans les bulletins de sécurité et les CVE. Il comprend deux sous-groupes :
| Sous-groupe | Métriques |
|---|---|
| Exploitabilité | Vecteur d’attaque, Complexité d’attaque, Privilèges requis, Interaction utilisateur |
| Impact | Confidentialité, Intégrité, Disponibilité + notion de Périmètre (Scope) |
2. Score temporel (Temporal Score) Il module le score de base selon l’état actuel de la vulnérabilité : existence d’un exploit public, niveau de maturité du correctif, fiabilité du rapport. Peu utilisé dans la pratique car il nécessite une mise à jour continue.
3. Score environnemental (Environmental Score) C’est là que vous intervenez en tant que RSSI : vous pouvez pondérer les métriques selon votre contexte (est-ce que la confidentialité de ce système est vraiment critique pour vous ?). Rarement exploité, pourtant le plus utile.
Décrypter les métriques de base
Vecteur d’attaque (AV)
Définit la proximité nécessaire pour exploiter la faille :
| Valeur | Signification | Score |
|---|---|---|
| N — Network | Exploitable depuis Internet | 0.85 |
| A — Adjacent | Réseau local ou VLAN requis | 0.62 |
| L — Local | Accès local à la machine requis | 0.55 |
| P — Physical | Accès physique requis | 0.20 |
Complexité d’attaque (AC)
Reflète les conditions techniques nécessaires au succès de l’exploit :
| Valeur | Signification | Score |
|---|---|---|
| L — Low | Exploitable de manière reproductible et sans condition particulière | 0.77 |
| H — High | Nécessite des conditions spécifiques difficiles à réunir | 0.44 |
Note de terrain BZHunt : Un AC:H ne signifie pas que c’est inexploitable. Sur nos missions Red Team, nous consacrons simplement plus de temps à réunir les conditions. Un AC:H sur un système exposé à Internet reste une priorité.
Privilèges requis (PR)
Niveau d’accès préalable nécessaire à l’attaquant :
| Valeur | Signification |
|---|---|
| N — None | Aucun compte requis |
| L — Low | Compte utilisateur basique |
| H — High | Compte administrateur ou équivalent |
Interaction utilisateur (UI)
Indique si l’exploitation nécessite qu’une victime effectue une action :
| Valeur | Signification |
|---|---|
| N — None | Aucune interaction requise |
| R — Required | Un utilisateur doit cliquer, ouvrir, visiter… |
Périmètre (Scope)
Métrique souvent mal comprise, fondamentale pour comprendre la dangerosité réelle :
| Valeur | Signification |
|---|---|
| U — Unchanged | L’exploit reste confiné au composant vulnérable |
| C — Changed | L’exploit peut impacter d’autres composants (ex : sortie de sandbox, pivot) |
Un
S:C(Scope Changed) indique qu’une compromission du composant vulnérable peut se propager au-delà — typiquement les hyperviseurs, les interpréteurs, les navigateurs. C’est un indicateur de mouvement latéral potentiel que nous retrouvons fréquemment dans nos audits Active Directory.
Confidentialité, Intégrité, Disponibilité (CIA)
L’impact potentiel sur chacun des trois piliers de la sécurité :
| Valeur | Signification |
|---|---|
| H — High | Perte totale ou accès complet |
| L — Low | Perte partielle ou accès limité |
| N — None | Aucun impact |
La formule de calcul
Sans entrer dans toutes les subtilités mathématiques, voici la logique générale :
ISCBase = 1 − [(1−C) × (1−I) × (1−A)]
Si Scope = Unchanged :
ISC = 6.42 × ISCBase
Score = Roundup(min(ISC + Exploitabilité, 10))
Si Scope = Changed :
ISC = 7.52×[ISCBase−0.029] − 3.25×[ISCBase−0.02]^15
Score = Roundup(min(1.08 × (ISC + Exploitabilité), 10))
Exploitabilité = 8.22 × AV × AC × PR × UI
La fonction Roundup arrondit au dixième supérieur — c’est pourquoi vous verrez rarement deux vulnérabilités différentes avec exactement le même score.
Lire un vecteur CVSS
Un vecteur CVSS v3.1 ressemble à ceci :
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Ce vecteur correspond à 9.8 (Critique) — une vulnérabilité exploitable depuis Internet, sans condition ni compte, avec un impact total sur les trois piliers. C’est exactement le profil de nos deux 0-day GLPI publiés en 2026.
Les limites du CVSS v3
Le CVSS v3 est critiqué depuis des années. Les reproches légitimes :
- Il ignore le contexte : une RCE sur un serveur de test isolé score pareil que sur votre ERP de production.
- Il ne mesure pas la probabilité d’exploitation : un score 9.8 sans exploit public disponible peut être moins urgent qu’un 7.5 avec un exploit weaponisé en circulation.
- La métrique Scope est difficile à interpréter de manière cohérente entre les différents éditeurs.
- Les scores temporels et environnementaux sont presque jamais utilisés, alors qu’ils constituent la valeur ajoutée réelle du framework.
CVSS v4 : ce qui change vraiment
Publié en novembre 2023 par le FIRST, CVSS v4.0 apporte des changements structurels significatifs. Il n’est pas encore universellement déployé — la plupart des CVE publiées fin 2025 proposent encore du v3.1 en priorité — mais il est important de comprendre où le standard se dirige.
La nouvelle nomenclature
CVSS v4 introduit une nomenclature explicite selon les groupes de métriques utilisés :
| Nomenclature | Métriques incluses |
|---|---|
| CVSS-B | Base uniquement |
| CVSS-BT | Base + Threat (remplace Temporal) |
| CVSS-BE | Base + Environmental |
| CVSS-BTE | Base + Threat + Environmental |
Les nouveautés majeures
1. Remplacement de Temporal par Threat Le groupe Temporal v3 comportait plusieurs métriques rarement renseignées. CVSS v4 les remplace par une seule : Exploit Maturity (E), qui indique si un exploit est disponible, confirmé ou weaponisé. Plus simple, plus actionnable.
2. Nouvelles métriques de base CVSS v4 ajoute des métriques qui manquaient cruellement :
- Attack Requirements (AT) : conditions préalables spécifiques (configuration particulière, race condition…)
- Subsequent System Impact : distingue l’impact sur le système vulnérable de l’impact sur les systèmes voisins
3. Un vecteur plus expressif Le vecteur v4 est plus long mais plus précis. Il distingue notamment l’impact sur le système vulnérable (VS) de l’impact sur les systèmes suivants (SS), ce qui adresse directement la limitation du Scope v3.
4. Suppression des scores partiels En v3, il était possible de calculer uniquement le score de base. En v4, le FIRST encourage fortement à toujours contextualiser avec au minimum la métrique Threat.
CVSS 3.1 vs CVSS 4.0 : comparaison visuelle
Cliquez sur un groupe pour voir le détail des changements.
Ce que ça change pour vous
En pratique, pour un RSSI en 2026 :
- La plupart de vos outils (scanners, SIEM, CMDB) sont encore en v3.1
- Les nouvelles CVE commencent à proposer des scores v4 en complément
- La migration vers v4 est progressive — vous avez le temps de vous former
- La logique reste la même : comprendre les métriques pour contextualiser le score
EPSS : la dimension probabiliste qui manquait
Qu’est-ce que l’EPSS ?
L’Exploit Prediction Scoring System (EPSS) est un modèle prédictif développé par le FIRST et mis à jour quotidiennement. Contrairement au CVSS qui mesure la gravité, l’EPSS mesure la probabilité qu’une vulnérabilité soit exploitée dans les 30 prochains jours.
Le score EPSS est un nombre entre 0 et 1 (ou 0% et 100%). Un score de 0.94 signifie que, selon le modèle, cette vulnérabilité a 94% de chances d’être exploitée dans le mois qui vient.
Comment le modèle fonctionne
L’EPSS s’appuie sur des données observées :
- Présence d’un PoC ou exploit public (GitHub, ExploitDB, Metasploit…)
- Mentions dans des flux de threat intelligence
- Activité de scanning observée sur des honeypots
- Caractéristiques intrinsèques de la vulnérabilité (type, vecteur…)
- Historique des CVE similaires
Le modèle est réentraîné régulièrement. Un score peut donc changer significativement du jour au lendemain si un exploit est publié ou si une campagne d’exploitation est détectée.
L’EPSS en chiffres
Les données historiques du FIRST montrent une réalité frappante :
- ~85% des CVE ne sont jamais exploitées dans la nature
- Parmi les CVE avec un score CVSS ≥ 9.0, moins de 10% ont un score EPSS > 0.5
- Prioriser uniquement sur le CVSS revient à traiter 90% de faux positifs critiques
Cette réalité, nous la vivons lors de chaque engagement Red Team. Nous ne cherchons pas la CVE la plus haute — nous cherchons la CVE exploitable dans votre contexte, avec un chemin d’attaque cohérent. C’est exactement ce que l’EPSS tente de modéliser.
Où consulter les scores EPSS ?
- FIRST EPSS : référence officielle, API disponible
- EUVD (ENISA) : la base européenne affiche le score EPSS directement sur les fiches de vulnérabilités (exemple : EUVD-2024-52191)
- EPSS dans votre scanner : Tenable, Qualys, Rapid7 intègrent l’EPSS nativement
Note : contrairement à ce qu’on lit parfois, le NIST NVD n’affiche pas le score EPSS sur ses fiches CVE (exemple : CVE-2024-53923 sur le NVD — pas d’EPSS). Pour obtenir le score EPSS d’une CVE, utilisez l’API FIRST ou consultez l’EUVD.
EUVD : la base de vulnérabilités souveraine européenne
En parallèle du NIST NVD américain et du programme CVE du MITRE, l’Europe dispose désormais de sa propre base de vulnérabilités : l’European Vulnerability Database (EUVD), opérée par l’ENISA dans le cadre de la directive NIS2.
L’EUVD introduit une nomenclature souveraine avec ses propres identifiants EUVD-YYYY-XXXXX, tout en maintenant les correspondances avec les CVE existantes. Concrètement, chaque vulnérabilité référencée dans l’EUVD peut être consultée avec son identifiant européen et son CVE-ID.
Pourquoi c’est important pour un RSSI français :
- L’EUVD affiche le score EPSS directement sur les fiches (contrairement au NVD)
- Elle propose un dashboard des vulnérabilités activement exploitées comparable au KEV (Known Exploited Vulnerabilities) de la CISA
- Elle constitue la référence dans le cadre réglementaire européen (NIS2, Cyber Resilience Act)
- Elle réduit la dépendance au MITRE et au NIST, dont les délais de traitement s’allongent
Chez BZHunt, nous orientons progressivement nos déclarations et références vers l’EUVD en complément des CVE — parce que la souveraineté numérique, c’est aussi savoir d’où viennent nos données de vulnérabilités.
CVSS + EPSS : comment les combiner ?
La combinaison la plus efficace est une matrice à deux axes :
EPSS faible EPSS élevé
─────────────────────────────────────
CVSS │ Surveiller │ TRAITER EN
élevé │ (peu probable │ PRIORITÉ
│ mais grave) │ ABSOLUE
─────────────────────────────────────
CVSS │ Traiter en │ Traiter rapidement
faible │ maintenance │ (exploitation active
│ normale │ mais impact limité)
Notre recommandation pratique chez BZHunt :
- CVSS ≥ 9 et EPSS ≥ 0.5 → Patch sous 24-48h, pas de discussion
- CVSS ≥ 7 et EPSS ≥ 0.3 → Patch dans le cycle hebdomadaire
- CVSS ≥ 7 et EPSS < 0.1 → Planifier, surveiller l’évolution de l’EPSS
- CVSS < 7 → Cycle de patching normal, prioriser par exposition
Ajoutez à cette matrice votre criticité métier : une vulnérabilité CVSS 7.0 / EPSS 0.05 sur votre Active Directory mérite plus d’attention qu’un CVSS 9.0 / EPSS 0.4 sur un serveur de test hors production.
Ce que les scores ne vous disent pas
Après des centaines de missions de pentest et de Red Team, voici ce que nos experts observent sur le terrain :
Un score CVSS 6.0 peut tuer votre production. Si la disponibilité de votre ERP est vitale et que la vulnérabilité permet un crash du service (A:H), peu importe que la confidentialité et l’intégrité ne soient pas impactées.
Un score EPSS de 0.95 peut ne jamais vous toucher. Si la vulnérabilité cible un service que vous n’exposez pas, l’exploitation active dans le monde n’a aucune incidence directe.
L’anecdote qu’on raconte à chaque restitution. Imaginez : nous trouvons une RCE sur la machine à café connectée de votre LAN. Score CVSS : 10/10. Panique à bord ? Pas forcément. Cette machine à café n’héberge aucune donnée métier, ne donne accès à aucun actif critique et n’a aucun impact sur votre activité business (quoique… le café reste un sujet sensible dans beaucoup d’organisations). Le score CVSS mesure la criticité technique de la vulnérabilité, pas son impact réel sur votre métier. Une telle faiblesse est à nuancer avec le contexte opérationnel — et c’est précisément ce travail de contextualisation que nous faisons systématiquement lors de nos restitutions d’audit.
La vraie question est toujours : existe-t-il un chemin d’attaque vers ce composant depuis un attaquant externe ou un utilisateur interne mal intentionné ? C’est précisément ce que nos audits de pentest vérifient — pas le score, mais l’atteignabilité.
Conclusion
Le CVSS est un langage, pas une vérité. L’EPSS est une probabilité, pas une certitude. Ensemble, ils vous donnent un point de départ rationnel pour prioriser — mais c’est votre connaissance de votre SI qui transforme ces chiffres en décisions.
Chez BZHunt, nous intégrons systématiquement ces métriques dans nos rapports de pentest, accompagnées d’une cotation environnementale qui reflète votre exposition réelle. Parce qu’un 9.8 sur un serveur isolé et un 9.8 sur votre contrôleur de domaine n’ont pas du tout la même couleur.
Pour aller plus loin :