Prioriser et remédier : notions de score CVSS

Imaginez un médecin des urgences face à plusieurs patients : il ne les soigne pas dans l’ordre d’arrivée, mais selon la gravité de leur état. Une équipe qui reçoit un rapport de trente constats est dans la même situation : tout ne peut pas être corrigé en même temps. Il faut un moyen partagé d’exprimer la gravité, puis d’arbitrer en tenant compte du contexte. C’est le rôle des échelles de gravité, dont la plus répandue est le CVSS.

Qu’est-ce que le CVSS ?

Le CVSS (Common Vulnerability Scoring System) est un système ouvert qui attribue à une vulnérabilité un score de gravité de 0 à 10, à partir d’une série de critères objectifs. Il est notamment utilisé dans la base NVD (nvd.nist.gov) pour qualifier les CVE. L’objectif est de parler le même langage : « 9,8 » signifie la même chose pour un testeur, un éditeur ou un responsable de la sécurité. Plusieurs versions existent ; les versions récentes ont affiné la méthode. Les principes ci-dessous valent pour toutes.

Les grandes composantes

Le score de base décrit la vulnérabilité en elle-même, indépendamment de l’environnement. Il se calcule à partir de critères regroupés en deux familles :

Selon la version, d’autres critères s’ajoutent (par exemple la portée de l’impact au-delà du composant touché). Vous n’avez pas besoin de connaître les formules : des calculateurs publics, accessibles sur le site de la NVD, effectuent le calcul quand vous renseignez chaque critère.

Les niveaux qualitatifs

Le score numérique est traduit en un niveau compréhensible par tous :

Raisonner avec le CVSS : trois exemples qualitatifs

Voici trois situations de votre parcours, évaluées par le raisonnement sur les critères (sans calcul exact) :

• Injection SQL sur une page publique, sans compte requis, avec lecture de données personnelles : vecteur par le réseau, complexité faible, aucun privilège, aucune interaction, forte atteinte à la confidentialité : gravité élevée à critique.
• XSS réfléchi sur une page publique : une victime doit cliquer sur un lien (interaction requise), l’impact porte sur un utilisateur à la fois : gravité moyenne, qui monte si la page est vue par des administrateurs.
• Divulgation de la version du serveur dans les en-têtes : aucun impact direct, mais information utile à l’attaquant : gravité faible.

Les limites du score de base

Le CVSS est utile, mais il a des limites que tout professionnel doit connaître :

• Il ignore le contexte propre à l’organisation : la même vulnérabilité est bien plus grave sur le serveur de paiement que sur un site vitrine rarement mis à jour.
• Il ne mesure pas la probabilité réelle d’attaque : une faille « critique » sur un composant inaccessible depuis Internet peut être moins urgente qu’une faille « moyenne » massivement exploitée.
• Il suppose le pire cas technique d’une vulnérabilité, pas son usage particulier dans votre application.
• Il est parfois subjectif : deux personnes peuvent choisir des valeurs différentes pour un critère (par exemple la complexité).

C’est pourquoi on complète le score de base par des informations de contexte : des critères « temporels » (existe-t-il un exploit public ? un correctif ?) et « environnementaux » (importance de l’actif concerné). Des listes publiques recensent aussi les vulnérabilités effectivement exploitées dans la nature, ce qui aide à prioriser.

Prioriser comme un professionnel

Une démarche simple, utilisable dès aujourd’hui, combine plusieurs critères :

1. Gravité technique (CVSS ou échelle équivalente).
2. Exposition : la faille est-elle accessible depuis Internet, par un utilisateur anonyme, ou seulement en interne et avec un compte ?
3. Valeur de l’actif : quelles données ou quels services sont concernés ?
4. Facilité d’exploitation : existe-t-il des outils ou des procédures publiques ?
5. Effort de correction : un correctif d’une ligne et une refonte ne se planifient pas de la même façon.
6. Obligations légales et contractuelles : une faille exposant des données personnelles a des implications (RGPD) qui renforcent l’urgence.

En pratique, on distingue des gains rapides (correction simple, bénéfice élevé : à faire tout de suite) et des chantiers de fond (refonte du contrôle d’accès, par exemple : à planifier).

Remédier : le cycle complet

1. Corriger selon la recommandation, en traitant la cause racine et pas seulement le symptôme (par exemple, corriger la construction des requêtes, pas seulement le paramètre testé).
2. Chercher les « cousins » : une faille trouvée à un endroit existe souvent ailleurs, dans le code de même facture.
3. Retester : vérifier que la correction fonctionne et ne casse rien.
4. Prévenir la récurrence : formation, bibliothèques centralisées de contrôle, tests automatisés, revue de code.
5. Mesures compensatoires en attendant : quand une correction demande du temps, on réduit le risque autrement (filtrage temporaire, désactivation de la fonction, surveillance renforcée).
6. Documenter l’état de chaque constat : ouvert, en cours, corrigé, accepté (avec justification de la personne responsable).

À vous de jouer

1. Reprenez cinq constats de votre carnet. Pour chacun, renseignez qualitativement : vecteur (Internet ou local), complexité, privilèges requis, interaction de l’utilisateur, impact sur confidentialité, intégrité et disponibilité.
2. Attribuez un niveau (faible, moyen, élevé, critique) et justifiez-le en une phrase.
3. Classez les cinq constats par priorité de correction en tenant compte de l’exposition et de l’effort de correction. Identifiez deux « gains rapides ».
4. Pour le premier, écrivez le plan de remédiation en quatre étapes (corriger, chercher les cousins, retester, prévenir).

Comment faire quand on découvre une faille sur un système dont on n’est pas le propriétaire, de façon légitime ? La leçon suivante aborde le bug bounty et la divulgation responsable.