Ce que contient un bon rapport de sécurité, et comment le lire
Vous achetez un document que vous n'avez jamais vu
La plupart des gens qui commandent un audit n'ont jamais lu de rapport. Le PDF arrive, on descend aux encadrés rouges, on transfère à un développeur, et on espère. Sans point de comparaison, un export de scanner de 60 pages et une évaluation rédigée de 20 pages semblent aussi sérieux l'un que l'autre.
Ce n'est pas la même chose. Un scanner liste ce qu'un outil a remarqué. Un rapport dit ce qu'un humain a vérifié, en quoi ça compte chez vous, et par quoi commencer. Faire la différence prend dix minutes quand on sait où regarder.
Ce que contient un rapport sérieux
Le Web Security Testing Guide de l'OWASP consacre un chapitre au rapport — le meilleur étalon gratuit. Sa structure, condensée :
Le périmètre et les limites, écrits
Quels hôtes, quels domaines, quels endpoints d'API. Si les tests étaient authentifiés, et avec quels rôles. Ce qui a été exclu. Le WSTG demande une sous-section Limitations : zones hors périmètre, fonctionnalités cassées, manque de temps, manque d'accès ou d'identifiants.
C'est la section qu'on saute, et c'est elle qui détermine la valeur du reste. « Aucune injection SQL détectée » ne veut rien dire tant qu'on ignore quels formulaires étaient atteignables, et si le testeur avait un compte. La moitié d'une application vit derrière une authentification.
Un rapport doit aussi dire jusqu'où sa validité s'étend dans le temps. Le WSTG propose une clause en ce sens : l'évaluation vaut à un instant donné, l'environnement a pu changer depuis, rien ne garantit l'exhaustivité. Un prestataire qui refuse cette phrase vend ce que personne ne peut livrer.
Le résumé exécutif
Deux à trois pages pour celui qui ne lira pas le reste : pourquoi le test a été commandé, ce qui en ressort en termes métier, quelles décisions prendre. Pas une recopie du tableau des constats. S'il contient des en-têtes HTTP, personne ne l'a rédigé.
La méthodologie
Quel référentiel — le Top 10 de l'OWASP, l'ASVS, le NIST SP 800-115 —, quels outils ont tourné, et ce qui a été fait à la main. Sans ça, impossible de juger la couverture ni de comparer d'une année sur l'autre.
Des constats justifiés un par un
Le modèle du WSTG fait une bonne liste de contrôle : identifiant, titre, vraisemblance ou exploitabilité, impact, niveau de risque, description technique, étapes de remédiation, références.
Ajoutez ce que le WSTG laisse facultatif : un identifiant CWE. Le CWE catalogue les classes de faiblesse — CWE-89 pour l'injection SQL, CWE-79 pour le XSS —, là où un CVE désigne une vulnérabilité précise dans un produit précis. Il transforme « problème de validation d'entrée » en une référence consultable, et permet de confronter les constats au CWE Top 25.
Des preuves reproductibles
La requête envoyée, la réponse reçue, la suite exacte des manipulations. Un constat non reproductible est un constat dont vous ne vérifierez jamais la correction. Le WSTG demande aussi de masquer mots de passe, données personnelles et numéros de carte : le rapport est lui-même une carte pour entrer chez vous.
Une remédiation priorisée et concrète
« Assainissez vos entrées » n'est pas une remédiation. « Remplacez la concaténation dans OrderRepository.findByRef() par une requête paramétrée » en est une. Et la priorité ne se réduit pas à la sévérité : un bon rapport dit quoi traiter cette semaine, ce trimestre, et ce qu'on peut assumer de laisser.
Le re-test
Le WSTG suggère qu'un rapport de re-test reprenne les constats précédents, leur statut mis à jour et les renvois vers le test courant. Sans lui, personne ne confirme que le correctif fonctionne — et il échoue souvent, parce qu'on corrige l'endpoint cité plutôt que le motif qui le produit.
Ce qu'une sévérité veut dire
La plupart des constats portent un score CVSS : une valeur de 0 à 10 assortie d'un libellé — Aucun 0,0 ; Faible 0,1-3,9 ; Moyen 4,0-6,9 ; Élevé 7,0-8,9 ; Critique 9,0-10,0.
Le chiffre seul vaut peu. Ce qui compte, c'est le vecteur à côté, en notation CVSS v3.1 :
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — 7,5, Élevé.
Il se lit de gauche à droite : atteignable depuis le réseau, complexité faible, aucun privilège requis, aucune interaction utilisateur, pas de changement de périmètre, impact fort sur la confidentialité, nul sur l'intégrité et la disponibilité. Changez une métrique — l'endpoint est en fait derrière une authentification d'administration, les privilèges requis passent à « élevés » — et le même défaut tombe à 4,9, Moyen. Même code, exposition différente.
Le vecteur rend le raisonnement de l'auditeur vérifiable. Un rapport qui annonce « Élevé » sans vecteur et sans échelle documentée vous demande de le croire sur parole.
Le score de base n'est pas votre risque
Le FIRST, qui maintient le CVSS, le dit sans détour dans son guide utilisateur : « les scores CVSS de base (CVSS-B) sont conçus pour mesurer la sévérité d'une vulnérabilité et ne doivent pas être utilisés seuls pour évaluer le risque. » (En version originale : « CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk. ») Le score de base ne couvre que les caractéristiques intrinsèques d'un défaut, indépendamment de la menace observée et de votre environnement. Le CVSS v4.0 le rend visible dans son vocabulaire — CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE — selon que les métriques de menace et d'environnement ont été appliquées.
Concrètement : un Moyen sur votre tunnel de paiement peut être plus urgent qu'un Élevé sur une page de recette que personne ne visite. Un rapport qui classe strictement par score de base délègue la priorisation à une formule qui n'a jamais vu votre métier. La méthodologie d'évaluation du risque de l'OWASP corrige le tir : vraisemblance croisée avec un impact qui inclut préjudice financier, réputation, non-conformité et violation de données personnelles, pas seulement la perte technique.
Pour les vulnérabilités connues de vos dépendances, EPSS estime la probabilité qu'un CVE publié soit exploité dans la nature sous 30 jours, et le catalogue KEV de la CISA — décrit plus en détail ici — recense ce qui l'est déjà : un CVSS 9,8 que personne n'exploite est souvent moins pressant qu'un 6,5 inscrit au KEV.
Les signes d'un export de scanner déguisé
| Signe | Ce qu'il dit |
|---|---|
| Des constats nommés d'après les plugins de l'outil (« X-Content-Type-Options missing ») | Personne n'a réécrit la sortie |
| Tout est classé Élevé ou Critique | Sévérités gonflées pour justifier la facture |
| Aucune étape de reproduction | Rien n'a été vérifié à la main |
| Aucun périmètre écrit, rien sur ce qui n'a pas été testé | Vous ignorez ce que le rapport couvre |
| Le même paragraphe de remédiation sur cinq constats | Du remplissage, pas de l'analyse |
| Une sévérité sans vecteur et sans échelle documentée | La note est invérifiable |
| Zéro faille de logique métier | Aucun scanner n'en trouve ; s'il n'y en a aucune, personne n'a cherché |
| « Votre application est désormais sécurisée » | Personne ne peut promettre ça |
La dernière surtout : un audit dit ce qui a été trouvé, dans un périmètre défini, à un instant donné. Qui promet davantage est négligent ou en train de vendre.
Les questions à poser avant de signer
C'est ici que se joue la qualification d'un prestataire : les questions purement budgétaires — jours-hommes, part manuelle, re-test compris ou facturé — sont dans l'article sur les prix ; celles qui portent sur la livraison sont ici.
- Quel est exactement le périmètre — hôtes, sous-domaines, endpoints d'API —, qu'est-ce qui en est explicitement exclu, et sera-ce écrit dans le rapport ?
- Les tests seront-ils authentifiés ? Combien de comptes et de rôles vous faut-il de ma part ?
- Puis-je voir un rapport d'exemple anonymisé avant de payer ?
- Chaque constat comporte-t-il des étapes que je peux rejouer moi-même ?
- Comment la sévérité est-elle attribuée — CVSS, méthodologie OWASP, échelle maison — et cette échelle est-elle expliquée dans le rapport ?
- Quelle part du travail est manuelle ? Comment les faux positifs sont-ils écartés ?
- Un re-test est-il prévu après le déploiement des correctifs, dans quel délai et à quel prix ?
- Délivrez-vous une attestation, et repose-t-elle sur une qualification reconnue ?
- Me direz-vous aussi ce qui n'a rien donné, ou seulement ce qui a échoué ?
- Comment le rapport est-il transmis et protégé, et que deviennent le rapport et les preuves collectées après la mission ?
- De quelle autorisation écrite avez-vous besoin de ma part avant de commencer ?
Si les réponses restent floues sur le périmètre, la reproduction et le re-test, le prix n'a plus d'importance.
Si vous en voulez un
C'est l'exigence que je m'applique — et si vous n'avez pas encore fait le ménage de base sur votre site, commencez par là : voici l'offre exacte.
C'est ce que vend iwantreport.dev : une application web et son API, testées sur l'OWASP Top 10, l'API Security Top 10, le CWE Top 25 et l'ASVS — un scanner en première passe, puis chaque résultat reproduit à la main avant d'entrer dans le rapport. Rapport écrit sous 48 h, un re-test inclus, 200 €, garantie satisfait ou remboursé 30 jours : il vous suffit d'en faire la demande par email dans les 30 jours suivant la livraison. Hors périmètre : le réseau interne, la revue de code source, le phishing et l'ingénierie sociale, les tests de charge ou de déni de service, et les applications mobiles.