Scanner de vulnérabilité : quel outil pour
quel besoin

Un scanner de vulnérabilité compare un état observé à une base de connaissances. Il relève une version, une bannière, une empreinte, un fichier de dépendances ou une configuration, il cherche la correspondance dans un catalogue de failles publiées, et il restitue les concordances. C'est mécaniquement tout ce qu'il fait. Le reste, la question de savoir si la faille est atteignable, déclenchable, et si elle mène quelque part, sort de son mandat.

L'étiquette "scanner de vulnérabilité" recouvre au moins cinq familles d'outils, qui ne regardent pas la même chose, ne prennent pas la même entrée et ne ratent pas les mêmes angles morts. Un scanner réseau ne verra jamais une dépendance npm vulnérable. Un scanner de dépendances ne verra jamais un port d'administration ouvert au monde. Acheter l'un en croyant couvrir l'autre, c'est le budget dépensé pour un angle mort qui reste entier. On se trompe rarement de produit ; on se trompe de famille.

Ce qu'un scan de vulnérabilité fait, mécaniquement

Quel que soit le domaine, la chaîne est la même en quatre temps. On fournit des cibles. L'outil prend une empreinte de ce qui tourne. Il confronte cette empreinte à un référentiel de failles connues, le plus souvent adossé aux CVE et aux données de la NVD du NIST. Il produit un rapport trié par sévérité. Le maillon fragile n'est pas le moteur, il est aux deux extrémités : la liste de cibles en entrée, et le tri humain en sortie.

Deux conséquences pratiques découlent de ce schéma, et elles reviennent dans chaque famille d'outils. La première : un scanner est aveugle à ce qu'on ne lui a pas donné, ce qui déplace le vrai sujet vers l'inventaire. La seconde : un verdict par concordance produit mécaniquement des faux positifs, puisqu'une version affichée ne dit rien de la configuration réelle.

Les cinq familles d'outils de scan de vulnérabilité

Le scanner réseau et système

C'est l'ancêtre de la catégorie, et ce que la plupart des gens ont en tête quand ils disent "scan de vulnérabilité". OpenVAS (le moteur de la suite Greenbone, open source), Nessus chez Tenable, Qualys ou InsightVM chez Rapid7 partent d'une plage d'adresses, énumèrent les ports et les services, puis testent des milliers de contrôles contre ce qui répond.

Leur vraie ligne de partage n'est pas la marque, c'est le mode : authentifié ou non. Un scan non authentifié voit ce qu'un inconnu voit depuis l'extérieur, donc surtout des bannières, et il se trompe beaucoup. Un scan authentifié se connecte à la machine, lit l'inventaire de paquets et l'état de configuration : il divise le bruit par un facteur considérable, mais il suppose des identifiants distribués, gérés et surveillés sur tout le parc. Beaucoup d'organisations achètent la licence et n'installent jamais cette partie-là, puis s'étonnent du taux de faux positifs.

Le scanner de vulnérabilité web

Ici, la cible n'est plus un hôte mais une application. Le scanner explore les URL, soumet des formulaires, injecte des charges et observe les réponses : on est dans le test dynamique, le DAST. Côté gratuit, ZAP (l'ancien OWASP ZAP) et Nuclei et ses gabarits communautaires en YAML couvrent énormément de terrain. Côté payant, le scanner de Burp Suite Professional, Acunetix ou Invicti se vendent sur la qualité du crawl et la profondeur des contrôles.

Le point qui décide vraiment de la couverture n'est jamais mis en avant sur les fiches produit : c'est la capacité du crawler à rester authentifié et à atteindre le fond de l'application. Une application moderne cache l'essentiel de sa surface derrière un login, un jeton qui expire, un rendu côté client et parfois une deuxième étape de vérification. Si le scanner perd sa session au bout de trois minutes, il vous rend un rapport très propre sur la page de connexion et sur rien d'autre. Vérifiez cela avant la liste de CVE détectées.

Le scanner de dépendances

Le SCA (Software Composition Analysis) ne teste rien : il lit vos manifestes et vos verrous de dépendances (package-lock.json, go.sum, pom.xml), résout l'arbre transitif et le confronte à des bases d'avis. Trivy, Grype, OSV-Scanner ou Dependabot font ce travail, y compris sur les images de conteneurs.

C'est la famille la moins chère à mettre en place et la plus rentable à court terme, parce qu'elle tourne dans la CI et qu'elle attrape des failles que personne n'a introduites en écrivant du code. C'est aussi la plus bruyante du lot : une CVE dans une bibliothèque présente dans votre arbre ne signifie pas que la fonction vulnérable est appelée par votre application. Les outils qui savent raisonner sur l'atteignabilité du code vulnérable changent l'ordre de grandeur du tri. Cette famille se documente naturellement par un SBOM, l'inventaire de vos composants, qui devient le référentiel commun entre développeurs et sécurité.

Le scanner d'infrastructure cloud et IaC

Sur du cloud, ce qui est réellement exploitable tient rarement à une CVE. Un bucket de stockage lisible par tout le monde, un rôle qui a hérité d'une politique trop large, un groupe de sécurité ouvert en 0.0.0.0/0 sur un port d'administration, une clé sans rotation depuis trois ans : ces défauts se lisent dans l'API du fournisseur, et nulle part sur le réseau.

Prowler et ScoutSuite interrogent le compte en lecture et évaluent des centaines de contrôles de configuration. Checkov et consorts font le même travail plus tôt, sur le Terraform, avant que la ressource n'existe. Un scanner réseau classique passe à côté de la totalité de cette catégorie, tout simplement parce qu'il n'y a aucun paquet à envoyer pour constater qu'un rôle IAM est trop permissif.

La découverte externe continue

Dernière famille, et la seule qui ne commence pas par une liste de cibles : l'EASM, la gestion de la surface d'attaque externe. Le point de départ est un nom de domaine racine ou une marque, et l'outil remonte le fil des sources publiques (journaux de Certificate Transparency, DNS, moteurs d'indexation de services) pour reconstituer ce que vous exposez, y compris ce que votre inventaire ignore. Il qualifie ensuite ces actifs et surveille leurs changements. La mécanique complète est détaillée dans la découverte d'actifs étape par étape.

Un EASM ne remplace aucune des quatre familles précédentes. Il résout le problème situé en amont de toutes : alimenter leur entrée. Le sous-domaine de recette laissé en ligne depuis 2022 n'est dans aucune plage fournie au scanner réseau, dans aucun pipeline CI, dans aucun compte cloud audité. Il est simplement joignable.

  FAMILLE              ENTREE REQUISE         CE QU'ELLE VOIT            ANGLE MORT PRINCIPAL
  ------------------   --------------------   ------------------------   ------------------------
  Reseau / systeme     plages IP, hotes       services, versions,        applicatif, cloud,
                       (+ identifiants)       correctifs manquants       actifs non listes
  Web (DAST)           URL de depart          injections, config web,    logique metier, droits
                       (+ session valide)     comportements a l'exec     entre comptes, chainage
  Dependances (SCA)    depot, image,          CVE des bibliotheques      code que vous ecrivez,
                       manifeste              directes et transitives    atteignabilite reelle
  Cloud / IaC          acces API en lecture   droits trop larges,        vulnerabilites logicielles
                       ou code Terraform      exposition, chiffrement    dans les charges de travail
  Decouverte externe   un nom de domaine      actifs oublies, shadow IT, profondeur d'exploitation,
  (EASM)               ou une marque          exposition qui bouge       perimetre interne

Ce qu'un scanner de vulnérabilité ne trouvera jamais

Cette liste ne relève pas de l'immaturité des outils, qu'une prochaine version corrigerait. Elle découle de la définition : on ne peut pas écrire la signature d'un défaut qui n'existe que par rapport à l'intention du logiciel.

• La logique métier. Un bon de réduction cumulable qui fait tomber le panier à zéro, un virement dont le montant est validé côté client, un statut de commande modifiable après paiement. Le serveur répond 200 OK et aucun motif n'est violé : pour le scanner, tout va bien. Seul quelqu'un qui comprend ce que le processus est censé faire peut voir le problème.
• Le contrôle d'accès horizontal. Vous êtes authentifié, vous changez un identifiant dans l'URL, vous lisez le dossier de quelqu'un d'autre. Détecter cela suppose deux comptes de test, de savoir quelles données appartiennent à qui, et de comparer ce qui aurait dû être refusé. Un scanner ne possède ni les comptes ni cette notion de propriété : c'est pourquoi cette catégorie reste en tête des classements de risques applicatifs alors que tout le monde scanne.
• Le chaînage. Un service de fichiers en lecture, un fichier de configuration avec un mot de passe de recette, une réutilisation de ce mot de passe en production. Trois constats classés "faible" ou même non signalés, dont la combinaison donne un accès administrateur. Le scanner note ligne par ligne, il ne compose pas.
• Les défauts sans CVE. Une vulnérabilité dans votre propre code n'a, par construction, aucun identifiant public. Le scan de dépendances couvre le code des autres, jamais le vôtre.
• Ce qui n'est pas dans la liste. L'angle mort le plus fréquent, et le plus banal. Un rapport impeccable sur 40 hôtes ne dit strictement rien des 60 autres que personne n'a inscrits.

Le bruit, les faux positifs et le coût du tri

Le faux positif emblématique tient en une ligne de bannière. Les distributions Linux rétroportent les correctifs de sécurité sans changer le numéro de version amont : un serveur qui annonce nginx/1.18.0 peut être parfaitement corrigé, et un scan non authentifié le classera vulnérable à tout ce qu'a connu la 1.18.0 depuis sa sortie.

# Vu du dehors : le scanner lit une banniere et conclut a la version amont
curl -sI https://exemple.tld/ | grep -i '^server:'
# Server: nginx/1.18.0 (Ubuntu)

# Vu du dedans : le paquet a recu le correctif, le numero amont n'a pas bouge
dpkg -l nginx-core | tail -1
# ii  nginx-core  1.18.0-0ubuntu1.4  amd64  ...

# Le changelog de la distribution tranche : le CVE y est liste comme corrige
apt changelog nginx-core | grep -i -m3 CVE

Le même mécanisme joue dans l'autre sens, et c'est plus embêtant : un module désactivé, une directive de configuration qui neutralise le chemin vulnérable, une bannière volontairement falsifiée, et le scanner rate une faille bien réelle. La concordance de version est un indice, pas une preuve, dans les deux directions.

Vient ensuite la question du tri. Plus de 40 000 CVE ont été publiées sur la seule année 2024, et l'enrichissement de la NVD accuse un retard notable depuis février de la même année, ce qui laisse arriver dans les rapports des entrées sans score ni métadonnées exploitables. Trier ce volume au seul CVSS revient à traiter en priorité des failles que personne n'exploite. Deux signaux valent mieux : l'EPSS, qui estime la probabilité qu'une vulnérabilité soit exploitée dans les trente jours, et le catalogue KEV de la CISA, qui liste ce qui est activement exploité dans la nature. La méthode complète de priorisation est détaillée dans le guide de la gestion des vulnérabilités.

Le scanner s'arrête là. Faire redescendre la file vers les équipes qui corrigent relève d'un plan de remédiation, et décider lesquelles de ces lignes justifient une fenêtre de maintenance en urgence, un correctif virtuel ou une acceptation de risque signée relève du patch management. Un outil de détection qui n'est branché sur aucune de ces deux mécaniques produit un rapport mensuel, pas une réduction de risque.

Scan de vulnérabilité gratuit : ce qu'on obtient vraiment

La réponse honnête est : beaucoup. Chacune des quatre premières familles a son représentant libre, sérieusement maintenu et documenté, et sur le seul critère de la capacité de détection, cet empilement tient la comparaison avec beaucoup d'offres facturées.

Ce qui n'est pas gratuit se trouve autour : héberger et maintenir les scanners, tenir les listes de cibles à jour, distribuer et surveiller les identifiants des scans authentifiés, absorber les mises à jour de flux, et surtout lire les rapports semaine après semaine. Sur un périmètre d'une centaine d'actifs, ce temps humain dépasse rapidement le prix d'une licence. Ce que facturent les offres commerciales, d'ailleurs, tient plus rarement à la détection qu'à ce qui l'entoure : corrélation entre sources, suivi d'un finding dans le temps, exports pour l'audit, intégrations au ticketing. On a décortiqué ces modèles de facturation, abonnement, actif surveillé ou volume, dans combien coûte un EASM.

Choisir son scanner de vulnérabilité : partir de ce qu'on protège

Le meilleur scanner dans l'absolu n'existe pas, et chercher un classement fait perdre le fil. Commencez par situer le risque que vous voulez réduire en premier : cette réponse désigne une famille, la famille laisse trois ou quatre candidats, et le choix final se joue sur l'intégration à ce que vous avez déjà.

Trois questions départagent ensuite les candidats d'une même famille, et aucune ne figure sur une plaquette. Est-ce que l'outil sait ingérer mon inventaire existant sans double saisie ? Est-ce qu'il suit un finding dans le temps : réapparu, corrigé, accepté avec justification, et depuis quand ? Est-ce que je peux sortir mes données au format brut si je change d'avis dans deux ans ? Sur ce dernier point, la grille de tri complète des plateformes du marché est dans notre comparatif des plateformes de gestion de surface d'attaque.

L'angle mort commun : le scan est un instantané

Toutes ces familles partagent une limite de forme. Un scan décrit un état à une date. Or ce qui vous expose bouge sans vous demander votre avis : une équipe publie un sous-domaine mardi, un prestataire ouvre un port pour déboguer et oublie de le refermer, un certificat révèle un nom d'hôte interne, une CVE sort sur un composant que vous n'avez pas touché depuis deux ans. Entre deux scans trimestriels, la surface a changé plusieurs fois, et le rapport que vous avez classé décrit un périmètre qui n'existe plus.

D'où le placement honnête d'un EASM au milieu de cette liste. Il ne creuse pas plus profond qu'un scanner spécialisé et ne prouve rien qu'un humain prouverait. Il tient à jour la seule chose dont tout le reste dépend, la liste de ce qui est joignable depuis Internet, et il fait remonter les écarts au fil de l'eau plutôt qu'au prochain trimestre.

L'EASM d'own2pwn occupe cette place-là et pas une autre : il part de vos domaines, corrèle les CVE sur ce qui répond vraiment, et vous prévient quand la surface bouge. Ses findings sortent d'une chaîne automatique, sans relecture humaine : quand il faut qu'un opérateur confirme et exploite pour de bon, on parle d'un pentest web blackbox, qui se planifie et se facture autrement.

Questions fréquentes sur le scan de vulnérabilité

À retenir

• Un scanner de vulnérabilité compare un état observé à un catalogue de failles connues. Il conclut par concordance, il ne démontre pas l'exploitation.
• Le mot recouvre cinq familles : réseau et système, web (DAST), dépendances (SCA), cloud et IaC, découverte externe. Elles ne prennent pas la même entrée et ne se remplacent pas.
• Cinq catégories échappent structurellement au scan : logique métier, contrôle d'accès entre comptes, chaînage de faiblesses, failles de votre propre code, et tout ce qui n'est pas dans la liste de cibles.
• Le mode authentifié et la capacité du crawler à rester connecté pèsent plus lourd sur le résultat que le nom de l'éditeur. Les bannières de version mentent dans les deux sens, à cause du rétroportage des correctifs.
• Le tri se fait sur l'exploitabilité (EPSS, catalogue KEV), pas sur le CVSS brut. La bonne métrique d'achat reste le nombre de findings réellement corrigés.
• Un scan est un instantané. La surface exposée, elle, change en continu : c'est le trou que comble une découverte externe permanente.

Si le point de départ est "je ne sais pas ce que j'expose", commencer par un scanner classique revient à qualifier très finement une liste incomplète. Cartographiez d'abord, avec l'EASM d'own2pwn ou tout autre outil de découverte, puis prenez la famille que la cartographie désigne. Un périmètre qu'on n'arrive pas à décrire ne se tranche pas dans un tableau comparatif ; il se cadre en le racontant à quelqu'un, ce à quoi sert la page contact.