La gestion des vulnérabilités désigne le processus continu par lequel une organisation recense les failles affectant ses systèmes, en évalue la gravité, les hiérarchise puis les traite — par correctif, par mesure compensatoire ou par acceptation documentée du risque. Ce caractère continu la distingue de l’audit ponctuel : des vulnérabilités nouvelles sont publiées chaque jour, sur un périmètre qui évolue tout autant.
L’inventaire des actifs et des dépendances
Avant tout scanner, la question porte sur le périmètre : serveurs, postes de travail, équipements réseau, applications, instances cloud. Un actif absent de l’inventaire échappe à la surveillance, et les angles morts se logent précisément là — machine virtuelle provisionnée hors procédure ou serveur hérité d’une fusion.
Le recensement ne s’arrête pas aux machines. Une application embarque des dizaines de bibliothèques tierces, chacune susceptible de porter une faille ; la vulnérabilité Log4Shell, fin 2021, a montré la difficulté, pour nombre d’organisations, de déterminer rapidement si elles étaient concernées. Tenir un inventaire des composants logiciels, ou SBOM, apporte cette visibilité ; il constitue aussi une première défense face aux attaques visant la chaîne d’approvisionnement logicielle, où la compromission arrive par un fournisseur ou une dépendance.
D’où viennent les signalements
Les scanners de vulnérabilités forment la source la plus systématique : en mode authentifié, ils comparent les versions installées aux bases de failles publiées ; en mode non authentifié, ils reproduisent le point de vue d’un attaquant externe. Leur périmètre d’analyse est celui de l’inventaire qui les alimente.
La veille complète ce socle. En France, les avis et alertes publiés par le CERT-FR signalent les vulnérabilités notables et les campagnes d’exploitation en cours ; leur suivi est souvent la première brique de la démarche. Le renseignement sur la menace affine cette lecture en indiquant quelles failles les attaquants exploitent réellement contre le secteur d’activité de l’organisation.
D’autres signalements arrivent de l’extérieur. Un chercheur peut remonter une faille par un programme de bug bounty ou une politique de divulgation coordonnée ; ces canaux couvrent des vulnérabilités propres à l’organisation, que ni scanner ni bulletin ne détecteront.
Le score CVSS : ce qu’il mesure, ce qu’il ignore
Publié et maintenu par le FIRST, le Common Vulnerability Scoring System attribue à chaque vulnérabilité un score de 0 à 10 à partir de ses caractéristiques intrinsèques : conditions d’exploitation, comme le vecteur d’accès, les privilèges requis ou la nécessité d’une action de l’utilisateur, et conséquences possibles sur la confidentialité, l’intégrité et la disponibilité du système touché. Ce langage commun permet à un éditeur, un CERT et une équipe interne de parler de la même chose.
Le score de base s’arrête pourtant à la sévérité technique. La criticité métier de l’actif concerné, son exposition réelle ou l’existence d’un code d’exploitation n’entrent pas dans son calcul ; le FIRST rappelle d’ailleurs que CVSS mesure une sévérité et non un risque. Une faille au score maximal sur un serveur de test isolé peut peser moins lourd qu’une faille de sévérité moyenne sur un système de paiement exposé.
Prioriser avec d’autres critères que le score
Deux vulnérabilités notées à l’identique n’appellent presque jamais le même traitement. L’exposition de l’actif vient en premier : accessible depuis Internet, joignable depuis le seul réseau interne, ou isolé dans un segment contrôlé. Vient ensuite l’exploitation constatée : la CISA publie un catalogue des vulnérabilités effectivement exploitées, qu’elle assortit d’échéances de correction pour les agences fédérales américaines ; beaucoup d’équipes s’en servent comme signal de priorisation, au même titre que les alertes du CERT-FR. Le FIRST propose de son côté EPSS, un modèle qui estime la probabilité qu’une vulnérabilité soit exploitée à court terme.
Reste la dimension métier : une même faille ne pèse pas d’un poids égal selon que l’actif porte un traitement critique ou un service secondaire. Cette pondération rejoint l’appréciation du risque cyber menée par ailleurs — l’ordre des corrections traduit, en pratique, la hiérarchie des risques de l’établissement.
Du correctif à l’acceptation du risque
Quand un correctif existe, son application reste le traitement de référence. Elle se heurte néanmoins aux contraintes d’exploitation — fenêtres de maintenance, tests de non-régression, systèmes qui tolèrent mal l’interruption — et les équipes planifient en conséquence, en réservant les procédures d’urgence aux failles activement exploitées.
Faute de correctif applicable à brève échéance, des mesures compensatoires réduisent l’exposition : filtrage réseau, désactivation de la fonction vulnérable, cloisonnement de l’actif, surveillance renforcée. Le SOC concentre alors sa détection sur les tentatives d’exploitation attendues, que les outils EDR et XDR peuvent repérer sur les postes et les serveurs. Si l’exploitation est avérée, le sujet change de nature et bascule vers l’équipe de réponse à incident, CSIRT ou CERT.
Troisième issue possible, l’acceptation : l’organisation choisit de ne pas traiter, parce que le coût de la correction dépasse l’enjeu ou que la faille n’est pas exploitable dans son contexte. La décision se documente — périmètre, justification, propriétaire, date de réexamen — et ce qui subsiste s’enregistre comme risque résiduel, réexaminé à échéance régulière.
Piloter l’effort dans la durée
Le pilotage du dispositif s’appuie sur quelques indicateurs couramment suivis par les équipes :
- délai de correction constaté, rapporté aux objectifs que l’organisation s’est fixés par niveau de criticité et d’exposition ;
- taux de couverture des scans, rapporté à l’inventaire de référence ;
- âge des vulnérabilités encore ouvertes, qui matérialise la dette accumulée ;
- part des acceptations et dérogations en attente de réexamen.
Ces chiffres supposent un inventaire fiable : un délai moyen calculé sur un périmètre incomplet donne une image faussement rassurante de l’état du parc. Dans la durée, les revues régulières avec les propriétaires d’actifs contribuent au moins autant que le tableau de bord à maintenir l’effort de correction.
Questions fréquentes sur la gestion des vulnérabilités
Quelle différence entre gestion des vulnérabilités et test d’intrusion ?
Le test d’intrusion est un exercice borné dans le temps, où des spécialistes cherchent à démontrer un chemin d’attaque en profondeur sur un périmètre donné. La gestion des vulnérabilités travaille en continu et en largeur, avec un objectif d’exhaustivité sur le parc. Les deux se complètent : un rapport de test alimente le processus, qui oriente en retour les périmètres à tester.
Un score CVSS critique impose-t-il une correction immédiate ?
Non, aucun automatisme ne s’applique : le score qualifie la sévérité technique de la faille, pas l’urgence de son traitement dans un contexte donné. La décision tient compte de l’exposition de l’actif et de sa criticité métier, ainsi que des signes d’exploitation active ; c’est la politique interne de l’organisation qui fixe, sur cette base, les cas justifiant une procédure de correction accélérée.
Que faire lorsqu’aucun correctif n’est disponible ?
Les éditeurs diffusent parfois des mesures de contournement avant la version corrigée, et les avis du CERT-FR recensent ces palliatifs pour les vulnérabilités marquantes. À défaut, l’objectif devient de rendre la faille inexploitable dans le contexte de l’organisation, en limitant l’accès à l’actif et en surveillant les tentatives d’exploitation. Le cas des systèmes en fin de support, pour lesquels aucun correctif ne viendra, se traite de la même manière, dans l’attente de leur remplacement.
Qui porte ce processus dans l’organisation ?
La coordination revient le plus souvent à l’équipe sécurité, mais l’application des correctifs relève des équipes d’exploitation et des propriétaires d’applications ; l’acceptation d’un risque engage, elle, la ligne managériale concernée. Les arbitrages remontent aux instances de gestion des risques lorsque les positions divergent, notamment sur les dérogations de longue durée.
