Quand un scan remonte plus de vulnérabilités de sévérité élevée ou critique que votre équipe ne peut en corriger cette semaine, il vous faut un ordre de traitement. Trier par score CVSS paraît objectif, mais cela répond à la mauvaise question. En le combinant avec EPSS, le catalogue KEV et la connaissance de vos propres actifs, vous obtenez une bien meilleure réponse.
Ce que mesure CVSS, et ce qu’il ne mesure pas
Le Common Vulnerability Scoring System (CVSS), maintenu par le FIRST, décrit la gravité d’une vulnérabilité. Le score de base reflète les caractéristiques intrinsèques de la vulnérabilité et suppose un pire cas raisonnable dans tous les environnements où elle pourrait être déployée. Le guide d’utilisation de CVSS v4.0 du FIRST le dit explicitement : les scores de base mesurent la gravité et « ne doivent pas être utilisés seuls pour évaluer le risque ».
Pourtant, le score de base est généralement tout ce dont vous disposez. Le même guide relève que les éditeurs de produits et la National Vulnerability Database américaine ne publient en général que des scores de base. C’est à vous d’ajouter les informations sur les menaces actuelles et sur votre propre environnement.
Un vecteur CVSS montre comment le score a été construit. Par exemple :
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8, Critical)Il se lit ainsi : accessible par le réseau, complexité faible, aucun privilège ni aucune interaction utilisateur nécessaires, impact élevé sur la confidentialité, l’intégrité et la disponibilité. Il ne dit rien de l’exploitation éventuelle de la vulnérabilité, ni même de l’exposition réelle du système concerné dans votre réseau.
CVSS v3.1 et v4.0 en bref
CVSS v4.0 a été publié en novembre 2023. Les deux versions utilisent les mêmes niveaux qualitatifs : faible de 0,1 à 3,9, moyen de 4,0 à 6,9, élevé de 7,0 à 8,9 et critique de 9,0 à 10,0. Vous verrez encore les deux versions dans les avis de sécurité pendant un certain temps.
| Sujet | CVSS v3.1 | CVSS v4.0 |
|---|---|---|
| Groupes de métriques | Base, temporel, environnemental | Base, menace, environnemental, complémentaire |
| Informations sur les exploits | Groupe temporel à trois métriques | Groupe menace avec la seule métrique Exploit Maturity |
| Impact élargi | Métrique Scope (portée) | Impacts distincts sur le système vulnérable et sur les systèmes en aval |
| Conditions d’attaque | Attack Complexity | Attack Complexity plus une nouvelle métrique, Attack Requirements |
| Interaction utilisateur | None ou Required | None, Passive ou Active |
| Libellé | Un seul score | CVSS-B, CVSS-BT, CVSS-BE ou CVSS-BTE, selon les groupes utilisés |
Les libellés de la v4.0 sont utiles. Un score marqué CVSS-B est un score de base seul : vous savez ainsi que la menace et l’environnement n’ont pas été pris en compte. Les métriques complémentaires, comme la possibilité d’automatiser l’exploitation, ajoutent du contexte sans modifier le score.
EPSS : quelle probabilité d’exploitation ?
L’Exploit Prediction Scoring System (EPSS), également géré par le FIRST, estime la probabilité qu’une CVE publiée soit exploitée dans la nature au cours des 30 prochains jours. Les scores vont de 0 à 1 et sont publiés chaque jour pour chaque CVE, gratuitement, en téléchargement CSV et via une API.
Le guide d’utilisation du FIRST propose de combiner EPSS et CVSS dans un simple tableau à quatre cases :
| CVSS faible | CVSS élevé | |
|---|---|---|
| EPSS élevé | Probablement exploitée, portée limitée à elle seule ; vérifiez si elle peut être enchaînée avec d’autres | À corriger en premier |
| EPSS faible | Peut généralement passer au second plan | Grave mais moins susceptible d’être exploitée ; surveillez son évolution |
Le guide est tout aussi clair sur les limites. EPSS ne couvre que le volet menace du risque : il « ne doit jamais être considéré comme un score de risque ». Il ne sait pas quels systèmes vous exploitez, à quel point ils sont exposés ni quelles données ils contiennent. Un score faible ne signifie jamais non plus un risque nul.
KEV : la vulnérabilité est-elle déjà exploitée ?
Le catalogue Known Exploited Vulnerabilities (KEV) de la CISA recense les vulnérabilités dont l’exploitation dans la nature est attestée par des preuves fiables. Une vulnérabilité n’y est ajoutée que si trois conditions sont réunies :
- elle possède un identifiant CVE
- il existe des preuves fiables d’exploitation active ; les scans, les travaux de recherche et le code de preuve de concept ne suffisent pas à eux seuls
- il existe des consignes de correction claires, comme une mise à jour de l’éditeur
La Binding Operational Directive 22-01 oblige les agences fédérales civiles américaines à corriger les entrées du KEV dans des délais fixés. Les autres organisations n’y sont pas soumises, mais la CISA recommande vivement à tous de traiter les entrées du KEV en priorité dans leur gestion des vulnérabilités.
Les organisations européennes disposent d’une seconde source. La base européenne des vulnérabilités de l’ENISA (EUVD), opérationnelle depuis mai 2025 en application de la directive NIS2, comprend un tableau de bord des vulnérabilités exploitées. Les données CVE, les avis des éditeurs et le catalogue KEV y sont intégrés automatiquement.
Une méthode de priorisation simple
Servez-vous du KEV et d’EPSS pour décider à quel point un correctif est urgent, et de votre connaissance de vos actifs pour décider où il compte. Les niveaux ci-dessous sont un point de départ que nous proposons, pas une norme. Adaptez les délais à votre capacité et à votre appétence au risque.
| Niveau | Condition | Objectif suggéré |
|---|---|---|
| 1 | Dans le KEV ou signalée comme exploitée dans l’EUVD, sur un système exposé à Internet ou critique pour l’activité | Quelques jours, avec des mesures de contournement si aucun correctif n’est encore possible |
| 2 | Dans le KEV sur des systèmes internes, ou EPSS élevé sur un système exposé | Prochain cycle de correctifs, sous deux semaines environ |
| 3 | CVSS élevé ou critique avec un EPSS faible, sans exposition | Cycle mensuel normal ; revérifiez régulièrement EPSS et le KEV |
| 4 | Tout le reste | Maintenance courante, ou acceptation du risque en consignant pourquoi |
C’est le contexte des actifs qui transforme un score en décision. Posez trois questions pour chaque système : est-il accessible depuis Internet, quelles données ou quels accès détient-il, et que coûterait une interruption ? En termes CVSS, ce sont vos métriques environnementales.
Un exemple pour illustrer
Imaginez deux vulnérabilités détectées le même jour. La première est notée 9,8 sur un serveur de test interne sans données sensibles, avec un score EPSS faible et aucune entrée dans le KEV. La seconde est une élévation de privilèges locale notée 7,8, présente dans le catalogue KEV et sur chaque ordinateur portable du personnel.
Le tri par score place la première en tête. La méthode ci-dessus place la seconde en premier. Elle est exploitée, et elle se trouve sur chaque ordinateur portable, là où un seul e-mail d’hameçonnage réussi peut donner à un attaquant le point d’appui dont il a besoin. Le serveur de test sera quand même corrigé, dans le cycle normal.
Par où commencer
- Vérifiez que votre scanner ou votre inventaire des actifs enregistre l’identifiant CVE de chaque vulnérabilité.
- Récupérez les scores EPSS quotidiens et la liste KEV, ou utilisez un outil qui le fait déjà.
- Classez vos actifs selon leur exposition et leur importance pour l’activité, même simplement en « exposé à Internet » et « critique ».
- Convenez avec la direction de délais cibles par niveau et suivez-les.
- Quand un avis ne donne qu’un vecteur, lisez-le avec notre calculateur CVSS et adaptez-le à votre environnement.
Si vous préférez que ce travail soit mené en continu, notre service de sécurité managée peut prendre en charge pour vous le suivi et la priorisation des vulnérabilités.
