Gestion des vulnérabilités (vulnerability management) :
le guide

Un rapport de scan qui remonte quatre mille findings, six cents estampillés "critique" avec un CVSS à 9,8, décrit le lundi matin ordinaire d'une équipe sécurité de trois personnes. Face à ce mur, la question "que faut-il corriger ?" n'a qu'une réponse honnête, "tout", et elle ne sert à rien. La seule qui décide de l'exposition de la semaine tient en trois mots : par quoi commencer ?

C'est tout le sujet de la gestion des vulnérabilités(vulnerability management). Lancer un scan n'en est qu'une brique. Le reste est un processus continu qui va de la découverte d'une faille jusqu'à la preuve qu'elle est bien refermée, en passant par l'étape que tout le monde bâcle : décider quoi traiter en premier. Le score CVSS ne suffit plus à trancher cette question, et c'est là que l'EASM et le pentest changent la donne.

La gestion des vulnérabilités n'est pas un scan

Confondre les deux est l'erreur la plus courante, et la plus coûteuse. Un scanner de vulnérabilités produit une liste : une photo, à un instant T, de failles potentielles sur un périmètre. C'est un capteur, rien de plus. La gestion des vulnérabilités, elle, est la chaîne complète qui transforme cette liste en risque maîtrisé : on découvre, on évalue, on priorise, on remédie, on vérifie, et on recommence, indéfiniment, parce que votre système d'information et le catalogue mondial des failles bougent tous les jours.

Pour donner l'échelle : en 2024, plus de 40 000 CVE ont été publiées, soit près de 108 par jour et une hausse de 39 % sur un an, d'après les statistiques du NVD. Une entreprise ne "rattrape" jamais ce flux. Elle le gère. Et gérer, c'est arbitrer, donc prioriser, parce que corriger tout, tout de suite, avec les moyens du bord, relève de la fiction.

Le cycle de vie d'une vulnérabilité

Un processus de gestion des vulnérabilités qui tient la route, c'est cinq étapes qui bouclent. Aucune n'est optionnelle, et la boucle ne s'arrête jamais : la sortie de la dernière étape alimente la première du tour suivant.

Deux phases concentrent presque tout l'enjeu, et ce sont rarement celles qu'on outille en premier. La priorisation, parce qu'elle décide de l'emploi d'une ressource rare (le temps de vos équipes). Et la vérification, parce qu'un correctif non rejoué reste une présomption tant qu'un contrôle ne l'a pas confirmé. On y revient plus loin ; d'abord, il faut comprendre pourquoi la simple sortie d'un scan ne suffit jamais à démarrer.

Pourquoi le scan de vulnérabilité seul ne suffit pas

Le scan de vulnérabilité est indispensable : c'est l'œil qui balaie en continu, à un coût dérisoire par rapport à un audit manuel. Mais un scanner a deux angles morts structurels, et les ignorer fait dérailler tout le processus en aval.

Le premier, ce sont les faux positifs. Un scanner raisonne le plus souvent par signature : il lit une bannière, une version de composant, une empreinte, et en déduit "probablement vulnérable". Sauf que la version affichée peut être un leurre, le correctif rétroporté sans changer le numéro (fréquent sur les paquets Debian/RHEL), ou la fonction vulnérable jamais appelée dans votre configuration. Résultat : une file de remédiation gonflée d'alertes qui n'en sont pas, et une équipe qui finit par se méfier de l'outil, le pire des mondes.

Le second, plus profond : le scanner dit "cette version a une CVE connue", jamais "j'ai exploité cette faille chez vous". Il ne fournit aucune preuve d'exploitabilité. Or entre "théoriquement vulnérable" et "exploitable en une requête depuis Internet", il y a un gouffre : un WAF devant, une authentification requise, une segmentation réseau, une fonctionnalité désactivée. Cette frontière entre détection automatisée et preuve réelle mérite un article à elle seule, on l'a écrit : pentest, scan de vulnérabilité ou EASM détaille qui répond à quelle question.

La priorisation moderne : au-delà du CVSS

Un chiffre devrait recadrer toute stratégie de gestion des vulnérabilités : d'après le FIRST, à peine 5 % de l'ensemble des failles publiées sont un jour exploitées dans la nature. La quasi-totalité des CVE qui défilent ne sera jamais attaquée. Le nerf de la priorisation, c'est de trouver cette minorité qui compte avant qu'un attaquant ne s'en charge.

Un cas récent donne un visage à cette minorité qui compte : wp2shell (CVE-2026-63030), une RCE pré-authentifiée du cœur de WordPress, est passée en quelques jours de "faille publiée" à "faille activement scannée, exploitable sans le moindre compte depuis Internet". Le type même de CVE qu'il faut extraire du bruit et traiter avant l'attaquant.

Le CVSS ne sait pas faire ce tri, et pour une raison de conception : il mesure la gravité potentielle (quel dégât si la faille est exploitée), pas la probabilité qu'elle le soit. C'est un thermomètre de dangerosité, pas une jauge d'urgence. Encore faut-il lire le thermomètre correctement : savoir calculer un score CVSS et distinguer le score de base du score environnemental évite déjà bien des faux "critiques". On le complète ensuite par trois signaux orthogonaux.

EPSS : la probabilité d'exploitation

L'EPSS (Exploit Prediction Scoring System), maintenu par le FIRST, est un modèle d'apprentissage automatique qui attribue à chaque CVE une probabilité, entre 0 et 1, d'être exploitée dans les 30 prochains jours. Là où le CVSS reste figé, l'EPSS se réévalue quotidiennement à partir de signaux réels : publication d'un exploit, activité observée, caractéristiques de la faille. La version EPSS v4, sortie le 17 mars 2025, a nettement affiné le modèle et son suivi en temps réel de l'activité d'exploitation.

L'intérêt est arithmétique, et le FIRST l'a mesuré. Prioriser au CVSS "≥ 7" impose de traiter plus de la moitié des CVE publiées, et l'essentiel de cet effort porte sur des failles qui ne seront jamais attaquées. L'EPSS remplace ce jugement de gravité par un signal empirique d'activité et concentre l'effort là où les attaques sont probables, pour une couverture équivalente à une fraction du travail.

KEV : ce qui est déjà exploité, sans débat

Le catalogue KEV (Known Exploited Vulnerabilities) de la CISA est la liste, mise à jour en continu, des failles pour lesquelles une exploitation avérée a été constatée dans la nature. Ce n'est plus une prédiction : c'est un fait. Le catalogue est volontairement resserré, avec 1 484 CVE fin 2025 (contre 1 239 fin 2024, soit une hausse de 20 % sur l'année), moins de 1 % de tout le NVD. Une CVE qui entre au KEV et qui touche l'un de vos actifs : c'est une alerte non négociable, tout en haut de la file, point. C'est aussi par là qu'arrive une faille zero-day une fois repérée dans la nature, souvent avant même que le correctif existe : le KEV vous dit qu'il faut agir, pas forcément qu'il y a quelque chose à installer.

L'exposition : le contexte que personne d'autre ne connaît

EPSS et KEV sont des signaux mondiaux : ils décrivent la faille dans l'absolu, pas votre situation. Le dernier facteur, c'est le vôtre et lui seul : cet actif est-il exposé sur Internet ou enterré dans un VLAN interne ? Porte-t-il une donnée sensible ? Est-il en production ou dans un bac à sable ? Une CVE critique sur un serveur de test isolé et une CVE moyenne sur votre portail client exposé n'ont pas la même urgence, de très loin.

La priorisation moderne, c'est donc un entonnoir qui combine ces couches pour faire tomber quelques milliers de findings à une poignée d'actions du jour.

Une règle de terrain qui condense tout cela, et qu'on peut coder dans un tableur avant de s'offrir un outil :

Une précision qui fait toute la différence : l'exposition et le CVSS, pris isolément, ne suffisent pas à monter une vulnérabilité en P0. Il faut un signal d'exploitation, le KEV ou l'EPSS, pour justifier l'urgence maximale.

L'apport de l'EASM : prioriser par ce qui est vraiment exposé

Toute cette logique repose sur une donnée que la plupart des organisations maîtrisent mal : qu'est-ce qui est réellement exposé ? On ne priorise bien que ce qu'on connaît, et le périmètre externe d'une entreprise déborde presque toujours son inventaire officiel : sous-domaines oubliés, environnement de préproduction ouvert par erreur, service exposé par un prestataire, actif hérité d'une acquisition. C'est le fameux shadow IT, et c'est justement là que les incidents commencent.

L'EASM (External Attack Surface Management) répond à ce manque : découvrir en continu, du point de vue de l'attaquant, tout ce qui est joignable depuis Internet, puis rattacher les vulnérabilités à ces actifs. La priorisation cesse alors d'être théorique : une faille sur un actif que l'EASM a identifié comme exposé, vivant et non inventorié remonte naturellement, quand la même faille sur un service interne segmenté attend son tour. C'est la couche "exposition" de l'entonnoir, alimentée automatiquement plutôt qu'à la main.

Concrètement, c'est ce que fait notre plateforme EASM : elle cartographie votre surface d'attaque externe en continu et pondère chaque vulnérabilité par son exposition réelle, pour que la file de remédiation reflète le risque du jour, pas un score hors-sol.

L'apport du pentest : prouver l'exploitabilité

L'EASM et les scanners restaurent la couverture et le contexte. Reste le dernier angle mort : la preuve. Un finding priorisé P0 mérite qu'on réponde à la seule question qui engage : est-ce exploitable, chez vous, dans votre configuration ? C'est le métier du test d'intrusion. Là où le scanner s'arrête à "version vulnérable détectée", le pentester enchaîne les étapes, contourne le WAF, chaîne deux failles anodines en une compromission, et vous rapporte une démonstration plutôt qu'une hypothèse.

Cette preuve d'exploitabilité fait deux choses irremplaçables. Elle élimine les faux positifs par le haut, un humain a confirmé, ou infirmé. Et elle requalifie la priorité : une faille jugée moyenne mais qui, chaînée à une autre, donne un accès administrateur, saute en tête de file. Aucun score automatique ne capture ce raisonnement d'attaquant. Pour voir comment cette démonstration s'insère dans un processus, sans opposer les approches mais en les empilant, relisez la comparaison pentest / scan / EASM.

Vulnerability management vs patch management

Les deux termes se croisent souvent, et les confondre fait dérailler l'organisation. La gestion des vulnérabilités est le cycle complet décrit ici : découvrir, évaluer, prioriser, remédier, vérifier, sur toutes les failles, de config comme de code, patchables ou non. Le patch management n'en couvre qu'une étape, la remédiation, et seulement pour les failles qui ont un correctif éditeur. C'est un sous-ensemble, mais c'est là que se jouent les arbitrages les plus durs : fenêtre d'exposition qui se referme en quelques jours, actifs qu'aucun correctif ne couvre, correctif qui casse la production. On détaille cette mécanique dans notre article sur le patch management.

Entre la file priorisée et le correctif déployé, il reste un geste concret : transformer une liste de findings en travail assigné, daté et vérifié. C'est l'objet du plan de remédiation, qui prend chaque finding et lui attache une priorité, un responsable, un délai et un mode de vérification. La priorisation CVSS + EPSS + KEV vue plus haut décide de l'ordre ; le plan de remédiation en fait des tickets qu'on peut suivre jusqu'au retest.

Construire le processus, pas seulement l'acheter

Un bon processus de gestion des vulnérabilités ne se résume pas à une plateforme allumée. Il tient sur quelques décisions organisationnelles qu'aucun outil ne prendra à votre place.

• Un propriétaire par actif. Un finding sans responsable désigné ne sera jamais corrigé. L'inventaire, avant le scan, conditionne tout le reste, c'est la moitié invisible du travail.
• Des SLA de remédiation par niveau de priorité. P0 sous 48 h, P1 sous une semaine, et ainsi de suite. Un délai écrit transforme une intention en engagement mesurable, et donne un critère clair d'escalade. Ces délais sont les vôtres et doivent tenir compte de vos fenêtres de maintenance, de vos actifs qu'aucun correctif ne couvre et de votre capacité de retour arrière : c'est tout le sujet du patch management.
• Une acceptation de risque tracée. Décider de ne pas corriger est parfois légitime (coût, dépendance, faible exposition), mais cette décision doit être documentée, datée et signée. C'est ce qui sépare un arbitrage assumé d'un oubli.
• La vérification comme condition de clôture. Un ticket ne passe "résolu" qu'après un re-test qui prouve la disparition de la faille. Le retest fait partie du cycle ; il n'est pas un bonus.
• Des métriques qui pilotent. Délai moyen de remédiation par criticité, part d'actifs couverts, âge des findings ouverts : sans chiffres, on ne sait pas si le processus s'améliore ou dérive.

Pour beaucoup d'organisations, cadrer ce processus n'est d'ailleurs plus seulement une bonne pratique : c'est une obligation réglementaire (NIS2), qui impose une gestion des risques et des vulnérabilités continue et démontrable. Autant la construire proprement une fois.

À retenir

• La gestion des vulnérabilités est un cycle de vie (découverte → évaluation → priorisation → remédiation → vérification), pas un scan ponctuel. La boucle ne s'arrête jamais.
• Le scan de vulnérabilité est un capteur nécessaire mais aveugle : faux positifs et zéro preuve d'exploitabilité. Il amorce le processus et s'arrête là.
• Le CVSS mesure la gravité, pas l'urgence. Avec plus de la moitié des CVE au-dessus du seuil 7, trier par score seul revient à ne pas trier.
• Prioriser aujourd'hui : CVSS + EPSS (probabilité à 30 jours) + KEV (exploitation avérée) + exposition réelle de l'actif. À peine 5 % des failles sont un jour exploitées : visez celles-là.
• L'EASM alimente la couche exposition (ce qui est vraiment joignable depuis Internet) ; le pentest apporte la preuve d'exploitabilité qui requalifie les priorités.

Vous croulez sous les findings et vous cherchez par où commencer ? C'est ce que fait notre plateforme EASM : prioriser par l'exposition réelle. Et, pour les failles qui comptent, nos pentests web blackbox prouvent l'exploitabilité au lieu de la supposer. Envie d'en parler à un humain ? La page contact est là pour ça.

Questions fréquentes sur la gestion des vulnérabilités