Sécurité
CVSS : Common Vulnerability Scoring System. « Système commun de notation des vulnérabilités », par analogie avec l'échelle de Richter qui résume la force d'un séisme en un seul chiffre. Le score va de 0 à 10 et le standard est maintenu par le FIRST.
Score et sévérité : Le score se range dans cinq paliers : aucune (0), faible (0,1 à 3,9), moyenne (4,0 à 6,9), haute (7,0 à 8,9) et critique (9,0 à 10). Ce palier sert de tri rapide dans les bulletins et les tableaux de bord.
Vecteur : Derrière chaque note se cache une chaîne du type CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, qui détaille le vecteur d'attaque (AV), la complexité (AC), les privilèges requis (PR), l'interaction humaine (UI) et l'impact sur la confidentialité, l'intégrité et la disponibilité. C'est cette chaîne qu'il faut lire, pas seulement le chiffre.
Groupes de métriques : La version 3.1 combine des métriques de base, temporelles et environnementales ; la version 4.0 remplace le groupe temporel par un groupe « menace » et ajoute des métriques supplémentaires. Seul le groupe de base est publié systématiquement, le reste est à calculer selon son propre contexte.
Limites : Le score de base mesure la gravité intrinsèque d'une faille, pas le risque réel pour un système donné. Un 9,8 sur une bibliothèque qu'aucun service n'appelle reste un 9,8 dans le rapport d'audit et devient l'urgence de la semaine, pendant que le 6,5 exposé sur Internet attend poliment son tour.
Ce qui arrive si on s'en passe
Sans notation CVSS, chaque vulnérabilité publiée arrive sans mesure commune de sa gravité : le tri des correctifs repose alors sur l'intuition ou sur l'écho médiatique, et une faille exploitable à distance sans authentification peut attendre derrière une faille qui exige un accès local. Les avis des éditeurs, les bases de vulnérabilités et les scanners ne parlent plus la même langue ; il devient impossible de comparer les alertes ou de fixer des seuils automatiques, comme bloquer un déploiement au-delà d'un score donné. Le vecteur qui accompagne le score disparaît lui aussi, et avec lui le détail des conditions d'exploitation (vecteur d'attaque, complexité, privilèges requis, impact sur la confidentialité, l'intégrité et la disponibilité) qui permet de juger si l'environnement est réellement exposé. Le score ne protège rien en soi ; son absence retarde la réponse aux failles les plus graves.
Explication de la marmotte
Quand on découvre une faille dans un logiciel, c'est-à-dire un défaut qui permet à quelqu'un de mal intentionné d'entrer ou de tout casser, il faut savoir si c'est grave. Ce système donne une note de 0 à 10, un peu comme l'échelle qui mesure la force des tremblements de terre. Pour la calculer, on répond à des questions : faut-il être sur place ou peut-on attaquer depuis l'autre bout du monde ? Faut-il un mot de passe ? Qu'est-ce que l'attaquant peut voler ou abîmer ? Plus la note est haute, plus il faut réparer vite. Attention : la note dit à quel point la faille est dangereuse en général, pas forcément pour ton ordinateur à toi.
Où ce terme est utilisé
- Prioriser les vulnérabilités avec CVSS 4.0, EPSS, KEV et exposition (12 occurrences)
- Attaque ANSSI et Dinum 2026 : la faille Metabase, c'est celui qui dit qui est (4 occurrences)
- Mettre en place une gestion récurrente des vulnérabilités (4 occurrences)
- PSIRT et divulgation coordonnée des vulnérabilités produit sous CRA (3 occurrences)
- Comment écrire un rapport de vulnérabilité corrigé (2 occurrences)
- Comment lire un rapport OWASP Top 10 (2 occurrences)
- OWASP Top 10 web 2025 : les dix catégories et ce qui a changé (2 occurrences)
- Cairn : panneaux d'opérations offensives par agents IA exposés sur Internet (1 occurrence)
- CICD-SEC-7 : configuration système non sécurisée (1 occurrence)
- Courtiers d'accès initial et marché des zero-day, détecter en amont (1 occurrence)
