Aller au contenu
Plan R résilience & cybersécurité

Chronique no 025 — 2025

Gestion des vulnérabilités : de la détection à la correction efficace

Scanner ne suffit plus. Reprendre la main sur les vulnérabilités, c’est prioriser, corriger, gouverner. Une chronique pour rendre l’action possible.

5 min de lecture 1031 mots

Visuel de titre « De la faille au correctif : reprendre la main sur la gestion des vulnérabilités ».

Scanner c’est bien. Corriger, c’est indispensable.

Introduction — Le paradoxe de la faille connue

Chaque année, des milliers de vulnérabilités sont découvertes, documentées, publiées. Des correctifs existent, les alertes sont diffusées, des outils les détectent instantanément. Et pourtant… des entreprises continuent d’être compromises par des failles connues, documentées, non corrigées.

Ce paradoxe a un nom : l’inaction organisée. Ce n’est pas l’information qui manque. Ce sont les arbitrages, la coordination, les ressources, la volonté. Scanner un système ne le sécurise pas. Ce qui compte, c’est ce qu’on en fait.

Dans cette chronique, on fait le tri. Entre bonnes intentions et réalités terrain. Entre outils puissants et chaîne de remédiation défaillante. Entre surcharge informationnelle et criticité réelle. Objectif : rendre la gestion des vulnérabilités à la fois stratégique, actionnable et soutenable.

Partie 1 — Scanner ne suffit pas : le mythe de la couverture complète

Un flot ininterrompu de failles

En 2023, plus de 29 000 nouvelles vulnérabilités (CVEs) ont été enregistrées par la base NVD du NIST. En moyenne : 80 par jour. À cette cadence, aucun SOC, aucun RSSI, aucun DSI ne peut « tout traiter ». Et ce n’est pas la faute des outils.

Cas 1 — Le faux sentiment de couverture

Une entreprise scanne tous les mois ses serveurs avec un outil haut de gamme. Résultat : plus de 25 000 vulnérabilités détectées, dont 2 800 classées « critiques » par le CVSS. Et pourtant, aucune alerte n’a été escaladée en urgence. Pourquoi ? Parce que tout était critique… et que personne ne savait par quoi commencer.

Les limites structurelles des scanners

  • Basés sur la qualité de l’inventaire (machines oubliées = angles morts)

  • Faux positifs fréquents, surtout sans agent installé

  • CVSS mal compris : un 9.8 n’est pas toujours un danger immédiat

  • Temps de scan différé : une vulnérabilité critique peut exister des semaines avant d’être détectée

Partie 2 — Qualifiez avant d’agir : de la faille au bon arbitrage

Cas 2 — Citrix, patch disponible, mais serveur compromis

En 2020, une faille critique (CVE-2019-19781) affecte Citrix. Un correctif est publié. Le RSSI d’un grand groupe alerte… mais le patch est repoussé pour des raisons de “gel de production”. Quelques semaines plus tard : compromission avérée d’un serveur exposé.

➡️ Le problème n’est pas technique. Il est organisationnel.

Encadré : 5 questions pour prioriser une vulnérabilité

  1. L’actif est-il exposé à Internet ?

  2. L’actif traite-t-il des données critiques ou sensibles ?

  3. Le correctif est-il disponible et applicable ?

  4. Existe-t-il un code d’exploitation (exploit public) ?

  5. Existe-t-il une mesure de mitigation provisoire ?

➡️ Si la réponse est « oui » à 3 questions ou plus, la vulnérabilité mérite un traitement prioritaire.

De la faille à la gouvernance

Une vulnérabilité non corrigée ne signifie pas forcément négligence. Mais elle signale :

  • un arbitrage non formalisé

  • un défaut de gouvernance claire

  • une chaîne de remédiation insuffisamment alignée

Partie 3 — Mettre en œuvre une gestion actionnable et durable

Le triptyque de la gestion efficace

Inventaire fiable → Criticité contextualisée → Gouvernance outillée

Encadré : la stack minimale de gestion

Besoin Outils recommandés


Scan & détection Tenable, Qualys, Rapid7, Nexpose CMDB ServiceNow, iTop, GLPI (avec module CMDB) Orchestration ITSM Jira, ServiceNow, EasyVista Automatisation SOAR (XSOAR, Splunk Phantom, TheHive + Cortex) Suivi correctifs WSUS, BigFix, Tanium, SCCM, Ansible

Workflow idéal (résumé)

  1. Détection

  2. Qualification avec contexte

  3. Attribution (via ITSM)

  4. Correction (patch, mitigation, retrait)

  5. Contrôle (scan différentiel ou agent)

  6. Clôture documentaire

  7. Rapport de remédiation

Cas 3 — Trop de failles tuent la correction

Un acteur public découvre 37 000 vulnérabilités après un scan massif. Aucune gouvernance en place. L’équipe technique classe tout en « à faire ». Trois mois plus tard, la volumétrie a doublé et les premières alertes CERT tombent. Résultat : une task force d’urgence est montée, alors que le problème était déjà documenté depuis 90 jours.

Partie 4 — La faille dans la tête : idées reçues à désarmer

« Le RSSI est responsable de toutes les vulnérabilités »

Non. Le RSSI coordonne et alerte, mais les propriétaires d’actifs sont responsables des correctifs. C’est un enjeu de gouvernance, pas de personne.

« On patchera plus tard »

Le « plus tard » devient souvent jamais. Sans SLA de correction définis, les patchs sont relégués derrière des projets métiers urgents, jusqu’au jour où… il est trop tard.

« Toutes les vulnérabilités sont critiques »

C’est faux. Sans exposition réelle ou données sensibles à risque, une vulnérabilité reste potentiellement exploitable, mais pas prioritaire.

« Corriger casse la production »

Parfois vrai, mais souvent surestimé. Avec une gestion intelligente (tests, workarounds, patch management outillé), le patching devient soutenable.

Partie 5 — Normes, régulations et maturité

Ce que disent les textes

  • ISO/IEC 27001 (Annexe A.12.6.1) : gestion des vulnérabilités techniques

  • Directive NIS2 (2023) : correction dans des délais proportionnés au risque

  • DORA : imposera des contrôles renforcés sur les processus de remédiation

  • Politique de sécurité : obligation de pilotage des plans correctifs

L’indicateur oublié : la correction

Au-delà du nombre de vulnérabilités, il faut mesurer :

  • Le taux de remédiation à temps

  • Le délai moyen de correction

  • Le volume de correctifs appliqués

  • Le nombre de vulnérabilités documentées mais non traitées

Conclusion — La maturité se lit dans l’action

La gestion des vulnérabilités est un miroir. Elle reflète :

  • La qualité de l’inventaire

  • La lucidité de la gouvernance

  • L’engagement réel des équipes

  • La capacité d’un système à se régénérer

Les outils existent. Les informations aussi. Ce qui fait la différence, c’est l’exécution.

C’est la capacité à trier, prioriser, corriger. Encore et encore.

Dans un monde où l’on scanne plus vite qu’on ne corrige, il faut remettre le patch au cœur de l’hygiène numérique. Ce n’est ni glorieux, ni nouveau. Mais c’est indispensable pour survivre.

Bibliographie

NVD — National Vulnerability Database (NIST)

https://nvd.nist.gov/

Base officielle de toutes les CVE, indispensable pour suivre l’évolution quotidienne.

CVE.org

https://www.cve.org/

Portail de référence sur les vulnérabilités connues, maintenu par la communauté MITRE.

Tenable VPR (Vulnerability Priority Rating)

https://www.tenable.com/blog/what-is-vulnerability-priority-rating-vpr

Une approche de priorisation basée sur les risques, et non uniquement sur le CVSS.

ServiceNow Vulnerability Response

https://www.servicenow.com/products/vulnerability-response.html

Plateforme intégrée ITSM pour la gestion et le suivi de bout en bout.

ISO/IEC 27001:2022 — Annexe A.12.6.1

https://www.iso.org/standard/82875.html

Exigence normative sur la gestion des vulnérabilités.

Toutes les chroniques (91)