CVSS (Système de notation des vulnérabilités communes)

TL;DR

CVSS est une manière standard de dire à quel point un bug de sécurité est grave. Il attribue à chaque vulnérabilité un score de 0 à 10 afin que les équipes sachent quoi corriger en priorité.

Pensez-y comme ceci :

• 0.0 → Aucun problème
• 10.0 → Laissez tout tomber et corrigez-le maintenant

Qu’est-ce que le CVSS ?

CVSS est un système de notation gratuit et largement utilisé pour les vulnérabilités de sécurité. Il est maintenu par un groupe industriel appelé FIRST, et il est utilisé par pratiquement tout le monde dans le domaine de la sécurité.

Chaque vulnérabilité reçoit un numéro entre 0.0 et 10.0 basé sur des critères tels que :

• La facilité d’exploitation
• La possibilité d’être attaqué à distance
• Les dégâts qu’elle peut causer

En termes simples : CVSS est un thermomètre pour les bugs logiciels.

Pourquoi le CVSS est important

Sans CVSS, chacun décrirait la gravité différemment. Un fournisseur pourrait dire qu’un bug est “critique”, tandis qu’un autre le qualifierait de “moyen”. CVSS offre à tout le monde un langage commun.

Cela est important parce que :

• Il indique aux équipes quoi corriger en premier La plupart des entreprises établissent des règles comme : “Tout ce qui dépasse 9.0 doit être corrigé dans les 48 heures.”
• Il est utilisé par les bases de données de vulnérabilités La Base de données nationale des vulnérabilités (NVD) attribue des scores CVSS à presque chaque CVE, ce qui permet aux outils de trier automatiquement des milliers de problèmes.
• Il élimine les conjectures Au lieu de débattre sur la gravité ressentie d’un bug, le CVSS vous oblige à examiner des facteurs concrets comme l’exploitabilité et l’impact.

Comment fonctionne le CVSS

CVSS a trois types de scores. La plupart du temps, vous ne verrez que le premier.

1. Score de Base (celui que tout le monde utilise)

Cela mesure à quel point la vulnérabilité est grave en elle-même, peu importe où elle est déployée.

Il examine des questions telles que :

• Peut-elle être exploitée via Internet ?
• Est-ce facile ou difficile à réaliser ?
• L’attaquant a-t-il besoin d’un identifiant ?
• Doit-il tromper un utilisateur ?
• Que se passe-t-il si elle est exploitée ? (vol de données, prise de contrôle du système, temps d’arrêt)

C’est le score que vous voyez habituellement dans les listes CVE.

2. Score Temporel (parfois utilisé)

Cela ajuste le score en fonction de ce qui se passe en ce moment.

Par exemple :

• Y a-t-il un code d’exploitation public ? (Le score augmente)
• Y a-t-il un correctif disponible ? (Le score diminue)

3. Score Environnemental (avancé, optionnel)

Cela adapte le score à votre environnement.

Par exemple :

• Le système est-il uniquement interne ? (Moins sévère)
• Contient-il des données clients ? (Plus sévère)

Un Exemple Réel : Log4j

Log4j (Log4Shell) est l’une des vulnérabilités les plus célèbres de tous les temps.

Son score CVSS était de 10.0 (Critique).

Pourquoi ?

• Il pouvait être exploité à distance
• Il ne nécessitait pas de connexion
• Il était facile à exploiter
• Il permettait une compromission complète du système

Qui Utilise CVSS ?

• Les fournisseurs de logiciels pour expliquer la gravité d’un bug
• Les équipes de sécurité pour se concentrer sur les problèmes les plus dangereux
• Les auditeurs pour vérifier si les vulnérabilités sont corrigées à temps

Plages de Scores CVSS (v3.1)

Voici comment les chiffres se traduisent généralement :

• 0.0 → Aucun problème
• 0.1–3.9 → Faible (à corriger plus tard)
• 4.0–6.9 → Moyen (à corriger bientôt)
• 7.0–8.9 → Élevé (à corriger de toute urgence)
• 9.0–10.0 → Critique (à corriger immédiatement)

Meilleures pratiques (Important)

• Ne vous fiez pas uniquement au CVSS Le CVSS mesure la sévérité, pas le risque. Un bug critique sur un serveur éteint n’est pas une réelle menace.
• Combinez le CVSS avec la probabilité Associez le CVSS avec EPSS pour voir quels bugs sont réellement susceptibles d’être exploités.
• Ajustez pour votre environnement Un bug sur un serveur de test n’est pas le même qu’un bug sur une base de données de production.
• Connaissez les versions Le CVSS v4.0 existe, mais la v3.1 est encore la plus couramment utilisée aujourd’hui.

Évitez la fatigue des alertes

Trouver des problèmes de sécurité n’est utile que si votre équipe sait quoi corriger en premier. Déverser des centaines d’alertes sur les ingénieurs n’améliore pas la sécurité ; cela crée la fatigue des alertes

Plexicus aide en classant les vulnérabilités afin que votre équipe puisse se concentrer sur ce qui compte réellement. Au lieu de traiter chaque problème de la même manière, Plexicus utilise quelques métriques simples pour guider la priorisation.

1) Priorité

Ce que cela signifie : À quel point ce problème est vraiment urgent

La priorité est un score de 0 à 100 qui regroupe tout en un seul chiffre :

• Sévérité technique (CVSS v4)
• Impact sur l’entreprise
• Probabilité d’exploitation

Ceci est votre liste d’actions. Triez par priorité et commencez par le haut.

• Priorité 85 → Laissez tout tomber et corrigez cela maintenant
• Priorité 45 → Important, mais cela peut attendre le prochain sprint

Exemple

Un problème d’injection SQL dans un outil interne qui :

• Est uniquement accessible via le VPN de l’entreprise
• Ne stocke pas de données sensibles

Scores :

• CVSS v4 : 8.2 (techniquement sérieux)
• Impact commercial : 45 (outil interne, exposition limitée)
• Disponibilité de l’exploit : 30 (nécessite une connexion)
• Priorité : 48

Pourquoi la priorité est importante

Si vous ne regardiez que le score CVSS, vous pourriez paniquer car 8.2 semble effrayant. La priorité met le problème en contexte et dit : « C’est réel, mais pas urgent. Corrigez-le au prochain sprint. »

Cela permet aux équipes de se concentrer sur le risque réel au lieu de réagir à chaque score CVSS élevé.

2) Impact

Ce que cela signifie : À quel point les choses deviennent mauvaises si cela est exploité

L’impact est noté de 0 à 100 et reflète les conséquences commerciales, pas seulement les conséquences techniques. Il examine des éléments tels que :

• Des données clients sont-elles impliquées ?
• Ce système est-il critique pour les opérations ?
• Y a-t-il des risques de conformité ou réglementaires ?

Exemple

• Injection SQL dans une base de données clients publique → Impact 95
• Le même problème dans un environnement de test interne → Impact 30

Même bug, risque commercial très différent.

3) EPSS

Ce que cela signifie : À quel point les attaquants sont susceptibles d’exploiter cela

EPSS prédit la probabilité qu’une vulnérabilité soit exploitée dans le monde réel dans les 30 prochains jours. Il varie de 0.0 à 1.0.

Exemple

• Une ancienne vulnérabilité avec CVSS 9.0 mais sans attaques actives → EPSS 0.01
• Une vulnérabilité plus récente avec CVSS 6.0 que les attaquants utilisent activement → EPSS 0.85

EPSS vous aide à vous concentrer sur ce qui intéresse les attaquants en ce moment, pas seulement sur ce qui semble mauvais sur le papier.

Comment utiliser ces métriques dans Plexicus

1. Connectez votre dépôt et attendez que l’analyse soit terminée
2. Allez à la page Findings
3. Triez et filtrez par Priority pour décider quoi corriger en premier

Termes associés

• CVE (Common Vulnerabilities and Exposures)
• EPSS (Exploit Prediction Scoring System)
• Gestion des vulnérabilités
• NVD (National Vulnerability Database)

FAQ CVSS

Quel est le score CVSS le plus élevé ?

10.0. Cela signifie que le bug est facile à exploiter et cause des dommages majeurs.

Un 9.0 est-il toujours pire qu’un 7.0 ?

Sur le papier, oui. En réalité, pas toujours. Un 7.0 qui est activement exploité peut être plus dangereux qu’un 9.0 que personne n’utilise.

Qui fixe le score CVSS ?

Habituellement, le fournisseur de logiciels ou le NVD. Parfois, ce sont les chercheurs en sécurité.

Puis-je modifier un score CVSS en interne ?

Oui. Beaucoup d’équipes ajustent les scores pour refléter leur configuration réelle, surtout si elles ont mis en place des protections solides.