Scan de vulnérabilités ou test d’intrusion : lequel vous faut-il ?

Deux devis, un rapport de prix de un à cinq, et à première vue la même promesse : « nous identifions vos vulnérabilités ». C’est le moment où la plupart des RSSI s’arrêtent, et c’est un bon réflexe. Les deux lignes ne recouvrent pas la même prestation et ne répondent pas à la même question.

La demande type arrive d’ailleurs presque toujours dans le même état : quelqu’un a lancé un scan, se retrouve avec 340 résultats dont 28 marqués « critique », et ne sait pas par où commencer. La bonne réaction est rarement de traiter les 28. C’est d’établir lesquels signifient réellement quelque chose dans votre environnement.

Cet article sépare trois termes que les devis mélangent, explique ce qu’un scanner trouve et ce qu’il ne peut pas trouver, montre comment lire un score CVSS, et répond à la question que personne ne traite : lequel de ces travaux répond à l’article 32 du RGPD.

Trois termes, trois choses différentes

Le vocabulaire français distingue ce que l’anglais laisse dans le flou, et la confusion coûte cher au moment de comparer deux devis.

Le scan de vulnérabilités est un outil : Nessus, OpenVAS, Nuclei et les autres. Vous l’achetez sous forme d’abonnement, vous le planifiez, il produit une liste.

L’audit de vulnérabilités est une prestation : le passage outillé, puis la vérification humaine, puis la priorisation au regard de votre exposition réelle. C’est le terme que nous employons, et c’est celui que le marché français réserve au service ; « scan » et « analyse » renvoient à l’outil.

Le test d’intrusion (pentest) est une prestation d’une autre nature : on n’y constate pas la présence d’une faille, on démontre ce qu’un attaquant en ferait.

La gestion des vulnérabilités n’est aucune des trois. C’est le processus continu qui les entoure : détecter, enregistrer, prioriser, affecter, corriger, contrôler. Le scan en est une source, l’audit une revue périodique, le test un sondage en profondeur. Qui vous vend une gestion des vulnérabilités en remplacement d’un test d’intrusion vous vend un processus à la place d’un constat.

Le référentiel d’exigences de l’ANSSI applicable aux prestataires d’audit de la sécurité des systèmes d’information — le schéma PASSI, une qualification volontaire que Haxoris ne détient pas — distingue cinq activités d’audit : audit d’architecture, audit de configuration, audit de code source, tests d’intrusion, audit organisationnel et physique. Le scan n’y figure pas comme une activité d’audit. Il est un moyen, pas une prestation, et c’est exactement la distinction que cet article défend.

Comment fonctionne un scan de vulnérabilités

Le déroulement est le même dans tous les outils :

1. Découverte. Quels hôtes répondent, quels ports sont ouverts, quels services tournent derrière.
2. Prise d’empreinte. Quel logiciel et quelle version se cachent derrière chaque service. C’est l’étape sur laquelle tout le reste repose, et celle qui se trompe le plus souvent.
3. Corrélation. La version détectée est confrontée à une base de vulnérabilités publiées, identifiées par leur numéro CVE.
4. Notation. Chaque correspondance reçoit un niveau de gravité, le plus souvent le score de base CVSS repris de la fiche CVE.

Le point décisif tient en une phrase : dans la majorité des contrôles, la vulnérabilité est déduite, pas démontrée. Le scanner lit « nginx 1.18.0 », trouve une fiche CVE qui correspond et la remonte. Il n’a pas vérifié que la faille est atteignable dans votre configuration.

Ce qu’un scan détecte de façon fiable

Cette limite posée, un scanner est excellent dans son domaine, et ce domaine n’a rien d’étroit :

• les composants obsolètes porteurs de CVE connues, sur des centaines de systèmes en une nuit ;
• les erreurs de configuration à signature claire : interfaces d’administration ouvertes, identifiants par défaut, listing de répertoires, points d’entrée de débogage restés actifs ;
• les configurations TLS faibles, les certificats expirés, les versions de protocole obsolètes encore acceptées ;
• les en-têtes de sécurité manquants et les autorisations manifestement trop larges ;
• les écarts par rapport à une référence : ce qui a changé depuis le passage précédent.

C’est précisément le travail qu’un humain ne devrait pas faire : volumineux, répétitif, et source d’erreurs dès qu’il est mené à la main. C’est pour cette raison que notre audit de vulnérabilités commence lui aussi par des passages outillés. Il ne s’y arrête simplement pas.

Sur les équipements dotés de leur propre micrologiciel, la portée d’un scanner réseau s’arrête à la surface de l’appareil : ce qui se trouve en dessous relève d’un test d’intrusion IoT.

Ce qu’un scan ne peut pas trouver

Les classes de constats qui suivent ne sont pas seulement difficiles pour un outil automatisé : elles lui sont structurellement inaccessibles, parce qu’il ignore ce qui devrait être permis dans votre application.

• Défauts d’autorisation. L’utilisateur A voit les commandes de l’utilisateur B. Pour le scanner, c’est une réponse HTTP 200 réussie. Il n’a aucune idée de qui devrait posséder quel enregistrement.
• Défauts de logique métier. Un code de réduction utilisable deux fois. Une étape de commande que l’on peut sauter. Un montant négatif comptabilisé comme un avoir.
• Chaînes de vulnérabilités. Une divulgation d’information anodine, plus une politique de mot de passe faible, plus un compte de test oublié : ensemble, une prise de contrôle complète. Le scanner remonte trois constats de faible gravité et ne voit pas la chaîne.
• Contournement de l’authentification multifacteur par un chemin secondaire, par exemple une API qui n’impose pas le second facteur.
• Fuites de données fonctionnelles. Une interface qui renvoie plus de champs que l’écran n’en affiche : techniquement correcte, et une violation de données personnelles du point de vue du RGPD.

L’exemple qui résume la différence

Une boutique en ligne laisse utiliser deux fois le même code de réduction. Aucune CVE, aucune version obsolète, aucun réglage incorrect : le code fait exactement ce qui a été écrit. Un scanner ne voit rien, et ne peut rien voir : il n’existe pas de base de défauts qui n’existent que dans votre application.

Un testeur muni d’un compte de test et d’une demi-heure le trouve. Il en va de même de l’étape de commande que l’on peut sauter, du virement à montant négatif, et de l’utilisateur qui accède aux données d’un autre en modifiant un identifiant dans l’URL. C’est la raison pour laquelle les deux prestations ne sont pas interchangeables, et la première raison pour laquelle le devis le moins cher n’est presque jamais le même produit que l’autre.

Les faux positifs, et pourquoi ils sont si nombreux

Le cas le plus fréquent en pratique est celui des correctifs rétroportés. Debian, Red Hat et d’autres distributions intègrent le correctif de sécurité dans leur propre version de paquet sans relever le numéro de version annoncé par l’application. La faille est fermée, le scanner la remonte quand même : il ne connaît que le numéro.

S’y ajoutent :

• le code inatteignable : la fonction vulnérable est présente dans la bibliothèque, mais votre application ne l’appelle jamais ;
• les mesures compensatoires : un pare-feu applicatif, une segmentation réseau ou une authentification en amont rendent le chemin d’attaque inutilisable en pratique ;
• la prise d’empreinte erronée : un reverse proxy ou une bannière volontairement modifiée conduisent à une correspondance entièrement fausse.

D’où l’étape qui transforme une sortie d’outil en audit : vérifier à la main chaque constat sérieux, écarter le reste comme du bruit, et écrire pourquoi. Une liste livrée sans cette étape occupe vos équipes pendant des semaines sur des points qui ne comptent pas — et, plus grave, elle les détourne de celui qui comptait.

Lire un score CVSS sans se tromper

Le score CVSS est couramment lu comme un risque. Il ne l’est pas. Il décrit la vulnérabilité en elle-même, sous des hypothèses standard, sans rien connaître de votre environnement.

Un score de base de 9,8 signifie : exploitable depuis le réseau, sans identifiants, avec un impact complet sur la confidentialité, l’intégrité et la disponibilité — si le système est exposé comme la notation le suppose. Quatre questions traduisent ce score en priorité réelle.

En pratique, une vulnérabilité notée 6,5 sur le portail client est presque toujours plus urgente qu’une vulnérabilité notée 9,8 sur une plateforme de test cloisonnée. Cette traduction est la priorisation, et c’est elle qui fixe l’ordre de vos trois prochains mois.

Scan, audit de vulnérabilités, test d’intrusion : le comparatif

L’ordre est croissant, pas alternatif. Qui se contente de scanner obtient une longue liste sans priorités. Qui ne teste qu’une fois par an passe à côté des CVE publiées pendant les onze mois qui séparent deux campagnes.

Ce que l’article 32 du RGPD demande réellement

C’est la question que les comparatifs disponibles en français évitent, alors que c’est elle qui décide du budget.

Le RGPD ne nomme ni le scan ni le test d’intrusion. Il décrit un résultat. L’article 32, paragraphe 1 impose au responsable du traitement et au sous-traitant de mettre en œuvre « les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque », puis énumère, « y compris entre autres, selon les besoins », quatre mesures. La quatrième, au point d), est celle qui nous occupe :

« une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement »

Trois expressions portent tout le poids de cette phrase.

« Une procédure ». Le texte ne demande pas un rapport, il demande un dispositif récurrent, documenté, avec un responsable désigné. Un test d’intrusion isolé, aussi bon soit-il, n’est pas une procédure. Un abonnement à un scanner dont personne ne lit les résultats non plus.

« Régulièrement ». Aucune fréquence n’est fixée. C’est à vous de la justifier au regard du risque, et cette justification s’écrit. Sur ce point précis, un scan mensuel dont la trace existe vaut mieux qu’un test annuel dont la date glisse.

« L’efficacité des mesures ». C’est le mot qui départage les deux prestations. Un scan mesure la présence de défauts connus dans des composants ; il ne mesure pas si vos mesures fonctionnent. Que votre segmentation tienne, que votre authentification multifacteur ne se contourne pas par une API, que le cloisonnement entre deux clients d’une application mutualisée résiste : aucun de ces trois points n’apparaît dans une sortie de scanner, et tous les trois sont des mesures au sens de l’article 32.

La réponse pratique se scinde donc en deux :

• pour la partie « tester et analyser régulièrement », un scan intégré dans une gestion des vulnérabilités documentée fait le travail, à un coût que rien d’autre n’approche ;
• pour la partie « évaluer l’efficacité », il faut des constats vérifiés, un périmètre écrit, une date et un contre-audit après correction. C’est la forme d’un rapport de test d’intrusion, pas celle d’un export de scanner.

Deux précisions que l’on oublie souvent. La première : les mots « selon les besoins » du chapeau signifient que cette énumération n’est pas une liste d’obligations absolues, mais le point d) reste la seule disposition du RGPD qui nomme explicitement le test périodique — et c’est la première chose qu’un délégué à la protection des données ira chercher. La seconde : l’article 32 s’adresse aussi au sous-traitant. Si vous éditez un logiciel en mode hébergé, vos clients vous demanderont ce rapport par contrat bien avant que la CNIL ne s’y intéresse.

La CNIL publie par ailleurs un guide de la sécurité des données personnelles qui décline ces principes en mesures concrètes. Il ne prescrit pas davantage d’outil ni de fréquence : la charge de la démonstration reste de votre côté.

Les autres référentiels demandent-ils la même chose ?

ISO/IEC 27001. L’annexe A distingue deux mesures que l’on confond régulièrement : A.8.8, la gestion des vulnérabilités techniques, et A.8.29, les tests de sécurité dans le développement et l’acceptation. La première se satisfait d’un dispositif de scan documenté et suivi ; la seconde attend des tests. C’est pour cette raison qu’un programme ISO 27001 sérieux comporte les deux, comme le détaille notre page ISO 27001.

La directive (UE) 2022/2555 (NIS 2). Son article 21, paragraphe 2, point f), vise « des politiques et des procédures pour évaluer l’efficacité des mesures de gestion des risques en matière de cybersécurité » — une formulation très proche de celle du RGPD. Un point de vigilance, en revanche : cette directive n’est pas transposée en droit français à ce jour. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité est toujours en cours d’examen parlementaire. Il n’existe donc, à cette date, ni obligation, ni échéance, ni sanction NIS 2 en droit interne : ce qui existe est le texte de la directive, et le temps de s’y préparer. Notre page NIS 2 traite cette préparation.

DORA (règlement (UE) 2022/2554) est un régime distinct, applicable aux entités financières, avec ses propres exigences de tests. Ne transposez pas ses obligations à un contexte qui n’est pas le sien.

Comment reconnaître un scan vendu comme un test

Trois signaux, tous visibles dans le devis ou dans le rapport d’exemple :

1. Aucun constat n’est accompagné d’une preuve. Chaque vulnérabilité porte une description soignée, mais nulle part il n’est écrit comment le testeur l’a reproduite.
2. Les descriptions sont génériques. Elles sortent d’une base et ne disent rien de votre environnement.
3. Un prix est annoncé avant qu’un périmètre existe. Annoncer un montant avant de connaître le nombre d’applications, de rôles et d’intégrations, c’est deviner — ou livrer un scan.

Demandez systématiquement un exemple de rapport caviardé, et regardez une seule chose : la preuve de concept attachée à un constat sérieux. Elle est là, ou elle n’y est pas.

Un véritable test d’intrusion coûte plus cher, et c’est normal. Ce que vous obtenez en échange est une liste courte dont chaque point est démontré, au lieu d’une liste longue qu’il vous reste à trier.

Comment articuler les deux sur douze mois

Un dispositif qui fonctionne dans une PME ou une ETI :

1. Scanner en continu — systèmes exposés sur Internet chaque semaine, réseaux internes chaque mois, plus un passage après chaque changement notable.
2. Vérifier chaque trimestre — un auditeur reprend les constats sérieux, écarte les faux positifs et classe la liste selon la priorité réelle. C’est l’audit de vulnérabilités.
3. Tester chaque année — un test d’intrusion couvre les classes qu’aucun outil ne trouve et produit la preuve qu’un auditeur ou un client vous demandera. Pour une application exposée, commencez par un test d’intrusion applicatif ; pour un domaine Active Directory, par un test d’intrusion interne.
4. Revérifier après correction. Sans contre-audit, vous documentez un problème, pas une solution. Chez Haxoris, le contre-audit est inclus dans le prix de la prestation.

Tous nos tests sont réalisés sur mandat écrit et dans un périmètre défini contractuellement, conformément aux articles 323-1 et suivants du code pénal.

Questions fréquentes

Vous hésitez encore ? Nous le disons quand un audit de vulnérabilités suffit : cela vous coûte moins cher, et cela vous évite d’acheter une profondeur dont vous n’avez pas encore l’usage. Décrivez votre périmètre en quelques lignes et demandez un devis, ou commencez par lire ce qu’est un test d’intrusion.

Nos services associés : audit de vulnérabilités de vos systèmes et de vos applications · tests d’intrusion sur vos applications et vos infrastructures · tests d’intrusion externes et internes sur votre infrastructure