La gestion des vulnérabilités est l’un des processus de sécurité les plus anciens, et pourtant l’un des plus mal maîtrisés. La raison est arithmétique : le nombre de vulnérabilités publiées chaque année a dépassé 40 000 en 2024 selon les données du programme CVE [3]. Aucune organisation ne peut corriger l’intégralité de ce flux. Le vrai sujet n’est donc pas de patcher plus, mais de patcher juste : concentrer un effort fini sur les failles qui présentent un risque réel pour l’entreprise.
Cet article décrit un processus de gestion des vulnérabilités fondé sur le risque, en s’appuyant sur les sources officielles : le programme CVE de MITRE, le système de notation CVSS du NIST, le catalogue KEV de la CISA, le score EPSS du FIRST, et les avis du CERT-FR. L’objectif est opérationnel : passer d’une logique de volume à une logique de priorisation.
Pourquoi la gestion des vulnérabilités échoue souvent
La plupart des programmes de gestion des vulnérabilités démarrent par un scan, produisent un rapport de plusieurs milliers de lignes, et s’arrêtent là. L’équipe sécurité transmet la liste aux équipes d’exploitation, qui la regardent une fois, constatent qu’elle est ingérable, et la classent. Six mois plus tard, le même scan produit la même liste, allongée. Ce scénario est si fréquent qu’il constitue un anti-modèle reconnu.
Le piège du volume
Un parc d’entreprise de taille intermédiaire génère couramment plusieurs dizaines de milliers de findings au premier scan complet. Si l’on décide de traiter tout ce qui est noté critique ou élevé, on hérite encore de plusieurs milliers d’items, car ces deux catégories représentent à elles seules la majorité des CVE publiées. La conséquence est une paralysie : l’équipe ne sait pas par où commencer, et l’absence de priorisation rend tout le processus inopérant.
Le piège du CVSS pris isolément
Le réflexe naturel consiste à trier par score CVSS décroissant. C’est une erreur méthodologique. Le CVSS mesure la gravité technique d’une vulnérabilité, c’est-à-dire le dommage potentiel si elle est exploitée. Il ne mesure pas la probabilité qu’elle le soit. Or de nombreuses vulnérabilités notées 9.8 ne sont jamais exploitées, parce qu’elles concernent des composants peu déployés, ou que l’exploitation est techniquement complexe à industrialiser. À l’inverse, des failles notées moyennes peuvent être massivement exploitées si elles touchent un produit ubiquitaire exposé sur Internet.
Le piège de l’inventaire absent
On ne peut corriger que ce que l’on connaît. Une part importante des incidents exploite des actifs oubliés : un serveur de test laissé en ligne, une appliance en fin de support, un service exposé par erreur. Sans inventaire fiable, le scan ne couvre qu’une fraction du parc, et la gestion des vulnérabilités donne une fausse impression de maîtrise. Cette dépendance à l’inventaire est la même que celle évoquée dans la démarche EBIOS Risk Manager : la méthode d’analyse de risque de l’ANSSI.
Les briques de référence : CVE, CVSS, KEV, EPSS
Avant de décrire le processus, il faut poser le vocabulaire. Quatre référentiels structurent la veille mondiale, et leur articulation est la clé d’une priorisation utile.
La CVE : l’identifiant universel
Le programme CVE (Common Vulnerabilities and Exposures) attribue un identifiant unique à chaque vulnérabilité publiquement divulguée, au format CVE-année-numéro [3]. Il est piloté par MITRE pour le compte de la CISA, et l’attribution est déléguée à un réseau d’autorités de numérotation appelées CNA (éditeurs, CERT, chercheurs accrédités). La CVE est un point de référence neutre : elle permet à un éditeur, un scanner, un avis du CERT-FR et un bulletin CISA de parler exactement de la même faille. Elle ne contient pas de jugement de gravité, seulement une description et des références.
Le CVSS : la gravité technique
Le CVSS (Common Vulnerability Scoring System) est un système de notation maintenu sous l’égide du FIRST et documenté par le NIST [2]. Il produit un score de 0 à 10 à partir de plusieurs métriques : le vecteur d’attaque (réseau, adjacent, local, physique), la complexité, les privilèges requis, l’interaction utilisateur, et l’impact sur la confidentialité, l’intégrité et la disponibilité. Le score de base reflète la gravité intrinsèque, indépendamment du contexte. La version CVSS v4.0 ajoute des métriques d’environnement et de menace destinées précisément à contextualiser ce score de base, mais en pratique la plupart des organisations n’exploitent que le score de base, d’où sa surinterprétation.
Le KEV : l’exploitation prouvée
Le catalogue KEV (Known Exploited Vulnerabilities) de la CISA recense les CVE pour lesquelles il existe une preuve d’exploitation active dans la nature [1]. C’est un filtre puissant : une CVE n’entre dans le KEV que sur la base de cette preuve. Si une vulnérabilité y figure, elle est attaquée maintenant, et la corriger devient une priorité absolue indépendamment de son score CVSS. Le KEV est devenu une référence de priorisation au-delà du périmètre administratif américain, parce qu’il transforme une question probabiliste (cette faille sera-t-elle exploitée) en fait observé (elle l’est).
L’EPSS : la probabilité d’exploitation
Le score EPSS (Exploit Prediction Scoring System), publié par le FIRST, estime la probabilité qu’une vulnérabilité soit exploitée dans les 30 jours [5]. Il s’exprime de 0 à 1 et s’appuie sur un modèle statistique alimenté par des signaux d’exploitation réels. Là où le KEV est binaire (exploitée ou non), l’EPSS est continu et prospectif : il aide à anticiper les failles qui basculeront prochainement vers l’exploitation. Croiser EPSS et CVSS permet de distinguer les vulnérabilités à la fois graves et probablement exploitées, qui constituent la cible prioritaire.
La synthèse : une matrice de priorisation
La combinaison de ces référentiels donne une logique de tri claire. Une CVE présente au KEV se traite en premier, sans débat. À défaut, une CVE avec un EPSS élevé et un CVSS élevé sur un actif exposé vient ensuite. Une CVE à fort CVSS mais EPSS faible et actif interne descend dans la file. Cette pondération par le risque réel, plutôt que par le seul score de base, est ce qui distingue un programme mature.
| Signal | Mesure | Usage en priorisation |
|---|---|---|
| CVE | Identifiant unique | Référence neutre, traçabilité |
| CVSS | Gravité technique (0 à 10) | Estime le dommage potentiel |
| KEV | Exploitation prouvée (oui/non) | Priorité absolue si présent |
| EPSS | Probabilité à 30 jours (0 à 1) | Anticipe l’exploitation à venir |
Le processus en cinq phases
Le standard NIST SP 800-40 révision 4 décrit la gestion des vulnérabilités comme un cycle continu de planification et de déploiement de correctifs [6]. On peut le décliner en cinq phases opérationnelles, à conduire en boucle.
Phase 1 : inventaire des actifs
Tout commence par un inventaire fiable et tenu à jour : serveurs, postes, appliances, conteneurs, services exposés, dépendances logicielles. Sans cartographie, le périmètre du scan est incertain et la couverture illusoire. Cet inventaire doit être enrichi de la criticité métier de chaque actif, car la même vulnérabilité n’a pas le même poids sur un serveur de facturation exposé que sur un poste de test isolé. La discipline d’inventaire rejoint celle de la gestion des identités et des accès décrite dans IAM et PAM : maîtriser les identités en 2026.
Phase 2 : détection
La détection combine plusieurs sources : le scan de vulnérabilités authentifié (qui interroge l’état réel des systèmes), l’analyse des dépendances logicielles (SCA), et la veille externe via les bulletins du CERT-FR [4] et les avis éditeurs. Le scan authentifié est nettement plus précis que le scan réseau seul, car il lit les versions installées plutôt que de les déduire. La fréquence de scan dépend de la criticité : hebdomadaire pour les actifs exposés, mensuelle pour le parc interne, au minimum.
Phase 3 : priorisation
C’est le coeur du processus. Chaque finding est enrichi du statut KEV, du score EPSS, du score CVSS, et de la criticité de l’actif. On applique ensuite la matrice de priorisation : KEV en premier, puis CVSS élevé croisé avec EPSS élevé sur actif exposé, puis le reste. Cette phase réduit typiquement une liste de milliers d’items à quelques dizaines d’actions réellement urgentes, ce qui rend le processus tenable. C’est aussi à ce stade que s’opère l’arbitrage entre risque de sécurité et risque d’exploitation, lorsqu’un correctif menace la stabilité de la production.
Phase 4 : remédiation
La remédiation prend trois formes. Le correctif (patch) est la voie normale lorsqu’il existe et qu’il peut être déployé. Le contournement (mitigation) s’applique quand le patch n’est pas disponible ou pas déployable immédiatement : isolation réseau, restriction d’accès, règle de détection sur l’EDR. L’acceptation de risque, enfin, est une décision formelle et documentée, prise au bon niveau, lorsque ni patch ni contournement ne sont possibles à court terme. Le déploiement de correctifs s’intègre idéalement dans une chaîne maîtrisée, dans la lignée des pratiques de DevSecOps : intégrer la sécurité dans la CI/CD.
Phase 5 : vérification et mesure
Une remédiation n’est acquise qu’une fois vérifiée. Le scan suivant doit confirmer la disparition du finding ; un patch annoncé mais mal déployé est un faux sentiment de sécurité fréquent. Le processus se pilote ensuite par des indicateurs : délai moyen de remédiation par criticité, taux de couverture du scan, nombre de CVE KEV ouvertes, âge moyen des vulnérabilités non traitées. Ces métriques alimentent un comité périodique et objectivent la trajectoire du programme.
Articuler la gestion des vulnérabilités avec la conformité
La gestion des vulnérabilités n’est pas qu’une bonne pratique : elle est explicitement attendue par les référentiels réglementaires. L’article 21.2 de la directive NIS2 cite le traitement des vulnérabilités et leur divulgation parmi les mesures minimales de gestion des risques. Les obligations de fond de ce régime sont détaillées dans NIS2 entreprise : guide complet de la directive 2026.
Une exigence transverse aux référentiels
Au-delà de NIS2, la gestion des vulnérabilités figure dans la quasi-totalité des cadres de sécurité : les contrôles CIS, la norme ISO 27001 (maîtrise des vulnérabilités techniques), et les exigences sectorielles financières du règlement DORA. Le point commun de ces textes est qu’ils n’imposent pas un outil, mais un processus formalisé, mesurable et révisé. Disposer d’une politique de gestion des vulnérabilités écrite, avec des délais de remédiation par criticité, est devenu un attendu d’audit.
Le lien avec le test d’intrusion
Le scan de vulnérabilités et le test d’intrusion sont complémentaires et souvent confondus. Le scan est automatisé, large et récurrent ; il détecte les vulnérabilités connues à grande échelle. Le test d’intrusion est manuel, ciblé et ponctuel ; il valide l’exploitabilité réelle et les chaînes d’attaque que le scan ne voit pas. Un programme mature utilise le scan en continu et le pentest en validation périodique, comme expliqué dans Pentest et test d’intrusion en entreprise.
Erreurs fréquentes et points de vigilance
Quelques écueils reviennent systématiquement et méritent une attention explicite.
Confondre couverture du scan et couverture du parc
Un tableau de bord qui affiche 98 pour cent d’actifs sains rassure, mais il ne mesure que les actifs scannés. Si l’inventaire est incomplet, le chiffre est trompeur. La métrique honnête rapporte les actifs scannés au nombre total d’actifs connus, et suit en parallèle l’effort de découverte des actifs inconnus.
Patcher sans tester ni planifier
Un correctif déployé en urgence sur un système de production sans fenêtre de test peut provoquer une indisponibilité plus coûteuse que la vulnérabilité elle-même. La réponse n’est pas de ralentir, mais de pré-définir des procédures : environnements de pré-production, fenêtres de maintenance, capacité de retour arrière. Pour les CVE du KEV exposées, l’urgence justifie d’accepter un risque d’exploitation maîtrisé ; pour le reste, la planification reste la règle.
Oublier les dépendances logicielles
Une part croissante des vulnérabilités se loge dans les bibliothèques tierces embarquées dans les applications, pas dans le système d’exploitation. L’analyse de composition logicielle (SCA) et la tenue d’un inventaire des composants (SBOM) sont devenues indispensables, en particulier pour les organisations qui développent leurs propres applications ou qui exploitent des conteneurs.
Négliger la fin de support
Un actif en fin de support ne reçoit plus de correctifs : ses vulnérabilités sont définitives. La gestion des vulnérabilités doit donc intégrer un suivi des cycles de vie produit et anticiper les migrations, faute de quoi des failles non corrigeables s’accumulent silencieusement.
Conclusion
La gestion des vulnérabilités est un problème de priorisation avant d’être un problème de correction. Le flux annuel de plus de 40 000 CVE rend toute approche exhaustive illusoire. La voie efficace consiste à inventorier rigoureusement, à détecter largement, puis à concentrer l’effort sur les failles que les signaux officiels désignent comme dangereuses : le catalogue KEV de la CISA pour l’exploitation prouvée, l’EPSS pour la probabilité d’exploitation, le CVSS pour la gravité, le tout pondéré par l’exposition réelle de l’actif. Les bulletins du CERT-FR fournissent le relais français de cette veille. Un programme qui formalise ce cycle en cinq phases, le mesure et le révise, répond à la fois aux exigences réglementaires et au risque opérationnel, là où une logique de volume échoue invariablement.
Sources et références
[1] CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog [2] NIST, NVD CVSS metrics and scoring, https://nvd.nist.gov/vuln-metrics/cvss [3] Programme CVE (MITRE / CISA), https://www.cve.org/ [4] CERT-FR, avis et alertes de l’ANSSI, https://www.cert.ssi.gouv.fr/ [5] FIRST, Exploit Prediction Scoring System (EPSS), https://www.first.org/epss/ [6] NIST SP 800-40 révision 4, Guide to Enterprise Patch Management Planning, https://csrc.nist.gov/pubs/sp/800/40/r4/final