En bref
Un rapport de scan est une liste de candidats, pas de faits : chaque ligne signale un motif connu observé, sans prouver qu’il est exploitable chez vous ni ce qu’un attaquant en tirerait. Pour le lire, vérifiez les faux positifs, replacez la gravité dans votre contexte, repérez les zones que le scan n’a pas atteintes et rappelez-vous ce qu’il ne cherche pas : contrôle d’accès et logique métier. Pour choisir entre scan et test d’intrusion, le comparatif détaille les critères.
Quelles vulnérabilités un scanner ne trouvera-t-il pas ?
- Les défauts de contrôle d’accès (IDOR / BOLA) : lire ou modifier l’objet d’un autre utilisateur en changeant un identifiant. Ce défaut occupe la première place de l’OWASP API Security Top 10 (édition 2023).
- L’élévation de privilèges applicative : un rôle qui peut, par un chemin détourné, effectuer une action réservée à un autre.
- Les abus de logique métier : cumuler deux remises, demander deux fois un remboursement, sauter une étape de validation, exploiter une condition de course sur un solde.
- Le cloisonnement entre clients d’une plateforme multi-tenant, qui ne se vérifie qu’avec deux identités dans deux organisations distinctes.
- Le chaînage : une fuite d’information anodine plus un parcours de réinitialisation permissif égalent une prise de contrôle de compte.
Quelle différence de méthode entre le scan et le test d’intrusion ?
Un scanner compare votre système à une base de défauts connus : versions vulnérables, en-têtes manquants, configurations par défaut, injections détectables par motif. Il est rapide, peu coûteux, et il excelle sur la largeur : des milliers de vérifications sur des centaines d’actifs, de façon répétable.
Il a deux limites structurelles. D’abord il ne comprend rien à votre métier : il ne sait pas qu’un utilisateur du plan gratuit ne devrait pas lire la facture d’un autre client, parce que rien dans la réponse HTTP ne le lui indique. Ensuite il ne chaîne pas : trois défauts classés « faibles » qui, combinés, donnent un accès administrateur, restent trois lignes « faibles » dans son rapport.
Ce que la référence du NIST range sous chaque nom
Le guide NIST SP 800-115, consacré aux tests et aux évaluations de sécurité de l’information, ne traite pas le scan et le test d’intrusion comme des synonymes. Il décrit des techniques de revue, des techniques d’identification et d’analyse de la cible (découverte du réseau, identification des ports et des services, recherche de vulnérabilités), puis des techniques de validation des vulnérabilités, dont le test d’intrusion fait partie.
Cette découpe est utile en pratique : la recherche de vulnérabilités produit des hypothèses, la validation les confirme ou les écarte. Un prestataire qui vend le premier étage sous le nom du second vous livre des hypothèses en les présentant comme des constats.
Le guide de test de l’OWASP (Web Security Testing Guide) va dans le même sens pour les applications web. Il organise le travail par familles de vérifications, dont la gestion des identités, l’authentification, l’autorisation et la logique métier, des domaines où le jugement de l’analyste pèse plus que l’outil. Vous pouvez vous en servir comme grille : demandez au prestataire lesquelles de ces familles seront couvertes, et comment.
Comment choisir selon votre situation
- 1Si vous voulez surveiller un parc étendu dans le temps et détecter les régressions de configuration : un scan récurrent, mensuel ou continu, est le bon outil au bon prix.
- 2Si une application porte votre chiffre d’affaires, des données personnelles sensibles ou des flux financiers : un test d’intrusion. Le scan seul laissera passer la catégorie de vulnérabilité qui vous coûterait le plus cher.
- 3Si un client vous demande « un rapport de pentest » : vérifiez ce qu’il attend. Un rapport de scan rebaptisé est repéré immédiatement par une équipe sécurité, et vous fait perdre à la fois le contrat et la crédibilité.
- 4Si votre budget ne couvre pas un test d’intrusion complet : réduisez le périmètre plutôt que la profondeur. Un test sérieux sur le parcours d’authentification et les API de facturation vaut mieux qu’un survol de toute l’application.
Pourquoi associer les deux
Dans une mission bien menée, le scan n’est pas l’alternative au test d’intrusion : il en est la première couche. Il traite le connu en quelques heures, ce qui libère le temps humain pour le reste. C’est exactement ainsi que nous travaillons, avec une plateforme interne qui industrialise la reconnaissance et les scanners, et un analyste qui passe son temps sur le contrôle d’accès et la logique.
La bonne question n’est donc pas « scan ou test d’intrusion ? » mais « quelle part de ma surface a besoin d’une lecture humaine, et à quelle fréquence ? ».
À retenir
- 1Un rapport de scan est une liste de candidats à vérifier, pas une liste de faits.
- 2Le scan couvre le connu, largement et à bas coût ; il ne comprend pas votre métier.
- 3Le contrôle d’accès, la logique métier et le chaînage demandent un humain : ce sont les vulnérabilités les plus coûteuses.
- 4À budget contraint, réduisez le périmètre d’un vrai test d’intrusion plutôt que la profondeur.
- 5Un rapport sans requête, sans réponse et sans impact démontré est un rapport de scan.
Comment lire un rapport de scan sans s’y perdre ?
Un rapport de scan se lit comme une liste de candidats, pas comme une liste de faits. Chaque ligne indique qu’un motif connu a été observé ; elle ne dit ni que la faille est exploitable chez vous, ni qu’elle l’est depuis Internet, ni ce qu’un attaquant en tirerait.