Un scanner de vulnérabilité open source examine des systèmes informatiques pour repérer des failles de sécurité déjà documentées. Il aide les équipes à découvrir des logiciels obsolètes, des configurations vulnérables et des services exposés avant qu’ils ne deviennent des points d’entrée.
Son utilité dépend toutefois du périmètre analysé et de la qualité des informations disponibles. Pour comprendre ce qu’il protège réellement, il faut distinguer les contrôles automatisés, les risques qu’ils révèlent et les limites qu’ils ne peuvent pas dépasser.
A retenir :
- Détection automatisée des vulnérabilités connues et des versions exposées
- Surveillance des serveurs, équipements réseau, conteneurs et dépendances logicielles
- Priorisation des corrections selon la gravité et le contexte d’exploitation
- Complément nécessaire pour les failles applicatives complexes et les tests humains
Scanners de vulnérabilité open source : fonctionnement et périmètre
Cette première distinction permet de comprendre ce qu’un scanner peut effectivement observer sur un réseau ou dans un logiciel. Contrairement à un inventaire manuel, l’outil automatise la comparaison entre les éléments détectés et des références de vulnérabilités connues.
Détection des CVE et logiciels obsolètes
Dans le périmètre d’un scan, l’identification des versions constitue souvent le premier indice exploitable par l’équipe sécurité. L’outil repère les systèmes, services et composants, puis rapproche leurs versions des CVE, références publiques décrivant des vulnérabilités connues.
Selon le programme CVE, ces identifiants facilitent la reconnaissance commune des vulnérabilités publiées, mais ils ne prouvent pas à eux seuls qu’une faille est exploitable. Par exemple, un serveur utilisant une version vulnérable d’un composant peut être signalé, même si une configuration particulière réduit son exposition.
Le rapport regroupe généralement les résultats par machine ou par anomalie et leur associe une sévérité. Les équipes peuvent alors examiner les correctifs disponibles, vérifier les faux positifs et ordonner les interventions sans traiter chaque alerte de la même manière.
Équipements réseau, ports ouverts et configurations vulnérables
Au-delà des serveurs, un scan peut couvrir des routeurs, des pare-feu, des commutateurs et certains firmwares. Selon le type d’outil et les droits accordés, il peut relever des versions anciennes, des paramètres risqués ou des services inutilement accessibles.
Un scanner de ports, comme Nmap, indique surtout quels ports ouverts répondent sur une machine et quels services semblent les utiliser. Un scanner de vulnérabilités va plus loin en confrontant les services détectés à des failles connues et à des contrôles de configuration.
Cette différence compte lorsqu’une entreprise veut mesurer son exposition, plutôt que simplement dresser une carte de son réseau. Le tableau suivant montre comment les principaux types de scan se complètent, avant d’aborder les risques applicatifs qu’ils couvrent moins bien.
Périmètres des scans réseau :
Type d’analyse
Éléments observés
Résultat attendu
Limite fréquente
Scan de ports
Ports ouverts et services visibles
Inventaire de l’exposition réseau
Ne confirme pas seul une vulnérabilité
Scan réseau de vulnérabilités
Versions, services et configurations
Failles connues et alertes priorisées
Dépend des signatures et informations recueillies
Analyse de dépendances
Bibliothèques et composants logiciels
Composants associés à des CVE
Contexte d’utilisation parfois à vérifier
Audit de configuration
Paramètres système ou cloud
Écarts par rapport aux règles définies
Ne couvre pas tous les défauts du code
Failles de sécurité détectées et limites des scanners
Une fois les équipements et composants recensés, l’enjeu devient la nature des faiblesses détectables. Le niveau de couverture varie selon que l’outil examine une infrastructure, une application web, une image de conteneur ou du code source.
Mauvaises configurations réseau et services exposés
Dans l’analyse d’infrastructure, les scanners peuvent signaler des protocoles dépassés, des services exposés ou des paramètres de sécurité insuffisants. Ils peuvent également relever des mots de passe par défaut lorsque leurs vérifications et les autorisations de scan le permettent.
Ces constats aident à réduire les risques d’accès non autorisés et de fuites de données, notamment lorsqu’un service sensible reste accessible depuis Internet. Selon le NIST, l’identification et la gestion des vulnérabilités s’inscrivent dans une démarche continue de maîtrise des risques.
Les alertes doivent cependant être interprétées dans leur contexte : une vulnérabilité signalée n’est pas toujours directement exploitable. L’exposition réelle, les protections en place et la disponibilité de correctifs déterminent la priorité de traitement.
Contrôles d’infrastructure fréquents :
- Versions logicielles associées à des vulnérabilités publiées
- Services accessibles et ports ouverts sans justification métier
- Paramètres réseau risqués sur routeurs et pare-feu
- Composants obsolètes dans les systèmes et images de conteneurs
Injections SQL, scripts intersites et défauts applicatifs
Dans le domaine web, les scanners spécialisés recherchent des faiblesses comme les injections SQL ou les scripts intersites. Selon l’OWASP, ces catégories figurent parmi les risques importants à prendre en compte dans la sécurité des applications.
Un scanner d’infrastructure classique ne teste pas toujours ces comportements applicatifs, surtout lorsque les failles dépendent d’un parcours utilisateur ou d’une logique métier particulière. Une analyse web dédiée, une revue de code ou un test d’intrusion peuvent alors compléter le diagnostic.
Les outils d’analyse de composition logicielle, eux, examinent les bibliothèques et dépendances, parfois dans le code ou les fichiers binaires. Le tableau ci-dessous distingue ces usages afin d’éviter de confondre détection de composants vulnérables et test complet d’une application.
Failles et méthodes d’analyse :
Risque recherché
Approche adaptée
Exemple de résultat
Vérification utile
Logiciel associé à une CVE
Scan de vulnérabilités ou analyse de dépendances
Version potentiellement vulnérable
Confirmer la version et l’exposition
Configuration système faible
Audit de configuration
Paramètre contraire à une règle définie
Vérifier le contexte opérationnel
Injection SQL
Test de sécurité applicatif
Entrée pouvant modifier une requête
Tester sans perturber les données
Scripts intersites
Analyse web et tests ciblés
Contenu injecté dans une page
Évaluer les protections côté navigateur
Choisir et utiliser un scanner open source efficacement
Comme les outils ne couvrent pas tous les mêmes faiblesses, le choix dépend d’abord des actifs à protéger et des compétences disponibles. Une petite équipe peut commencer par un périmètre limité, puis intégrer les contrôles dans ses opérations régulières.
Comparer OpenVAS, Nmap et les outils spécialisés
Pour une organisation qui souhaite analyser ses équipements réseau, Greenbone Community Edition, historiquement associé à OpenVAS, constitue une option open source à évaluer. Nmap est utile pour cartographier les ports et services, mais ne remplace pas à lui seul un scanner qui associe des failles aux versions détectées.
Selon le périmètre, une équipe peut ajouter un outil d’analyse de dépendances ou un scanner web spécialisé. Le choix doit tenir compte de la fréquence des mises à jour, de la qualité des signatures, de la facilité d’exploitation des rapports et des besoins d’intégration.
Critères de sélection opérationnels :
- Compatibilité avec les systèmes et équipements réellement utilisés
- Actualisation régulière des signatures et références de vulnérabilités
- Rapports compréhensibles et priorisation adaptée aux risques
- Possibilité de scanner sans perturber les services de production
Planifier les scans et corriger les vulnérabilités
Dans une démarche de gestion continue, les scans gagnent à commencer tôt dans le cycle de développement et à se répéter après les changements importants. Une équipe DevSecOps peut, par exemple, vérifier les dépendances avant livraison, puis examiner les services déployés en production.
Selon les recommandations de l’OWASP, la sécurité applicative demande plusieurs contrôles complémentaires, plutôt qu’un unique outil censé tout détecter. Les exploits connus, la gravité, l’accessibilité de l’actif et les mesures compensatoires aident à distinguer les alertes urgentes des risques moins immédiats.
Un résultat de scan n’est donc ni une certification ni la preuve qu’un système est invulnérable. C’est un signal exploitable pour décider quoi vérifier, corriger ou surveiller, tandis que les analyses applicatives complètent la couverture des scanners classiques.
Source : NIST, « National Vulnerability Database » ; CVE Program, « About CVE » ; OWASP, « OWASP Top 10 ».
