CVSS - Scoring vulnérabilités v3.1 vs v4.0 en 2026

Le CVSS (Common Vulnerability Scoring System) est le standard ouvert maintenu par FIRST.org pour scorer la sévérité technique d'une vulnérabilité, sur une échelle de 0.0 à 10.0. Quatre versions ont structuré son histoire : v1 (2005), v2 (2007), v3.0 (2015), v3.1 (juin 2019), et la dernière v4.0 publiée le 1er novembre 2023. En 2026, l'écosystème vit une transition partielle : le NVD et la majorité des CNAs scorent encore en v3.1, tandis que Red Hat, FIRST CERT, et plusieurs éditeurs critiques publient désormais en double v3.1 + v4.0, environ 25 à 30 % des CVE 2025 ont un score v4.0 publié. Comprendre la décomposition Base / Threat / Environmental / Supplemental, les MacroVectors v4.0, le piège Scope vs Vulnerable/Subsequent, et la différence entre CVSS et risque réel est fondamental pour ne pas piloter le vulnerability management dans le brouillard.

Pour le contexte adjacent : voir CVE - Définition, format, processus qui décrit l'identifiant et l'écosystème dans lequel le score CVSS s'applique, et IOC - Indicateurs de compromission pour la couche détection en aval.

1. CVSS, FIRST.org et l'historique des versions

CVSS n'est pas une norme ISO ni une RFC : c'est un standard maintenu par le FIRST (Forum of Incident Response and Security Teams), une organisation à but non lucratif qui anime depuis 1990 la coordination internationale des CSIRT. Le SIG CVSS (Special Interest Group) regroupe des contributeurs MITRE, NIST, Cisco, Red Hat, IBM, Oracle, JPCERT/CC, et plus de 30 autres organisations. Chaque version est publiée sous licence ouverte et accompagnée d'une specification document, d'un user guide et d'un examples document.

Spec officielle v4.0 : https://www.first.org/cvss/v4-0/specification-document. Le calculator officiel est sur https://www.first.org/cvss/calculator/4.0.

2. Décomposition Base, Threat, Environmental, Supplemental

CVSS s'organise en groupes de métriques complémentaires. Comprendre quel groupe répond à quelle question est le mental model essentiel.

Les groupes Threat et Environmental sont systématiquement sous-utilisés dans la pratique. La majorité des équipes consomment uniquement le score Base publié au record CVE. C'est une perte d'information importante : le score CVSS-BT (Base + Threat) baisse typiquement de 0.5 à 1.5 points quand un patch officiel existe et que la maturité de l'exploit reste à Proof of Concept, différentiel qui change la décision de gating.

3. Métriques Base v3.1 et v4.0 - le tableau de référence

Métriques Base v3.1 (qui restent majoritaires en 2026) :

Métriques Base v4.0 - changements clés :

Vector string v4.0 type : 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. Le format est strict : chaque métrique doit apparaître dans l'ordre canonique, et toute valeur non-N/A doit être explicite (pas d'élision).

4. Les MacroVectors v4.0 - rupture algorithmique

Le changement le plus profond entre v3.1 et v4.0 n'est pas la liste de métriques, c'est la méthode de calcul du score Base. CVSS v3.1 utilise une formule continue avec arrondis spéciaux (roundUp non standard documenté en spec §5.1). CVSS v4.0 utilise des MacroVectors : huit dimensions catégorielles qui projettent la combinaison des métriques Base/Threat/Environmental dans un espace fini d'environ 270+ équivalences, avec une lookup table des scores correspondants.

Conséquences pratiques :

1. Deux vulnérabilités au vector string différent peuvent recevoir le même score CVSS-B v4.0 si elles appartiennent au même MacroVector, phénomène inexistant en v3.1 où chaque combinaison produisait un score quasi unique.
2. La transition v3.1 → v4.0 ne donne pas des scores comparables 1:1. La spec v4.0 §1.5 indique explicitement qu'il ne faut pas comparer un CVSS v3.1 et un CVSS v4.0 d'un même CVE.
3. Recoder l'algo à la main est devenu encore plus risqué qu'en v3.1. Utiliser une lib certifiée FIRST (lib Python cvss v3.x supporte v4) ou le calculator officiel.

5. Plages de sévérité et seuils de décision

Plages officielles partagées par v3.x et v4.0 :

Ces seuils sont conventionnels, pas réglementaires. Beaucoup d'organisations matures ont calibré leurs propres seuils : par exemple DORA (Digital Operational Resilience Act, applicable aux acteurs financiers UE depuis le 17 janvier 2025) impose à plusieurs entreprises financières de tracer chaque vulnérabilité ≥ 7.0 avec un SLA de remédiation explicite. NIST SP 800-40r4 (Guide to Enterprise Patch Management Planning, avril 2022) recommande de combiner CVSS avec la valeur de l'actif et l'exposition réseau pour fixer les SLA.

Position tranchée : aligner aveuglément le SLA de remédiation sur la plage CVSS produit du bruit. Une vulnérabilité 9.8 sur un service interne air-gappé n'a pas le même budget de réponse qu'une 7.4 sur une API exposée à Internet et déjà KEV-listed. Le scoring CVSS Base est un input au triage, pas la décision finale.

6. CVSS, EPSS, CISA KEV - la synthèse opérationnelle

CVSS répond à la question « à quel point cette vulnérabilité est-elle techniquement grave ? ». Deux autres signaux complètent l'image en 2026 :

Combinaison opérationnelle pragmatique :

Priorité = f(CVSS-BT, EPSS, KEV, ExpositionReseau, ValeurActif)
 
Top priority = (KEV present) OR (CVSS-BT >= 9.0 AND EPSS >= 0.5)
High         = CVSS-BT >= 7.0 AND (EPSS >= 0.3 OR ExposureFacing)
Medium       = CVSS-BT >= 4.0 AND (Patch dispo)
Low / defer  = reste

Cette grille est plus utile qu'un seuil CVSS unique. Elle correspond à la pratique observée chez les équipes vulnerability management matures (banque, e-commerce grand volume, opérateurs cloud), documentée notamment dans le rapport Verizon DBIR 2024 (section vulnerability exploitation) et dans plusieurs publications SANS 2024-2025.

7. Calcul pratique - lib Python et scripts

Installation et usage de la lib officielle Python :

pip install cvss

from cvss import CVSS3, CVSS4
 
# Score CVSS v3.1 - Log4Shell (CVE-2021-44228)
v31 = CVSS3('CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H')
print(v31.base_score)        # 10.0
print(v31.severities())       # ('Critical', None, None)
print(v31.clean_vector())     # 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H'
 
# Score CVSS v4.0 équivalent
v40 = CVSS4(
    'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/'
    'VC:H/VI:H/VA:H/SC:H/SI:H/SA:H'
)
print(v40.base_score)        # 10.0
print(v40.severity)          # 'CRITICAL'
 
# Avec Threat metrics (Exploit Maturity = Attacked, Patch officiel disponible)
v40_bt = CVSS4(
    'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/'
    'VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:A'
)
print(v40_bt.base_score)     # 10.0 (Threat n'abaisse pas si Attacked)

Script bash de bulk-scoring sur un export NVD ou cvelistV5 :

#!/usr/bin/env bash
# Recalcule les scores v3.1 et v4.0 pour tous les CVE 2025 Critical
# Utile en audit pour vérifier la cohérence CVSS publié vs recalculé.
 
set -euo pipefail
INPUT_DIR="cvelistV5/cves/2025"
 
find "$INPUT_DIR" -name "CVE-*.json" | while read -r f; do
  cve_id=$(jq -r '.cveMetadata.cveId' "$f")
  v31_vec=$(jq -r '.containers.cna.metrics[]?.cvssV3_1.vectorString // empty' "$f" | head -1)
  v40_vec=$(jq -r '.containers.cna.metrics[]?.cvssV4_0.vectorString // empty' "$f" | head -1)
 
  if [[ -n "$v31_vec" ]]; then
    score_v31=$(python -c "from cvss import CVSS3; print(CVSS3('$v31_vec').base_score)")
  else
    score_v31="-"
  fi
  if [[ -n "$v40_vec" ]]; then
    score_v40=$(python -c "from cvss import CVSS4; print(CVSS4('$v40_vec').base_score)")
  else
    score_v40="-"
  fi
 
  printf "%s\t%s\t%s\n" "$cve_id" "$score_v31" "$score_v40"
done | tee scoring_audit_2025.tsv

Ce script produit un TSV avec, pour chaque CVE 2025, son score Base v3.1 et v4.0 si publiés. Permet de mesurer en interne l'écart entre les deux versions sur ton scope, et d'identifier les CVE où la transition modifierait le triage.

8. Erreurs fréquentes et anti-patterns CVSS

9. Adoption v4.0 et ce qui change vraiment en pipeline

État de l'adoption observé en 2026 :

Implication concrète : un pipeline qui décide uniquement à partir du score Base v3.1 reste viable en 2026 pour la majorité des CVE, mais commence à manquer de signal sur les CVE scorés exclusivement v4.0 (cas Red Hat principalement). Une stratégie défensive consiste à lire les deux versions dans le scanner et appliquer la règle « score le plus élevé entre v3.1 et v4.0 ». Inversement, certaines équipes choisissent v4.0 comme source de référence dès qu'il est disponible parce que la précision MacroVector capture mieux le différentiel Vulnerable/Subsequent.

Position tranchée : forcer une migration v3.1 → v4.0 brutale en 2026 dans une organisation qui n'est pas mature CVSS est inutile et coûteux. Mieux vaut rester en v3.1 par défaut et lire v4.0 quand publié, en attendant que le NVD termine son rattrapage et que les scanners SCA stabilisent leur support v4.0. Les bénéfices marginaux du nouveau scoring sont réels mais ne justifient pas une refonte du pipeline avant 2027.

10. Cas concrets - vulnérabilités marquantes et leur scoring

Le cas Heartbleed (CVE-2014-0160) avec CVSS v3.1 = 7.5 est éclairant : le score capturait correctement la confidentialité (impact sur les clés privées et sessions), mais le risque réel observé en exploitation a été largement supérieur à ce que la note 7.5 suggère. C'est un exemple de la limite intrinsèque du Base score isolé, il faut combiner avec EPSS, KEV et exposition.

11. Pour aller plus loin

• CVE - Définition, format, processus, l'identifiant auquel le score CVSS est attaché.
• IOC - Indicateurs de compromission, pour la couche détection en aval.
• TTP - Tactics, Techniques, Procedures, pour le mapping MITRE ATT&CK des techniques exploitant ces vulnérabilités.
• Bootcamp DevSecOps, formation 12 semaines couvrant SCA, scoring composite, gating CI/CD.
• Hub catégorie Glossaire cyber, autres définitions de référence Zeroday.
• Spec officielle FIRST CVSS v4.0 : https://www.first.org/cvss/v4-0/specification-document.
• Calculator FIRST v4.0 : https://www.first.org/cvss/calculator/4.0.
• FIRST EPSS (probabilité d'exploitation) : https://www.first.org/epss/.
• CISA KEV catalog : https://www.cisa.gov/known-exploited-vulnerabilities-catalog.
• NIST SP 800-40 r4 (Patch Management Planning) : https://csrc.nist.gov/pubs/sp/800/40/r4/final.

12. Points clés à retenir

• CVSS = sévérité technique 0.0-10.0, pas le risque réel. Risque = Sévérité × Probabilité × Valeur de l'actif.
• v4.0 publiée le 1er novembre 2023 par FIRST.org. Adoption 2026 ~25-30 % des CVE 2025, v3.1 reste majoritaire.
• Quatre groupes : Base (intrinsèque, immutable), Threat / Temporal (état exploit + patch), Environmental (contexte org), Supplemental (v4 only, ne change pas le score).
• Nomenclature v4.0 : CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE, l'utiliser pour éviter l'ambiguïté.
• Changement majeur v4.0 : retrait de Scope, split Vulnerable/Subsequent System (VC/VI/VA + SC/SI/SA), ajout Attack Requirements (AT), Supplemental Metrics (Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency).
• MacroVectors v4.0 : ~270 équivalences, lookup table, scores non comparables 1:1 avec v3.1 (interdit explicitement par spec §1.5).
• CNA score vs NVD score : 15-20 % de divergence avec écart moyen 1.0-2.0 points. Documenter la source choisie.
• Plages : 0.0 None, 0.1-3.9 Low, 4.0-6.9 Medium, 7.0-8.9 High, 9.0-10.0 Critical. Conventionnelles, pas réglementaires.
• Anti-pattern n°1 : utiliser Base seul en gating CI. Préférer CVSS-BT × EPSS × KEV × exposition × valeur.
• Lib Python cvss : référence pour calcul programmé en v3.1 et v4.0. pip install cvss.
• Safety metric (v4.0 Supplemental) : critique pour OT, ICS, médical, automotive, escalader systématiquement même si Base est moyen.
• Recommandation 2026 : rester en v3.1 par défaut, lire v4.0 quand disponible, attendre stabilisation NVD et scanners avant migration totale.