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

La gestion des vulnérabilités (vulnerability management) est le processus qui va de la découverte d'une faille à la preuve qu'elle est refermée. Le scan n'en est que le point de départ, et la plupart des guides s'arrêtent là, avec des chiffres d'illustration. Cet article part d'une vraie sortie de scan, celle de notre propre plateforme EASM, et montre ce qu'il faut en faire : sur 28 findings annoncés "critiques", quatre tiennent au tri.

La sortie est reproduite telle que l'outil l'a rendue, bruit compris. Aucun scanner ne produit que des résultats justes, et c'est dans le traitement de ce bruit que le processus fait son travail.

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

Un scanner de vulnérabilités produit une liste de failles potentielles à un instant donné. La gestion des vulnérabilités est la chaîne qui transforme cette liste en risque maîtrisé, et elle boucle, parce que le périmètre et le catalogue des failles bougent en permanence : plus de 40 000 CVE publiées en 2024 selon les données CVE, soit plus d'une centaine par jour.

Le reste de l'article porte sur la phase 2, l'évaluation, parce que c'est celle qu'on saute le plus souvent et celle qui décide de la qualité de tout ce qui suit.

À quoi ressemble une sortie de scan brute

Sur les cinq domaines déclarés, les scans ont relevé 616 findings (577 ouverts, 39 passés "corrigés") et inventorié 2 267 actifs, dont 41 seulement portent au moins un finding. Réparti par sévérité telle que l'outil l'annonce :

La sévérité n'est qu'une moitié de l'information. L'autre moitié, c'est le niveau de confiance que l'outil attache lui-même à chaque constat, et il est sans ambiguïté :

Trois findings prouvés sur 616. C'est normal pour un scan de surface, et c'est pourquoi on ne corrige pas une liste brute dans l'ordre de ses couleurs.

Trier les 28 critiques : il en reste quatre

Prenons les 28 critiques un par un, preuve en main. Quatre familles de bruit apparaissent, et chacune se retrouve dans n'importe quel outil de détection.

Les findings dérivés recomptent les autres

Onze critiques ne sont pas des constats mais des agrégats : quatre fiches de priorisation KEV/EPSS, trois fiches de conformité (NIS2 art. 21(2)(a) et (e), CRA annexe I), deux chaînes d'attaque, une corrélation de risque et un enrichissement de onze findings de version. Chacun reprend des findings déjà présents dans la liste. Dix des onze sont en plus rattachés à l'actif ginandjuice.shop, y compris quand la CVE citée a été relevée sur rest.vulnweb.com ; le onzième, une chaîne d'attaque, l'est à preview.owasp-juice.shop:443. Ils servent au tableau de bord, mais les traiter comme des tickets revient à compter deux fois les mêmes findings.

Un 200 OK n'est pas un fichier

Neuf critiques annoncent un fichier sensible exposé : sept fichiers Terraform ou Pulumi (staging.tfvars, prod.tfvars, Pulumi.prod.yaml…) et une configuration CI/CD sur Juice Shop, plus un endpoint Spring Boot /actuator/jolokia sur BrokenCrystals. La preuve enregistrée par l'outil suffit à les écarter (sortie raccourcie) :

GET https://preview.owasp-juice.shop:443/staging.tfvars -> HTTP 200

<!--
  ~ Copyright (c) 2014-2026 Bjoern Kimminich & the OWASP Juice Shop contributors.
  ~ SPDX-License-Identifier: MIT
  -->

<!doctype html>
<html lang="en" data-beasties-container>
<head>
  <meta charset="utf-8">
  <title>OWASP Juice Shop</title>
  …

Ces applications sont des single-page apps : le serveur renvoie la page HTML de l'application, avec un code 200, pour n'importe quel chemin inconnu. Le détecteur a vu le 200 et la bonne extension, pas le contenu. Le même mécanisme produit les douze findings élevés "flux de debug exposé" (/admin/stream, /metrics/stream…), qui renvoient tous la page HTML. Un test de contrôle suffit à les repérer : demander un chemin qui n'existe certainement pas et comparer la réponse.

Un même fichier, deux actifs

Le fichier db.sql de rest.vulnweb.com (317 octets, servi en application/x-sql) apparaît deux fois, sur les actifs rest.vulnweb.com:80 et rest.vulnweb.com:80/http, qui désignent le même service. L'un est marqué corrigé, l'autre ouvert. Le phénomène dépasse les critiques : le seul info.php du même hôte produit huit findings, venus de cinq détecteurs, et l'absence d'en-tête CSP en produit sept sur quatre hôtes. En dédoublonnant à clé stricte (même actif à ce suffixe près, même titre, même première ligne de preuve), les 616 findings tombent à 572.

La CVE déduite d'une bannière

Trois critiques visent testasp.vulnweb.com sur la seule foi de son en-tête Server: Microsoft-IIS/8.5. Le plus spectaculaire porte même le drapeau KEV, "activement exploitée" :

Detected microsoft-iis/8.5 (banner: 'status=200 OK; server=Microsoft-IIS/8.5;
x-powered-by=ASP.NET'). Affected versions: < 10.0.17763 [KEV: actively exploited]

La CVE en question, CVE-2021-31166, touche la pile HTTP (http.sys) de Windows 10 et Windows Server en versions 2004 et 20H2. IIS 8.5 est livré avec Windows Server 2012 R2, qui n'est pas concerné. La règle compare un numéro de version d'IIS à un numéro de build de Windows : le lien est faux, et le drapeau KEV, exact pour la CVE, ne dit rien de cet actif. Les deux autres CVE du lot reposent sur la même bannière et n'ont pas davantage de preuve. Sur ce serveur, le vrai sujet est ailleurs : un système en fin de support, qui relève du patch management et d'une migration, pas d'une alerte critique.

Restent quatre constats dont la preuve est dans la réponse du serveur : un config.json qui livre des identifiants de base de données, y compris un bloc "production", une chaîne de connexion à la base dans le JavaScript client, le db.sql, et un .env Laravel. Même ces quatre-là demandent une lecture : le .env ne contient aucun secret (APP_KEY et DB_PASSWORD sont vides), il descend d'un cran.

Le tri joue aussi dans l'autre sens. Un /.svn/wc.db exposé sur BrokenCrystals, un fichier SQLite de 1 004 Ko dont l'outil a vérifié la signature, est classé "élevé". C'est la base du dépôt Subversion, donc potentiellement le code source et son historique : il mérite davantage que les sept faux fichiers Terraform classés au-dessus de lui.

Prioriser par exploitabilité, pas par sévérité brute

Une fois le bruit retiré, reste à ordonner. Le CVSS mesure le dégât si la faille est exploitée, pas la probabilité qu'elle le soit. Près de la moitié des CVE publiées dépassent 7 : une politique "on traite tout ce qui est ≥ 7" désigne prioritaire près de la moitié du flux mondial, alors que, selon le FIRST, 2,5 à 3 % des CVE publiées montrent une activité d'exploitation sur une fenêtre de 30 jours. Savoir calculer un score CVSS reste utile, à condition de le compléter par trois signaux.

L'EPSS donne la probabilité d'exploitation d'une CVE à 30 jours, recalculée chaque jour. Le catalogue KEV de la CISA liste les failles dont l'exploitation est avérée (1 484 CVE fin 2025), c'est par là qu'une faille zero-day devient visible une fois repérée. Et l'exposition de l'actif, joignable depuis Internet ou non, porteur d'une donnée sensible ou non, est le seul des trois que vous seul connaissez. Un cas comme wp2shell (CVE-2026-63030), RCE pré-authentifiée passée en quelques jours de publiée à activement scannée, coche les trois.

Notre export montre la limite de ces signaux quand on les branche sur des constats non vérifiés. Cinq findings portent le drapeau KEV : quatre fiches dérivées et le faux lien IIS. Le catalogue KEV/EPSS embarqué datait par ailleurs de 196 jours au moment des scans, ce que l'outil signale lui-même dans un finding dédié. Et la file de priorités de l'outil place douze entrées ex aequo en tête, au même score de 8,6 : dix agrégats, qui ne sont pas des tickets, et les deux findings confirmés par le pentest. Un signal d'exploitation ne vaut que ce que vaut la correspondance de version en dessous. Le score global du tableau de bord (100, moins 8 par critique, 3 par élevé, 1 par moyen) tombe à 0 sur 100 pour la même raison : il compte le bruit avec le reste.

La règle qui en découle tient dans un tableur, avant tout outil :

Ce que le processus doit faire de cette sortie

Confirmer avant d'assigner. Les trois findings confirmés du jeu viennent du module de pentest, sur ginandjuice.shop : une pollution de prototype côté client dont la clé __proto__ atteint un setAttribute("href"), donc une XSS DOM, et une manipulation de lien exécutée dans un vrai navigateur. Pour les constats qui en valent la peine, la preuve vient d'un pentest web blackbox, ou d'une vérification manuelle ciblée ; la frontière entre les deux approches est détaillée dans pentest, scan de vulnérabilité ou EASM.

Tenir l'inventaire. Sur les 2 111 sous-domaines inventoriés, 2 106 n'ont pas été déclarés, et 2 079 se trouvent sous un seul sous-domaine de BrokenCrystals, dont l'origine (DNS joker, journaux de certificats ou DNS passif) n'est pas établie. Un inventaire qui gonfle sans dire d'où viennent ses entrées ne se priorise pas mieux qu'une liste de findings. Le shadow IT existe, mais chaque actif découvert doit pouvoir justifier sa présence et recevoir un propriétaire.

Vérifier avant de clore. Des 39 findings "corrigés", une partie peut venir d'une réconciliation automatique (un scan postérieur ne reproduit pas le constat) plutôt que d'une correction. Le db.sql est à la fois corrigé et ouvert selon l'actif qu'on regarde. Seul un contrôle qui rejoue la preuve d'origine autorise la clôture, et c'est ce que formalise un plan de remédiation, construit sur ce même jeu de données.

Commencer plus tôt. Les secrets du JavaScript client et les fichiers de configuration déployés auraient pu être arrêtés dans la chaîne de build, avant d'atteindre la surface d'attaque. C'est le rôle de l'analyse de code, détaillée dans SAST, DAST, IAST et IA. Et pour les entités concernées par NIS2, ce processus doit en plus pouvoir se démontrer.

Si vous voulez voir votre propre sortie brute, bruit compris, c'est ce que produit notre surveillance de la surface d'attaque externe, avec la preuve enregistrée de chaque constat pour que le tri se fasse sur pièces. Pour en parler avec la personne qui a fait ce tri, la page contact est là.

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