Scanner de vulnérabilités
Un scanner de vulnérabilités confronte automatiquement vos systèmes à une base de failles connues, CVE et défauts de configuration, et produit une liste priorisée.
Un scanner de vulnérabilités est un outil qui teste automatiquement des systèmes contre une base de failles connues. Il identifie les logiciels et leurs versions, les confronte aux CVE publiées, vérifie une série de défauts de configuration classiques, certificats expirés, services obsolètes, en-têtes manquants, et produit une liste de findings généralement priorisée par score CVSS. C'est l'outil de base de la gestion des vulnérabilités, et son grand mérite est de passer à l'échelle : des milliers d'hôtes couverts en continu, pour un coût marginal.
Ses limites sont tout aussi structurelles. Un scanner ne trouve que ce qu'il connaît : il ne voit ni les failles de logique métier, ni les enchaînements de vulnérabilités, ni les défauts propres à votre application. Il produit aussi des faux positifs qu'il faut trier, et un rapport de scan brut n'a jamais dit si une faille était réellement exploitable dans votre contexte.
Le scanner est donc un complément du test d'intrusion, pas son remplaçant : l'un balaie large et souvent, l'autre creuse profond et prouve. Notre article pentest ou scan de vulnérabilités explique quand utiliser l'un, l'autre, ou les deux.
Ce que les référentiels en exigent
Le scan n'est pas seulement une bonne pratique, il est écrit noir sur blanc dans plusieurs référentiels. La norme PCI DSS impose des scans externes trimestriels réalisés par un prestataire agréé ASV, des scans internes au même rythme, et des tests d'intrusion annuels par-dessus. L'ISO 27001:2022 demande, à la mesure A.8.8, une gestion documentée des vulnérabilités techniques. La directive NIS2 range le traitement et la divulgation des vulnérabilités parmi les mesures attendues à l'article 21.2. Aucun de ces textes ne se satisfait du scan seul : tous demandent la chaîne complète, détection puis priorisation puis correction puis vérification, que déroule notre guide de la gestion des vulnérabilités.
Le faux positif n'est pas le vrai problème
On reproche toujours aux scanners leurs faux positifs. Le sujet plus grave est le faux négatif silencieux : un scan authentifié dont les identifiants ont expiré depuis trois mois, une application derrière un portail SSO que l'outil n'a jamais franchi, une API qui n'apparaît dans aucun parcours de crawl. Le rapport revient propre, et personne ne se demande ce qu'il n'a pas regardé. Avant de discuter du bruit, vérifiez la couverture : comparez la liste des cibles effectivement scannées à l'inventaire réel des actifs exposés. L'écart est presque toujours la partie intéressante, et notre comparatif des scanners de vulnérabilité explique quel outil couvre quoi.
Questions fréquentes
Un scanner peut-il casser un système en production ?
Oui, et c'est une raison d'annoncer les fenêtres de scan. Les tests intrusifs, envoi de payloads et énumération lourde, peuvent saturer un service fragile ou remplir des tables de journalisation. Les modes non intrusifs existent, au prix d'une détection moins fiable.
Faut-il un scan authentifié ?
Pour l'interne, oui : sans compte, l'outil ne voit que la bannière du service et manque l'essentiel des correctifs absents. Pour l'externe, le scan non authentifié reflète mieux ce qu'un attaquant sans compte peut réellement atteindre.
Le scan remplace-t-il un test d'intrusion ?
Non. Il trouve à grande échelle les failles connues et publiées. Il ne trouve ni les défauts de logique métier, ni les enchaînements de vulnérabilités, ni les problèmes de contrôle d'accès propres à votre application, qui sont justement ce qu'un attaquant motivé cherche.