Gestion des vulnérabilités : le guide complet (cycle de vie, priorisation CVSS + EPSS
+ KEV)

Lundi matin, le rapport du scanner atterrit dans votre boîte. Quatre mille findings. Six cents étiquetés « critique », dont une bonne partie en rouge vif avec un CVSS à 9,8. Votre équipe patch fait la moitié de votre équipe sécurité, qui fait elle-même trois personnes. La question n'est pas « que faut-il corriger ? » — la réponse honnête serait « tout », et elle est inutile. La vraie question, celle qui décide de votre exposition réelle cette semaine, c'est : par quoi commencer ?

C'est tout le sujet de la gestion des vulnérabilités(vulnerability management). Pas « lancer un scan » — ça, c'est une brique. Mais 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. Ce guide déroule ce cycle de vie de bout en bout, explique pourquoi le score CVSS ne suffit plus à trancher, et où 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é est un correctif présumé — pas un correctif prouvé. 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 réellement 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

Voici le chiffre qui devrait recadrer toute stratégie de gestion des vulnérabilités : sur l'ensemble des failles publiées, environ 6 % seulement ont été exploitées dans la nature, et sur la seule année 2024, 768 CVE l'ont été pour la première fois — à peine 2 % du cru. La quasi-totalité des failles que vous voyez passer ne sera jamais attaquée. Le nerf de la priorisation, c'est de trouver les 2 à 6 % qui comptent avant qu'un attaquant ne s'en charge.

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. On le complète donc 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. Prioriser au CVSS « ≥ 7 » impose de patcher environ la moitié des CVE connues pour ne couvrir qu'autour de 75 % des failles réellement exploitées : énormément d'effort, peu de rendement. L'EPSS remplace ce jugement de gravité par un signal empirique d'activité, et concentre l'effort là où les attaques sont probables.

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é — de l'ordre de 1 500 CVE fin 2025 (contre 1 239 fin 2024), soit 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.

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 :

FILE DE REMEDIATION — ordre de traitement

  P0  actif EXPOSE  ET  (dans le KEV  OU  EPSS eleve)     -> aujourd'hui
  P1  actif EXPOSE  ET  CVSS >= 7                          -> cette semaine
  P2  actif interne ET  (KEV  OU  CVSS critique)           -> ce mois
  P3  tout le reste                                         -> cycle patch courant

  Nota : "expose" et "CVSS" seuls ne suffisent pas a monter en P0.
         Il faut un signal d'EXPLOITATION (KEV/EPSS) pour 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 exactement à 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 asset 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 vraiment : est-ce réellement 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 non pas une hypothèse mais une démonstration.

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.

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.
• 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 ouvre le processus, il ne le résume pas.
• Le CVSS mesure la gravité, pas l'urgence. Avec 53 % des CVE en « High/Critical », 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. Seulement 2 à 6 % 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 exactement 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.