Gestion des vulnérabilités : prioriser les correctifs avec CVSS, EPSS et KEV
Plusieurs dizaines de milliers de vulnérabilités (CVE) sont publiées chaque année. Aucune équipe ne peut toutes les corriger immédiatement, et la plupart ne seront jamais exploitées. La question n'est donc pas « combien de vulnérabilités avons-nous ? », mais « lesquelles corriger d'abord ? ».
Le piège : trier uniquement par score CVSS
Le score CVSS (Common Vulnerability Scoring System) mesure la sévérité intrinsèque d'une vulnérabilité, sur une échelle de 0 à 10. Il ne dit pas si elle est réellement exploitée, ni si elle concerne un serveur exposé sur Internet ou un poste isolé. Une grande partie des CVE obtiennent un score élevé : trier sur ce seul critère produit une liste « critique » interminable, et les équipes finissent par ne plus la regarder.
Trois sources complémentaires
CVSS (publié par le FIRST) : la sévérité technique. La version 3.1 reste la plus répandue, la version 4.0 est publiée depuis fin 2023. Ses métriques environnementales permettent d'ajuster le score à votre contexte.
EPSS (Exploit Prediction Scoring System, également publié par le FIRST) : la probabilité qu'une vulnérabilité soit exploitée dans les 30 prochains jours. Les scores sont mis à jour quotidiennement et accessibles gratuitement.
KEV (Known Exploited Vulnerabilities, catalogue de la CISA américaine) : la liste des vulnérabilités dont l'exploitation est avérée. Si une CVE y figure, la question de sa probabilité d'exploitation est tranchée.
À compléter par les avis et alertes nationaux : CERT-FR en France, maCERT au Maroc.
Une méthode de priorisation en quatre niveaux
Les délais ci-dessous sont des exemples à adapter à votre organisation et à vos contraintes de production.
Urgent : vulnérabilité présente dans le catalogue KEV ou signalée comme activement exploitée par un CERT, sur un actif exposé à Internet. Correctif ou mesure de contournement sous 48 à 72 heures.
Prioritaire : vulnérabilité KEV sur un actif interne, ou score EPSS parmi les plus élevés sur un actif exposé. Traitement sous une semaine.
Planifié : score CVSS élevé (7 ou plus) sans exploitation connue. Intégration au cycle mensuel de correctifs.
Courant : le reste, traité dans le cycle normal, ou risque accepté et documenté.
Le contexte de vos actifs fait la différence
Aucune de ces sources ne connaît votre système d'information. Pour prioriser correctement, il faut un inventaire à jour qui indique pour chaque actif s'il est exposé à Internet, quelle est sa criticité métier et quelles mesures compensatoires existent déjà (segmentation, pare-feu applicatif, EDR). Une vulnérabilité KEV sur un serveur web public et la même sur un poste de test isolé ne relèvent pas du même délai.
Outillage et indicateurs
Les scanners de vulnérabilités (Greenbone/OpenVAS, Nessus, Qualys et d'autres) produisent la liste brute. Le module de détection de vulnérabilités de Wazuh peut aussi signaler les CVE présentes sur les machines supervisées : nous en parlons dans notre article sur les règles de corrélation Wazuh. L'enrichissement par EPSS et KEV se fait ensuite par script, à partir des données publiques.
Trois indicateurs suffisent pour piloter :
le délai moyen de correction par niveau de priorité ;
le nombre d'actifs exposés portant une vulnérabilité KEV non corrigée (objectif : zéro) ;
la part du parc couverte par l'inventaire et les scans.
Quand on ne peut pas corriger tout de suite
Un correctif peut casser une application métier ou nécessiter un arrêt impossible à court terme. Dans ce cas : appliquer la mesure de contournement publiée par l'éditeur, désactiver la fonction vulnérable, isoler l'actif, renforcer la surveillance, et formaliser l'acceptation du risque avec une date de revue.
Gazeltech aide les équipes à mettre en place ce processus, de l'inventaire à la supervision. Contactez-nous pour faire le point sur votre situation.



Commentaires