Score CVSS : comprendre le calcul, le vecteur et
ses limites

Un score CVSS, c'est huit décisions binaires ou presque, écrasées en un seul nombre entre 0.0 et 10.0. La compression est brutale, et elle cache autant qu'elle informe. Prenez trois failles réelles : Log4Shell note 10.0, la RCE pré-authentifiée du cœur de WordPress notée 9.8, et PwnKit, l'escalade de privilèges de pkexec, notée 7.8. Trois nombres proches, trois situations qui n'ont presque rien à voir. Pour les départager, il faut ouvrir le capot.

Cet article décompose le vecteur CVSS métrique par métrique, montre la formule officielle du score de base en v3.1, l'implémente dans un calculateur interactif que vous manipulez plus bas, puis décortique trois CVE vérifiées. On finit par la partie que tout le monde saute : pourquoi le score, seul, ne suffit jamais à décider quoi corriger en premier.

CVSS, ce que le score mesure vraiment

CVSS veut dire Common Vulnerability Scoring System. C'est un standard ouvert maintenu par le FIRST (Forum of Incident Response and Security Teams), et c'est la note que vous voyez sur chaque fiche NVD, dans les avis d'éditeurs et dans la sortie de votre scanner. La notation CVSS se décline en trois groupes de métriques : le groupe de base, qui décrit la gravité intrinsèque et immuable d'une faille, un groupe temporel (rebaptisé menace en v4.0) qui suit l'évolution de l'exploit, et un groupe environnemental qui pondère selon votre déploiement.

Dans la quasi-totalité des usages, quand on dit "le score CVSS d'une CVE", on parle du score de base. C'est celui que publie la NVD, celui qui alimente les tableaux de bord, et le seul qui ne dépend pas de votre contexte. Il se calcule à partir d'un vecteur : une chaîne compacte du type CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Le vecteur est la vérité, le score n'en est que le résumé. Deux failles au même score peuvent avoir des vecteurs très différents, et c'est là que se joue la compréhension.

Le vecteur CVSS v3.1, métrique par métrique

Le score de base v3.1 se répartit en deux sous-scores : l'exploitabilité (à quel point la faille est facile à déclencher) et l'impact (ce qu'on obtient une fois qu'elle est déclenchée). Quatre métriques nourrissent l'exploitabilité, trois l'impact, et une huitième, le Scope, articule les deux. Voici les huit, avec les poids exacts de la table 16 de la spécification.

Le Scope mérite un arrêt, parce que c'est la métrique la plus mal comprise et celle qui fait basculer un score. Scope Unchanged : l'impact reste dans le périmètre d'autorité du composant touché. Scope Changed : l'exploitation déborde, comme une évasion de conteneur qui compromet l'hôte, ou une injection dans un composant qui pilote un autre système. Un Scope changé relève les poids de PR et applique un facteur 1.08 au total, ce qui permet à une faille d'atteindre 10.0. Sans lui, le plafond effectif d'un vecteur classique tourne autour de 9.8.

Comment le score CVSS v3.1 est calculé (la formule)

Contrairement à ce que laisse croire l'étiquette "score", ce n'est pas une moyenne. C'est une suite de multiplications définie mot pour mot dans la spécification FIRST v3.1. Trois étapes : un sous-score d'impact (ISS), un sous-score d'exploitabilité, puis leur combinaison avec un arrondi particulier.

# Sous-score d'impact
ISS = 1 - [ (1 - C) × (1 - I) × (1 - A) ]

# Impact, selon le Scope
Impact(S:U) = 6.42 × ISS
Impact(S:C) = 7.52 × (ISS - 0.029) - 3.25 × (ISS - 0.02)^15

# Exploitabilité
Exploitability = 8.22 × AV × AC × PR × UI

# Score de base
BaseScore(S:U) = Roundup( min(Impact + Exploitability, 10) )
BaseScore(S:C) = Roundup( min(1.08 × (Impact + Exploitability), 10) )
# Roundup = le plus petit nombre à 1 décimale >= à l'entrée

Le Roundup n'est pas un arrondi standard : il arrondit toujours vers le haut à la première décimale. C'est pour ça qu'un calcul intermédiaire de 7.7077 ressort à 7.8 et non à 7.7. Déroulons PwnKit à la main, vecteur AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. ISS vaut 1 - (1 - 0.56)³ = 0.9148. L'impact en Scope Unchanged vaut 6.42 × 0.9148 = 5.8731. L'exploitabilité vaut 8.22 × 0.55 × 0.77 × 0.62 × 0.85 = 1.8346. La somme fait 7.7077, on arrondit vers le haut : 7.8. La note tombe pile sur ce que publie la NVD.

Plutôt que de vous croire sur parole, manipulez-le. Le calculateur ci-dessous implémente exactement ces équations, poids compris, et recalcule le score et le vecteur à chaque clic, en local. Il est pré-rempli sur la RCE WordPress à 9.8 : basculez S sur Changed et regardez le score franchir 10.0, ou passez AV de Network à Local pour voir l'exploitabilité s'effondrer.

Trois CVE décomposées vecteur par vecteur

Rien ne vaut de vrais vecteurs pour sentir ce que le score cache. Voici trois CVE au score de base élevé, chacune vérifiée sur sa fiche NVD, avec un profil de vecteur radicalement différent. Le tableau donne le vecteur, la ligne de prose qui suit explique ce que chaque note dit et ne dit pas.

Log4Shell et la RCE WordPress partagent le même sous-score d'impact, et pourtant l'une note 10.0 et l'autre 9.8. La seule différence tient dans une lettre : S:Ccontre S:U. Log4Shell débordait du composant de logging vers l'ensemble du processus Java via une résolution JNDI, ce que le Scope Changed traduit numériquement. La RCE de WordPress, décrite par sa fiche NVD comme un défaut de routage de l'API REST combiné à une injection SQL, reste dans son périmètre applicatif. On approfondit sa mécanique dans l'analyse de la RCE pré-auth qui touche le cœur de WordPress.

PwnKit raconte l'histoire inverse. Impact maximal sur les trois axes, comme les deux autres, mais un vecteur d'attaque Local et des privilèges Low requis : il faut déjà un compte sur la machine pour la déclencher. Ces deux métriques divisent l'exploitabilité par plus de deux, et le score tombe à 7.8, dans la bande High. Un scanner qui trie par note descendante l'affichera loin derrière une pile de failles Critical. On verra pourquoi c'est une erreur de le reléguer.

CVSS v4.0 : la fin de la formule unique

Publiée par le FIRST, la version 4.0 change la donne sur un point structurant : il n'y a plus de formule arithmétique fermée. Là où v3.1 se calcule au crayon, v4.0 repose sur un MacroVector et une table de correspondance. Les vecteurs sont regroupés en classes d'équivalence (six EQ), chaque classe pointe vers un score de référence, et un vecteur donné est interpolé selon sa distance de sévérité à l'intérieur de sa classe. Impossible de reproduire ça avec quatre multiplications, d'où le renvoi au calculateur officiel plus haut : c'est la seule implémentation qui embarque la table complète.

Les métriques de base bougent aussi. Le Scope disparaît en tant que tel et se scinde en deux jeux d'impact : le système vulnérable (VC/VI/VA) et le système suivant, en aval (SC/SI/SA). Une nouvelle métrique Attack Requirements (AT) capte les conditions de déploiement, comme une course à gagner. Et User Interaction passe de deux à trois valeurs : None, Passive, Active. Le tout se lit à travers une nomenclature qui indique enfin quels groupes de métriques ont réellement servi au score.

CVSS-B     Base seule            (le score public d'une CVE)
CVSS-BT    Base + Threat         (maturité de l'exploit prise en compte)
CVSS-BE    Base + Environmental  (pondéré pour VOTRE déploiement)
CVSS-BTE   Base + Threat + Env.  (le score le plus complet)

Les bandes qualitatives, elles, ne changent pas d'une version à l'autre : None à 0.0, Low de 0.1 à 3.9, Medium de 4.0 à 6.9, High de 7.0 à 8.9, Critical de 9.0 à 10.0. Un 8.9 reste un cheveu sous le rouge, un 9.0 bascule dedans, et cette frontière arbitraire pilote plus de décisions de patch qu'elle ne le devrait.

En pratique, v3.1 reste la version que vous croiserez le plus. La plupart des fiches, des scanners et des politiques internes raisonnent encore en v3.1, et de nombreuses CVE portent les deux vecteurs en parallèle, l'un du fournisseur, l'autre de la NVD. Savoir lire les deux notations n'est donc pas optionnel : une même faille peut afficher un score v3.1 et un score v4.0 qui ne tombent pas sur la même valeur, ni parfois sur la même bande de sévérité, sans que l'une des deux soit fausse. Elles ne mesurent simplement pas tout à fait la même chose.

Pourquoi le score CVSS ne suffit pas à prioriser

Voilà le vrai sujet. Le score de base mesure une gravité intrinsèque, volontairement détachée de tout contexte. C'est une qualité pour comparer des failles dans l'absolu, et un défaut pour décider quoi corriger lundi matin. Trier un backlog par CVSS décroissant, c'est traiter une faille Critical sur un serveur interne éteint avant une faille High sur un actif exposé et déjà attaqué. Deux signaux corrigent ce biais, et aucun des deux n'est dans le score.

Le premier est l'EPSS (Exploit Prediction Scoring System), également maintenu par le FIRST : une probabilité, mise à jour chaque jour, qu'une CVE soit exploitée dans les trente prochains jours. Une même note CVSS peut couvrir un EPSS de 0,1 % et un EPSS de 95 %. Le second est le catalogue CISA KEV (Known Exploited Vulnerabilities), la liste des failles pour lesquelles une exploitation en conditions réelles est prouvée. PwnKit, notre 7.8, y figure depuis 2022 : moins gravement noté que n'importe quel 9.8, mais massivement exploité, trivial à automatiser une fois un accès obtenu. Le score le range en second, la réalité le range en premier.

Le troisième signal, celui que ni CVSS ni EPSS ne portent, c'est votre exposition. Une CVE ne compte que si l'actif qui la porte est joignable et vous appartient. C'est tout l'objet d'une surveillance de surface d'attaque externe : corréler chaque CVE à un actif réellement exposé sur Internet, par bannière et version, et remonter en priorité ce qui est à la fois grave, exploité et atteignable. Ce croisement est aussi le cœur d'un programme EASM, là où un scanner de vulnérabilité classique s'arrête souvent à la note brute.

Concrètement, le score CVSS entre comme un ingrédient dans une gestion des vulnérabilités qui le dépasse : il alimente la sévérité de départ, l'EPSS et le KEV ajustent l'urgence, l'exposition tranche, et le tout se traduit en échéances dans un plan de remédiation puis en patch management discipliné. Le score n'est pas la décision, c'est une de ses entrées.

À retenir

• Le vecteur prime sur le score. Deux failles à 9.8 peuvent avoir des profils opposés. Lisez toujours AV/AC/PR/UI/S/C/I/A, pas seulement le nombre.
• Le score v3.1 est une formule fermée. Impact via l'ISS, exploitabilité via un produit de poids, combinaison et arrondi vers le haut. Le Scope Changed est ce qui débloque le 10.0.
• CVSS v4.0 n'a plus de formule. MacroVector et table de correspondance, Scope éclaté en VC/VI/VA et SC/SI/SA, nouvelle métrique AT, et une nomenclature B / BT / BE / BTE qui dit ce que le score contient.
• Le score de base ignore le contexte. Il mesure la gravité intrinsèque, pas la probabilité d'exploitation ni votre exposition.
• Prioriser, c'est croiser. CVSS pour la gravité, EPSS et CISA KEV pour la menace, la surface d'attaque pour l'exposition. Une High exploitée et exposée passe avant une Critical inatteignable.

Le score CVSS est un point de départ honnête et un point d'arrivée trompeur. Si vous voulez transformer une liste de CVE en file de correctifs qui a du sens, il faut le confronter à ce qui est réellement joignable chez vous : c'est exactement ce que fait la surveillance de surface d'attaque externe d'own2pwn, qui rapproche chaque vulnérabilité de l'actif exposé qui la porte et priorise par exploitabilité. Pour un regard humain sur les failles que la note sous-estime, un pentest automatisé complète le tableau. Pour en discuter, il suffit de prendre contact.

Questions fréquentes sur le score CVSS