On adore tous les scores CVSS. Surtout quand ils sont rouges et qu’ils font peur aux managers. “Chef, on a une 9.8 sur le serveur de prod !”. Panique à bord, cellules de crise, café froid. Mais est-ce qu’on comprend vraiment ce que ce chiffre raconte ? Ou est-ce qu’on l’utilise juste comme un horoscope de la sécurité ?
Qui tient la calculette ?
C’est le FIRST (Forum of Incident Response and Security Teams) qui gère le standard CVSS (Common Vulnerability Scoring System). Ce n’est pas une agence gouvernementale obscure, mais une asso internationale de gens très sérieux qui aiment les matrices et les vecteurs.
Un peu d’histoire (et de maths)
Pourquoi on a créé ça ? Parce qu’avant, c’était la jungle. “C’est grave ?” “Bof, moyen grave”. “Moyen grave comment ?”. Il fallait un langage commun.
L’évolution des espèces
- v1 (2005) : Le brouillon. Personne ne l’utilisait vraiment, c’était trop subjectif.
- v2 (2007) : Le standard pendant longtemps. Simple, mais avec des défauts majeurs (tout était “High” ou “Medium”).
- v3.0 (2015) / v3.1 (2019) : La révolution. Introduction du scope (Scope Change - S:C), qui a fait exploser les scores. Une faille XSS est passée de “bof” à “Critique” juste parce qu’elle touchait le navigateur de l’utilisateur.
- v4.0 (2023) : La petite dernière. Elle essaie de corriger le tir en ajoutant plus de granularité et en séparant mieux la sécurité du système vulnérable de celle du système impacté. Elle introduit aussi la notion d’Automatisable (très utile pour l’IA et les bots).
L’inflation des notes
Si on regarde les stats, c’est effrayant. En 2010, avoir un 10/10 était rare. C’était l’apocalypse. Aujourd’hui ? On a l’impression que chaque mardi matin apporte son lot de 9.8. Est-ce que le monde est plus dangereux ? Peut-être. Mais surtout, la formule v3 a tendance à “surnoter” certains risques théoriques.
Comment on cuisine un score ?
Le score CVSS n’est pas juste un chiffre, c’est un vecteur. Une chaîne de caractères barbare qui ressemble à ça : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
Il se compose de trois groupes de métriques :
- Base Score : La gravité intrinsèque de la faille (c’est le chiffre que tout le monde regarde).
- Attack Vector (AV) : D’où on attaque ? (Réseau, Local, Physique…)
- Attack Complexity (AC) : C’est dur ou pas ?
- Privileges Required (PR) : Faut être admin ou stagiaire ?
- User Interaction (UI) : Faut-il que Michel de la compta clique sur un lien ?
- Scope (S) : Est-ce qu’on casse juste l’appli ou tout le serveur ?
- CIA : Impact sur la Confidentialité, l’Intégrité, la Disponibilité.
- Temporal Score : Ça change avec le temps.
- Y a-t-il un exploit public ? (Si oui, ça chauffe).
- Y a-t-il un patch ?
- Environmental Score : C’est là que vous intervenez (ou devriez intervenir).
- “Ce serveur est-il critique ?”
- “Est-il exposé sur Internet ?”
Le problème : 99% des gens s’arrêtent au Base Score. C’est comme juger la vitesse d’une voiture juste en regardant son compteur, sans savoir si elle a un moteur.
👉 Les outils officiels :
CVSS vs OWASP Risk Rating
C’est là que je sors ma casquette de puriste. CVSS mesure la SÉVÉRITÉ technique. Il ne mesure pas le RISQUE.
Le risque, c’est : Impact x Probabilité.
- CVSS : “Cette bombe est très puissante” (Sévérité).
- Risque : “Cette bombe est très puissante, MAIS elle est au fond de l’océan et personne n’a le détonateur” (Risque Faible).
La méthodologie OWASP Risk Rating est beaucoup plus pragmatique pour une entreprise. Elle prend en compte le Business Impact. Une injection SQL sur le site de la cantine (CVSS 9.8) a moins de risque business qu’une fuite de données sur le CRM (CVSS 6.5).
Sources
“Je ne suis pas un numéro, je suis un homme libre !”
— Le Prisonnier (1967)