Le CVSS n'est pas qu'un score, c'est un langage puissant pour qui sait le lire. À condition de lui demander ce qu’il sait faire et pas davantage.

Dans ce guide, nous prenons un vecteur CVSS v4 comme exemple. Nous verrons comment le lire, pourquoi son score Base ne raconte qu’une partie de l’histoire, puis comment passer du chiffre à une décision de remédiation.

Qu’est-ce que le CVSS ?

Le Common Vulnerability Scoring System (CVSS) est un cadre de notation maintenu par FIRST. Il décrit les caractéristiques techniques d’une vulnérabilité au moyen d’un vecteur, auquel peut correspondre un score de 0 à 10.

Une distinction utile dès le départ :

CVE (Common Vulnerabilities and Exposures) est un identifiant de vulnérabilité ;
CVSS est une manière d’en décrire et d’en noter la sévérité.

Le CVSS donne aux équipes un langage commun. Quand on lit « attaque par le réseau, sans privilèges, sans interaction utilisateur », on apprend quelque chose de plus précis qu’avec un simple « 9,5 ».

En revanche, le score Base ne sait pas, à lui seul, si votre produit est exposé sur Internet, si un actif est essentiel à votre activité, ni si une attaque est observée. C’est pour cela qu'il faut se méfier des procédures du type « tout ce qui dépasse le score 9 passe avant le reste ».

Les groupes de métriques du CVSS v4

Un vecteur CVSS (4.O ou versions précédentes) est constitué de métriques qualitatives réparties en 3 groupes :

Base : les caractéristiques intrinsèques à la vulnérabilité comme l'impact sur le composant vulnérable, la nécessité ou non d'une interaction de l'attaquant avec l'utilisateur, etc. ;
Threat ou Temporal : les métriques liées au contexte de menace comme la présence de code d'exploitation publics ;
Environmental : les métriques liées au contexte dans lequel va se manifester l'exploitation comme les attentes de sécurité d'un actif ou son positionnement dans le système d'information.

Les métriques Threat et Environmental nécessitent donc des informations complémentaires qui sortent du simple cadre technique de la vulnérabilité. Elles ne sont à ce titre presque jamais renseignées dans des référentiels publics.

Ainsi, en utilisant le vecteur et le score tels qu'ils sont diffusés, on manque des parties importantes dans le scoring.

Pour bien comprendre les enjeux, examinons les trois groupes un à un.

Base : ce que décrit la vulnérabilité

Les métriques Base décrivent notamment les conditions d’attaque et les impacts possibles du strict point de vue du système vulnérable.

Côté attaque :

AV — Attack Vector : par quel chemin l’attaque peut être menée.
AC — Attack Complexity : la complexité de l’attaque, notamment vis-à-vis de contremesures de sécurité natives.
AT — Attack Requirements : l’existence de conditions préalables à réunir (une configuration particulière par exemple).
PR — Privileges Required : les privilèges nécessaires à la conduite de l'exploitation.
UI — User Interaction : la nécessité d’une action de l’utilisateur.

Côté impacts, le CVSS v4 distingue les effets sur le système vulnérable (VC, VI, VA) et sur les systèmes subséquents (SC, SI, SA). Les lettres C, I et A renvoient à la confidentialité, à l’intégrité et à la disponibilité.

Cette séparation est utile : compromettre un équipement peut aussi avoir des conséquences sur d’autres systèmes. Le vecteur permet de le dire explicitement.

Les métriques de base sont toujours renseignées dans un vecteur CVSS.

Threat : ce que l’on sait de l’exploitation

Le groupe Threat, qui prend la place du groupe Temporal des versions précédentes, sert à tenir compte de la maturité de l’exploitation, notamment avec la métrique E (Exploit Maturity).

C’est une information d’une autre nature que les métriques Base. Une vulnérabilité ne change pas forcément de caractéristiques techniques parce qu’un exploit apparaît. Ce qui change, c’est l'appréciation de la menace.

Ce groupe de métriques peut changer dans le temps (les métriques Base ne changent pas en principe) en fonction du niveau de menace et plus particulièrement l'existence d'attaques ou la présence d'un code d'exploitation de la vulnérabilité.

Environmental : ce qui est vrai chez vous

Les métriques Environmental permettent d’ajuster l’évaluation au contexte d’une organisation : importance de la confidentialité, de l’intégrité ou de la disponibilité, et caractéristiques de l’environnement concerné.

C’est là qu’il faut résister à la tentation de copier le chiffre d’un autre.

Une même vulnérabilité peut toucher, chez l’un, un équipement exposé qui porte un service essentiel ; chez l’autre, un système isolé ou dont l’usage est différent. Le vecteur Base est commun. Le contexte dans lequel la vulnérabilité se manifeste ne l’est pas.

Les métriques Environmental permettent à la fois d'ajuster directement les métriques de base en fonction du contexte mais aussi de définir les attentes en matière de sécurité. Ce dernier point permet tout particulièrement de définir la criticité effective du système pour l'organisation qui l'opère.

Lire un vecteur CVSS v4 en pratique

Prenons le vecteur fourni pour CVE-2026-88771 :

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Il se lit ainsi :

AV:N : l’attaque passe par le réseau.
AC:L : la complexité d'attaque est faible.
AT:P : une condition préalable doit être réunie.
PR:N : aucun privilège n’est nécessaire.
UI:N : aucune interaction d’un utilisateur n’est nécessaire.
VC:H/VI:H/VA:H : les impacts potentiels sur la confidentialité, l’intégrité et la disponibilité du système vulnérable sont élevés.
SC:H/SI:H/SA:H : ces trois impacts potentiels sont également élevés pour les systèmes subséquents.

Avec AV:N, PR:N et UI:N, on pourrait lire : « C’est accessible par le réseau, donc c’est immédiatement exploitable partout. » Le vecteur dit autre chose. Il précise qu’une condition préalable intervient dans la réussite de l’attaque.

Cela ne rend pas la vulnérabilité bénigne. Cela signifie qu’avant de décider, il faut comprendre quelle est cette condition et si elle est réunie dans notre environnement. Le vecteur ne remplace pas la lecture de l’avis technique.

Même prudence avec le score : deux vulnérabilités très sévères peuvent appeler des traitements différents. L’une peut être activement exploitée sur un actif exposé ; l’autre, présente uniquement sur un système non concerné par les conditions d’attaque. Le CVSS aide à mesurer la sévérité, pas la probabilité que la menace se manifeste.

Base, Threat et Environmental : trois niveaux à ne pas mélanger

Le vecteur ci-dessus contient seulement des métriques Base. On l'a évoqué plus tôt, il manque des considérations importantes pour comprendre le risque en tant que tel.

Bien que le CVSS soit un score de criticité, il intègre des facteurs de risque tels que la menace. Pour la CVE-2026-88771, le vecteur ci-dessus pourrait devenir :

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:A.

Cet ajout indique que la vulnérabilité est activement exploitée.

À partir de ces éléments, on peut partir sur un scénario de travail pour déterminer les métriques suivantes spécifiquement pour notre organisation :

Comment exposons-nous Citrix Netscaler ou ADC ?
Quelles sont nos exigences de sécurité pour le système exécutant l'un des produits vulnérables ? Y-a-t-il des données sensibles accessibles via ce système ? Ce système doit-il rester absolument disponible pour nos opérations métier ?

Faire du CVSS le début du triage, pas sa conclusion

On n'a pas parlé du score CVSS dans l'exemple ci-dessus. Le vecteur nous en a beaucoup dit et on y comprend une grande criticité dans le détail avec tous les éléments à notre disposition.

On a ici un CVSS Base à 9.5.

On a donc un score critique. Mais comme plus de 50% des vulnérabilités publiées dans le système CVE obtiennent un niveau haut ou critique, cette vulnérabilité ne se distingue pas du bruit.

Si l’équipe traite mécaniquement tous les scores supérieurs à 9 avant d’examiner les signaux d’exploitation et son parc, elle risque de consacrer ses trois jours à une file très bruyante. Pendant qu’un autre problème, tel que celui de notre exemple, mérite une réponse immédiate.

Au final, les bonnes questions à se poser dans le processus de triage vont au-delà de la note de criticité et sont les suivantes.

1. Que décrit exactement le score ?

On l'a vu, le score à lui seul est très réducteur. Il faut lire le vecteur, pas seulement la note. Il est nécessaire d'avoir les métriques pour prendre une décision éclairée.

2. Que sait-on de l’exploitation ?

Chercher des éléments vérifiables : avis fournisseur, exploitation observée, présence dans le KEV (Known Exploited Vulnerabilities), renseignement sur la menace. L'EPSS peut compléter ce tableau en estimant la probabilité d’exploitation selon son propre modèle.

3. Sommes-nous réellement concernés ?

Confirmer les versions et configurations touchées. Puis regarder l’exposition de l’actif et son rôle dans le système d’information. Un inventaire incomplet rend même le meilleur score difficile à utiliser.

4. Quelle décision prend-on, et pour quand ?

Corriger, appliquer une mesure de réduction du risque, investiguer une éventuelle compromission ou documenter pourquoi le traitement peut attendre : la bonne décision dépend des éléments précédents.

Il faut aussi prendre en compte le fait qu'une décision n'est jamais définitive. La situation peut évoluer et il faut être prêt à s'adapter.

Une méthode comme SSVC peut aider à formaliser cet arbitrage. Son intérêt n’est pas de produire un chiffre de plus, mais de conduire à une décision explicite, compréhensible et révisable.

Conclusion : quatre réflexes avant de lancer le patch

Quand une nouvelle CVE arrive dans la file, quatre gestes s'imposent dans le processus de qualification :

Lire le vecteur CVSS, sa version et ses conditions, plutôt que s’arrêter au score ;
Chercher les signaux d’exploitation, sans confondre absence de signal et absence de risque ;
Vérifier le contexte local : produit concerné, exposition et importance de l’actif ;
Décider et tracer une action, un responsable et un délai adaptés à ce contexte.

Le CVSS reste précieux. Il donne un langage commun pour parler de sévérité. Le problème commence quand on lui demande de piloter, à lui seul, toute la file de remédiation.

C’est précisément le travail que nous rendons plus simple chez Sentibee: rapprocher les informations sur les vulnérabilités, les signaux d’exploitation et le contexte produit pour aider les équipes à construire une file d’actions, plutôt qu’une liste de scores à faire descendre.

Pour aller plus loin : https://www.first.org/cvss/calculator/4.0

Qu’est-ce que le CVSS ? Comprendre (et dépasser) le score de criticité