CVSS 4.0 expliqué : le guide complet de la notation de gravité des vulnérabilités en 2026

Peu d'acronymes de la sécurité ont autant voyagé que CVSS. Le Common Vulnerability Scoring System apparaît dans les fiches CVE, les avis des éditeurs, les scanners de vulnérabilités, les tableaux de bord SIEM et les rapports de risque présentés en comité de direction. En 2026, la plupart des programmes matures sont passés — ou sont en train de passer — du CVSS 3.1 au CVSS 4.0, une révision qui redéfinit la façon dont les défenseurs raisonnent sur la gravité des vulnérabilités et sur les priorités. Ce guide parcourt le CVSS 4.0 de bout en bout : les métriques de base, les nouveaux groupes menace et supplémentaire, la manière dont la lecture environnementale modifie la notation, et comment traduire un résultat numérique en décisions de patch management défendables.

Pourquoi le CVSS compte pour les CVE et la gestion des vulnérabilités

Chaque entrée CVE (Common Vulnerabilities and Exposures) publiée est un artefact de coordination : un accord de l'industrie sur un identifiant unique attribué à une faille divulguée. Le CVSS est le langage associé, qui décrit à quel point cette faille est grave, de manière normalisée et indépendante des éditeurs. Sans CVSS, comparer une faille du noyau Linux à un contournement d'authentification applicatif web exigerait un récit ; avec le CVSS, les deux se résolvent sur la même échelle de 0 à 10, avec une chaîne de vecteur documentée.

Pour les équipes de sécurité, le CVSS permet trois choses à grande échelle : le triage (trier rapidement des milliers de constats), la communication (traduire entre l'ingénierie, la direction et les auditeurs) et l'automatisation (encoder des règles de priorité dans le ticketing, les garde-fous CI/CD et les outils de posture cloud). Mais le CVSS seul ne suffit pas. Le « S » signifie scoring system, pas decision system — et le CVSS 4.0 est explicite sur cette distinction, en encourageant les équipes à combiner le score de base avec des données de menace temporelles et le contexte environnemental.

La demande de recherche autour de CVSS 4.0 a fortement augmenté depuis sa finalisation, à mesure que les praticiens comparent le nouveau cadre au CVSS 3.1 et cherchent des repères clairs pour la migration. Comprendre les nuances dès maintenant est rentable pour le reporting de conformité, les questionnaires d'assurance cyber et les publications de confiance client, qui citent de plus en plus explicitement les vecteurs CVSS.

Les groupes de métriques du CVSS 4.0 en un coup d'œil

Le CVSS 4.0 organise l'information en quatre groupes de métriques complémentaires :

1. Métriques de base : caractéristiques intrinsèques de la vulnérabilité, qui ne varient ni dans le temps ni selon l'environnement.
2. Métriques de menace : informations sur l'exploitation réelle et la maturité, qui évoluent après la divulgation.
3. Métriques environnementales : surcharges reflétant le contexte propre à l'organisation qui déploie le produit.
4. Métriques supplémentaires : descripteurs additionnels (non intégrés au score) qui communiquent des nuances telles que l'impact sur la sécurité des personnes, l'effort de restauration et l'urgence de réponse.

Cette structure remplace la division « Base / Temporel / Environnemental » du CVSS 3.1 par une séparation plus nette entre ce que l'on sait de la faille et ce que l'on sait des attaquants et de votre environnement. Elle introduit également CVSS-BT (Base + Threat) et CVSS-BTE (Base + Threat + Environmental) comme variantes de notation canoniques au-delà du score de base brut, ce qui facilite l'indication de la couche de contexte prise en compte par un score donné.

Métriques de base : à quoi ressemble la vulnérabilité elle-même

Le groupe de base répond à la question : si un attaquant tente d'exploiter cette faille, quelle est la difficulté, et que se passe-t-il en cas de succès ? Le CVSS 4.0 conserve des dimensions familières tout en en affinant plusieurs.

• Attack Vector (AV) : Network, Adjacent, Local ou Physical. Décrit à quelle distance l'attaquant peut se trouver.
• Attack Complexity (AC) : Low ou High. « High » reflète désormais explicitement les obstacles maîtrisés par le défenseur, comme l'ASLR ou des configurations non par défaut.
• Attack Requirements (AT) : nouveauté de la 4.0. Capture les conditions hors du contrôle de l'attaquant, comme les fenêtres de course (race conditions) ou une topologie réseau particulière côté victime.
• Privileges Required (PR) : None, Low ou High. Essentiel pour distinguer les failles pré-authentification des failles post-authentification.
• User Interaction (UI) : None, Passive ou Active. Le CVSS 4.0 distingue les déclenchements automatiques de ceux qui exigent une action délibérée de l'utilisateur.
• Vulnerable System Impact (VC/VI/VA) : impact en confidentialité, intégrité et disponibilité sur le composant vulnérable.
• Subsequent System Impact (SC/SI/SA) : impact sur les systèmes en aval ou connectés — en pratique un remplacement plus précis de l'ancienne métrique Scope.

La séparation entre système vulnérable et système subséquent est l'un des changements les plus utiles en pratique. Dans le CVSS 3.1, la métrique binaire Scope écrasait souvent la nuance : soit une faille franchissait une frontière de confiance, soit non. Le CVSS 4.0 permet d'exprimer qu'une faille confinée dans un bac à sable a un impact élevé sur le composant isolé mais faible sur l'hôte — ou l'inverse. Cette précision est particulièrement précieuse pour les conteneurs, les hyperviseurs et les chaînes d'exploitation navigateur, où l'impact en aval est justement le but recherché.

Métriques de menace : intégrer la réalité de l'exploitation dans le score

Le CVSS 3.1 disposait d'un groupe Temporel, mais il était optionnel, rarement renseigné de façon cohérente et souvent ignoré par les scanners. Le CVSS 4.0 élève ce contexte au rang de groupe Threat dédié et renomme la métrique centrale :

• Exploit Maturity (E) : Not Defined, Attacked, POC ou Unreported. « Attacked » est le nouvel état à fort signal, indiquant une exploitation confirmée dans la nature.

Ce basculement compte pour la priorisation, car un score de base est un plafond, pas un indicateur de risque en temps réel. Une CVE avec un score de base de 9,1 mais aucune exploitation connue après un an ne se comporte pas comme une CVE de 7,8 apparue la semaine dernière dans les discussions entre affiliés ransomware. Alimenter votre chaîne de traitement avec les métriques de menace — via le catalogue Known Exploited Vulnerabilities (KEV) de la CISA, les probabilités EPSS, les bulletins de menace des éditeurs et le renseignement payant sur les exploits — est le moyen le plus propre pour que votre score CVSS-BT colle à la réalité.

Du point de vue du référencement et de la documentation, expliquer aux parties prenantes la différence entre score de base, score ajusté à la menace et score environnemental crée une valeur de contenu durable : les praticiens recherchent régulièrement ces comparaisons lorsqu'ils construisent ou auditent un programme.

Métriques environnementales : votre réseau n'est pas la machine de référence

Les métriques environnementales permettent aux défenseurs de modifier le score en fonction du déploiement réel d'un actif vulnérable. En 4.0, vous pouvez surcharger les métriques de base (par exemple, déclarer que dans votre déploiement une interaction utilisateur est requise parce qu'un WAF bloque les chemins d'exploitation directs) et appliquer des modificateurs d'importance d'actif pour la confidentialité, l'intégrité et la disponibilité.

Deux ajouts environnementaux sont particulièrement utiles :

• Modified Attack Requirements (MAT) et Modified Attack Vector (MAV) : utiles lorsque des mesures compensatoires (segmentation réseau, rebonds d'administration, service meshes) limitent l'accessibilité réelle de la faille.
• Exigences DIC (CR/IR/AR) : elles reflètent la classification des données ou la criticité d'un actif. Une faille à faible impact sur une base de données de santé contenant des données de patients peut malgré tout justifier un score environnemental élevé ; une faille à impact moyen sur un service de test sans état, non.

La notation environnementale est le moment où le CVSS cesse d'être un numéro de catalogue universel pour refléter votre risque réel. Les organisations qui sautent cette étape se retrouvent systématiquement à corriger les mauvaises 500 CVE chaque trimestre, pendant que l'exposition réelle dort tranquillement dans un recoin non noté de leur environnement.

Métriques supplémentaires : Safety, Automatable, Recovery et les autres

Le CVSS 4.0 introduit des métriques supplémentaires qui n'affectent pas le score numérique mais accompagnent la chaîne de vecteur pour la prise de décision en aval :

• Safety (S) : indique si l'exploitation pourrait causer des dommages physiques — crucial pour les technologies opérationnelles, les dispositifs médicaux, l'automobile et les systèmes de contrôle industriel.
• Automatable (AU) : l'exploitation peut-elle être scriptée contre des cibles à grande échelle.
• Recovery (R) : le système peut-il se rétablir automatiquement ou exige-t-il une restauration manuelle.
• Value Density (V) : une compromission unique procure-t-elle à l'attaquant une valeur concentrée ou diffuse.
• Vulnerability Response Effort (RE) : effort de remédiation attendu.
• Provider Urgency (U) : urgence communiquée par l'éditeur (Clear, Green, Amber, Red).

Les métriques supplémentaires permettent à votre processus interne d'encoder un contexte qui compte mais qui n'a pas sa place dans un indicateur de gravité universel. Par exemple, une vulnérabilité Automatable + Attacked peut déclencher immédiatement une chaîne de « balayage de détection à l'échelle de l'entreprise », même si le score n'est que de 6,5.

Du score CVSS 4.0 à la décision de risque

Un processus mature traduit les vecteurs CVSS en actions au moyen d'une grille reproductible. Une base de travail exploitable :

1. Ingérer le score de base de l'éditeur et stocker la chaîne de vecteur complète.
2. Enrichir avec les métriques de menace — présence au KEV, probabilité EPSS, disponibilité de code d'exploitation — pour calculer le CVSS-BT.
3. Appliquer les modificateurs environnementaux rattachés à l'inventaire des actifs : exposition Internet, classification des données, mesures compensatoires.
4. Évaluer les indicateurs supplémentaires, en escaladant les préoccupations Safety ou Automatable même lorsque le score numérique paraît modéré.
5. Associer le score CVSS-BTE final à un palier : urgence (correction sous 24–72 h), élevé (dans le SLA), planifié ou surveillance.

Documenter cette grille dans votre politique de gestion des vulnérabilités transforme des débats subjectifs de réunion en décisions déterministes qui passent bien l'audit. Cela donne aussi à la direction sécurité un levier clair pour communiquer les arbitrages : si le métier veut raccourcir les SLA, la grille met en évidence les effectifs et l'outillage qu'il faut faire évoluer pour le soutenir.

Le CVSS 4.0 dans le paysage plus large du threat intelligence

Aucun système de notation n'existe en vase clos. Les services de threat intelligence, les traqueurs de ransomware et les outils de réputation d'infrastructure comme isMalicious complètent le tableau en indiquant qui exploite une CVE et quelle infrastructure est utilisée. Même un score CVSS-BTE soigneusement calculé profite énormément des signaux opérationnels : domaines sous surveillance, adresses IP malveillantes et indicateurs de commande et contrôle qui révèlent si l'adversaire est déjà à votre porte.

Intégrer la priorisation basée sur le CVSS avec la télémétrie d'activité malveillante observée est une marque des opérations de sécurité modernes. Cela permet à un SOC de dire : « CVE-2026-xxxxx est notée 8.7 avec une maturité d'exploitation Attacked, affecte notre périmètre, et nous observons actuellement des connexions vers une infrastructure C2 connue de la famille qui l'exploite — escalade. » Cette phrase, rendue possible par le CVSS 4.0 plus l'enrichissement, c'est le son d'une bonne gestion des vulnérabilités.

Pièges courants lors de l'adoption du CVSS 4.0

Même les équipes qui basculent résolument vers le CVSS 4.0 butent sur des problèmes récurrents :

• Considérer le CVSS-B comme la réponse finale. Le score de base est délibérément dénué de contexte. Utilisez le CVSS-BT ou le CVSS-BTE pour la priorisation.
• Ignorer les métriques supplémentaires. Les indicateurs Safety et Automatable comptent parfois davantage que le chiffre affiché pour les environnements ICS et SaaS.
• Ne pas enregistrer les chaînes de vecteur. Stockez le vecteur complet, pas seulement le score numérique. Les audits et les recalculs exigent la donnée brute.
• Sous-estimer l'effort de migration. Les tableaux de bord, les SLA et les modèles de tickets codent souvent en dur les seuils CVSS 3.1 ; un déploiement de la 4.0 touche plus de systèmes qu'on ne l'imagine.
• Sur-ajuster au CVSS. Ce n'est qu'un signal. CVE + EPSS + KEV + modélisation interne des menaces restent indispensables.

CVSS, conformité et paysage réglementaire 2026

Les régulateurs et les assureurs cyber font de plus en plus référence à des seuils CVSS précis dans leurs attentes. Des référentiels comme le NIST SSDF, les annexes de l'ISO 27001 et les règles sectorielles pour la santé, la finance et les infrastructures critiques s'appuient désormais sur un langage de SLA fondé sur le CVSS. La couche environnementale plus riche du CVSS 4.0 aide justement les défenseurs ici : vous pouvez démontrer aux auditeurs que votre priorisation tient compte de la sensibilité des données et des mesures compensatoires, et pas seulement des chiffres de gravité bruts sortis d'un scanner.

Si votre organisation publie des politiques de divulgation de vulnérabilités accessibles au public, les mettre à jour pour référencer les vecteurs CVSS 4.0 signale votre maturité aux chercheurs en sécurité, aux clients et aux équipes achats qui évaluent votre posture. C'est un petit changement à l'impact mesurable en matière de confiance.

Conclusion

Le CVSS 4.0 n'est pas un simple changement de version cosmétique : c'est un cadre plus expressif et plus honnête pour décrire les vulnérabilités. En séparant ce qu'est la faille, ce que font les attaquants et à quoi ressemble votre environnement, il fournit la structure dont les programmes modernes de gestion des vulnérabilités ont besoin pour percer le bruit des scanners. Associez-le au threat intelligence, aux probabilités EPSS, à l'appartenance au KEV et au contexte au niveau des actifs fourni par des outils comme isMalicious, et vous obtenez un moteur de priorisation qui reflète la réalité plutôt que le cérémonial.

Investissez dès maintenant dans la plomberie : mettez à jour les chaînes d'ingestion pour analyser les vecteurs CVSS 4.0, alignez les SLA internes sur le CVSS-BTE plutôt que sur le CVSS-B, et formez les analystes aux nouvelles métriques supplémentaires. Les organisations qui intègrent tôt le CVSS 4.0 passeront la prochaine décennie à corriger moins — parce qu'elles corrigeront ce qui compte vraiment.