Un score CVSS n’est pas un risque

Prenons un lundi matin ordinaire (exemple fictif). Le scanner a rendu son rapport : 412 vulnérabilités, dont 38 notées critiques. La politique interne demande de corriger les critiques sous sept jours, et l’équipe a la capacité d’en traiter une dizaine. Il faut choisir lesquelles passent en premier.

Trier par note CVSS décroissante est le réflexe le plus répandu. Ce tri repose sur un malentendu, que les auteurs du standard ont eux-mêmes pris soin de dissiper.

Ce que mesure CVSS, selon ses auteurs

Le Common Vulnerability Scoring System est maintenu par le FIRST. Le guide utilisateur de la version 3.1 consacre une section à la question, intitulée « CVSS Measures Severity, not Risk » (CVSS v3.1 User Guide). CVSS mesure la sévérité d’une vulnérabilité ; le risque est une autre grandeur.

La sévérité décrit les caractéristiques intrinsèques du défaut : comment on l’atteint, ce qu’il faut pour l’exploiter, ce qu’il permet. Elle est identique pour toutes les organisations. Le risque dépend de votre contexte : l’exposition de l’actif, les données qu’il contient, l’exploitation en cours ou non de la vulnérabilité, l’existence d’une mesure compensatoire. Il varie d’une organisation à l’autre.

Le score publié dans les bases de vulnérabilités est presque toujours le score de base, qui ignore tout de votre infrastructure.

Lire le vecteur

Un 9,8 isolé apprend peu de chose. Son vecteur en dit davantage :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H   → 9.8 (Critique)

Attaque par le réseau (AV:N), complexité faible (AC:L), aucun privilège (PR:N) ni interaction (UI:N) requis, impact élevé sur la confidentialité, l’intégrité et la disponibilité. Si le composant concerné n’écoute que sur une interface interne, AV:N reste exact au sens de la spécification et décrit pourtant mal votre exposition réelle. Le calculateur CVSS 3.1 décompose un vecteur métrique par métrique et montre ce qui fait varier le score.

CVSS 3.1 et 4.0 : les changements

La version 4.0, publiée par le FIRST en novembre 2023 (spécification), corrige plusieurs défauts reprochés à la 3.1.

	CVSS 3.1	CVSS 4.0
Groupes de métriques	Base, Temporal, Environmental	Base, Threat, Environmental, Supplemental
Conditions d’attaque	Attack Complexity seule	AC, plus une nouvelle métrique Attack Requirements (AT)
Interaction utilisateur	None, Required	None, Passive, Active
Portée	Métrique Scope (S)	Supprimée : impacts séparés sur le système vulnérable (VC, VI, VA) et sur les systèmes en aval (SC, SI, SA)
Menace	Exploit Code Maturity, Remediation Level, Report Confidence	Exploit Maturity seule
Nomenclature	« score CVSS »	CVSS-B, CVSS-BT, CVSS-BE ou CVSS-BTE selon les groupes utilisés

La même exécution de code à distance, sans prérequis, s’écrit ainsi en 4.0 :

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N   → 9.3 (Critique)

Pour la priorisation, la nouvelle nomenclature est le changement le plus utile. Écrire « CVSS-B 9.3 » indique explicitement qu’il s’agit d’un score de base, calculé sans information sur la menace ni sur l’environnement. Le lecteur sait d’emblée ce qui manque au calcul.

EPSS : une probabilité d’exploitation

L’Exploit Prediction Scoring System, également porté par le FIRST, traite une autre question : la probabilité qu’une activité d’exploitation de la CVE soit observée dans les 30 jours qui suivent. Le score, compris entre 0 et 1, est accompagné d’un percentile et recalculé chaque jour à partir de données d’observation et des caractéristiques de la vulnérabilité.

L’API est publique et ne demande pas d’authentification :

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" | jq '.data[0]'

La réponse contient epss (la probabilité), percentile et la date du calcul. La FAQ EPSS rappelle deux précautions. EPSS estime une probabilité d’exploitation dans la nature et ne dit rien de l’impact : une CVE à faible EPSS sur votre actif le plus critique peut rester prioritaire. Et il s’agit d’une estimation statistique sur l’ensemble des vulnérabilités, qui ignore si votre organisation est spécifiquement visée.

KEV : une exploitation constatée

Le catalogue Known Exploited Vulnerabilities de l’agence américaine CISA recense les vulnérabilités pour lesquelles il existe une preuve fiable d’exploitation active. Trois conditions sont requises pour y entrer : un identifiant CVE, une exploitation avérée et une mesure de remédiation claire. Le catalogue est disponible en JSON :

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '.vulnerabilities[] | select(.cveID == "CVE-2021-44228")
        | {cveID, dateAdded, knownRansomwareCampaignUse}'

EPSS prédit, KEV constate. Une CVE inscrite au catalogue et présente dans votre parc mérite d’être traitée avant les autres, quelle que soit sa note CVSS. En France, les avis et alertes du CERT-FR jouent un rôle complémentaire, notamment pour les produits très déployés dans les administrations et les entreprises françaises.

Une priorisation contextuelle

Aucune de ces sources ne suffit seule. Combinées à votre inventaire, elles donnent une grille défendable, à adapter à votre organisation.

1. Exploitation avérée. La CVE figure dans KEV, ou une alerte CERT-FR mentionne une exploitation. Si l’actif est exposé, le traitement est immédiat.
2. Exposition. L’actif est-il joignable depuis Internet, depuis un réseau partenaire, ou seulement depuis un segment d’administration ?
3. Criticité de l’actif. Données personnelles, production, chaîne de paiement et annuaire d’authentification ne pèsent pas comme une machine de test isolée.
4. Probabilité d’exploitation. Un EPSS élevé, en valeur absolue ou en percentile selon le seuil que vous aurez calibré, fait monter la priorité d’un cran.
5. Sévérité technique. Le vecteur CVSS, lu métrique par métrique, précise les conditions d’exploitation et l’impact.
6. Mesures compensatoires. Fonction vulnérable désactivée, filtrage en amont, module concerné absent de votre installation.

En code, la logique tient en quelques lignes. Les seuils sont des points de départ à calibrer sur vos propres données :

def priorite(cve: dict, actif: dict) -> str:
    """cve: {'kev': bool, 'epss': float, 'cvss': float}
    actif: {'expose_internet': bool, 'critique': bool}"""
    if cve["kev"] and actif["expose_internet"]:
        return "P0 : immédiat"
    if cve["kev"] or (cve["epss"] >= 0.1 and actif["expose_internet"]):
        return "P1 : sous quelques jours"
    if actif["critique"] and cve["cvss"] >= 7.0:
        return "P2 : cycle de correctifs prioritaire"
    return "P3 : cycle normal"

Pour une démarche plus formalisée, le modèle SSVC (Stakeholder-Specific Vulnerability Categorization), conçu par le CERT/CC et adapté par la CISA, remplace le score par un arbre de décision. Ses critères portent notamment sur l’état d’exploitation, l’automatisabilité de l’attaque et l’impact, et ses sorties sont des actions : Track, Track*, Attend, Act.

L’angle mort des vulnérabilités sans CVE

CVSS, EPSS et KEV ne couvrent que ce qui porte un identifiant CVE. Une erreur de configuration, un contrôle d’accès défaillant dans votre propre application ou une interface d’administration exposée sans authentification n’ont pas de CVE. Ils n’apparaissent donc dans aucun de ces flux, alors qu’ils figurent parmi les portes d’entrée les plus courantes.

Pour ces défauts, seule une démonstration dans votre contexte réel établit l’exploitabilité ; un numéro de version ne suffit pas à l’inférer. Un constat accompagné de sa preuve se priorise beaucoup plus facilement. La note RZ-2026-001, Preuve avant alerte détaille cette approche. Quelle que soit la grille retenue, écrivez-la : une règle de priorisation documentée peut être discutée, auditée et corrigée, ce qui est impossible avec un tri implicite par note.