À quoi ressemble un vrai rapport d'audit de sécurité — et comment le lire

Tapez « rapport de pentest exemple » et vous tomberez surtout sur des PDF de démonstration : société inventée, failles inventées, mise en page soignée. Ils montrent une maquette, pas un raisonnement. Ce guide fait l'inverse : il décrit section par section ce que contient un rapport d'audit sérieux, donne les six signes qui distinguent un vrai rapport d'un export de scanner reformaté, et illustre chaque exigence avec une vulnérabilité réelle, publiée et créditée par un éditeur tiers.

Le rapport est le seul livrable qui vous reste

Un test d'intrusion produit du temps passé, des accès temporaires et un document. Six mois plus tard, il ne reste que le document. C'est lui que votre RSSI relira et que votre donneur d'ordre exigera dans un dossier.

Des référentiels publics en décrivent la forme attendue. L'OWASP publie une structure de rapport dans son Web Security Testing Guide. Le NIST décrit la restitution et la remédiation dans sa publication SP 800-115. En France, l'ANSSI encadre la prestation par le référentiel PASSI, mis à jour en version 2.2 le 29 novembre 2024, qui introduit deux niveaux de qualification, élevé et substantiel, en alignement avec le règlement européen sur la cybersécurité. Hydra n'est pas qualifié PASSI ; le référentiel sert ici de repère sur la forme attendue du rapport. Ces textes convergent : le rapport n'est pas un compte rendu d'activité, c'est un document de décision.

L'anatomie d'un rapport sérieux

Un rapport complet s'ouvre et se ferme toujours de la même manière. Voici l'ossature, dans l'ordre où elle doit apparaître.

1. Périmètre et exclusionsLa liste exacte de ce qui a été testé — domaines, adresses, comptes fournis, environnement — et la liste explicite de ce qui ne l'a pas été. Sans les exclusions, le périmètre ne veut rien dire.
2. Méthode et fenêtre de testBoîte noire, grise ou blanche ; référentiels suivis ; dates de début et de fin ; version de l'application testée. L'OWASP place la durée de la mission — son point 1.6, Timeline — dans l'introduction du rapport.
3. Résumé pour la directionUne à deux pages sans jargon. L'OWASP le décrit comme devant présenter l'objectif du test et les constats clés dans un contexte métier — conformité, réputation — en laissant de côté les détails techniques.
4. Synthèse par sévéritéUn tableau, un identifiant par constat, une échelle définie en annexe. L'OWASP suggère Informational, Low, Medium, High, Critical, et demande que l'échelle retenue soit documentée.
5. Le détail de chaque constatLe corps du rapport, et la partie qu'aucun scanner ne produit. Sa structure est détaillée plus bas.
6. Plan de remédiation prioriséPas une liste de correctifs, un ordre : cette semaine, ce mois-ci, ce trimestre, avec le coût et le risque de chaque action.
7. Retest et vérificationLa procédure de contre-vérification, sa date, et ce qui sera rejoué.
8. AnnexesMéthodologie, définition des sévérités, sorties d'outils brutes. Elles prouvent le travail, elles ne gonflent pas le volume.

Le périmètre : lisez d'abord ce qui en est exclu

C'est la section que les acheteurs survolent et celle que les auditeurs sérieux écrivent en premier. Un périmètre utile répond à quatre questions. Quels actifs, nommés un par un. Quels comptes et quels rôles ont été fournis — un test authentifié et un test non authentifié ne couvrent pas la même surface. Quelles actions étaient interdites : déni de service, envoi réel d'e-mails, écriture en production. Et quelle version a été testée : un numéro de build, un tag de dépôt.

Une exclusion honnête ressemble à ceci : « l'API de facturation n'a pas été testée, l'environnement de recette n'était pas disponible pendant la fenêtre ». Un rapport qui ne liste aucune exclusion n'a pas borné son périmètre. Sur des périmètres partagés — un prestataire qui teste pour ses propres clients — le périmètre doit aussi préciser qui porte la responsabilité de l'autorisation, un point détaillé sur notre page audits en marque blanche.

L'unité de base : à quoi ressemble un constat

Un rapport se juge sur un seul de ses constats. Prenez-en un au hasard : s'il ne contient pas les six éléments suivants, le rapport entier est un export de scanner mis en forme.

L'OWASP est explicite sur le troisième point : le rapport peut inclure des artefacts rejouables pour aider les développeurs à vérifier les correctifs — commandes curl reproduisant la requête, preuve de concept, fichiers HAR, scripts simples. C'est l'exigence qu'un scanner ne peut pas satisfaire : il signale une condition, il ne démontre pas une exploitation.

Les six signes d'un vrai rapport

Le deuxième point mérite d'être cité à la source. Le FIRST, qui publie la norme CVSS, écrit dans la spécification v4.0 :

Autrement dit : un score de base recopié tel quel n'est pas une évaluation de votre risque, c'est une donnée d'entrée que l'auditeur doit contextualiser. Un rapport qui empile des scores bruts sans expliquer ce qu'ils signifient dans votre architecture vous a livré la moitié du travail.

Un exemple réel : CVE-2026-12478, libsoup

Voici une vulnérabilité réelle, co-signalée par l'opérateur d'Hydra avec Gerard Capdevila, publiée au NVD le 14 juillet 2026 et créditée par Red Hat. Elle sert ici d'exemple de rédaction : tout ce qui suit est vérifiable sur les pages de Red Hat, du NVD, de MITRE et sur le dépôt GNOME/libsoup.

Sources : Red Hat Product Security, page CVE-2026-12478 ; NVD, notice CVE-2026-12478.

Contexte. Le composant est libsoup, la bibliothèque HTTP du projet GNOME. Le défaut vit dans le traitement des trames WebSocket, dans la fonction process_frame() de libsoup/websocket/soup-websocket-connection.c, à l'endroit du bloc if (masked) — localisation lisible dans le code amont et dans la demande de fusion 518, et non dans la fiche Red Hat, qui s'en tient à « libsoup's WebSocket frame processing ». La condition d'atteignabilité est nommée, et c'est elle qui fait la valeur du constat : une configuration non par défaut où max_incoming_payload_size vaut zéro.

Primitive technique. La description publiée, mot pour mot. Elle tient en deux phrases, parce qu'un défaut compris se décrit brièvement :

Remarquez ce que fait ce paragraphe : il nomme le correctif précédent, le commit, la version, l'endroit exact où la garde a été placée et la conséquence de ce placement. Il désigne ensuite qui déclenche le défaut — un serveur, donc un attaquant distant — et avec quelle donnée. Un développeur peut le lire et savoir quoi corriger sans poser de question.

Pourquoi ça compte. Une lecture hors limites paraît anodine tant qu'on ne dit pas ce qu'elle donne. MITRE, dans la fiche CWE-125, liste les conséquences : l'attaquant peut obtenir des valeurs secrètes — clés cryptographiques, données personnelles, adresses mémoire — utilisables dans des attaques ultérieures ; la mémoire lue hors bornes peut contenir des adresses permettant de contourner l'ASLR ; la lecture peut provoquer une erreur de segmentation, donc un arrêt du service. Un rapport correct traduit cette liste dans vos termes.

Comment on la prouve. La preuve est ici une trame WebSocket forgée, envoyée par un serveur contrôlé vers un client construit dans la configuration précisée ; le rapport fournit la configuration exacte, le contenu de la trame et le comportement observé. Le correctif amont est public : la demande de fusion GitLab n° 518 du projet GNOME/libsoup s'intitule « websocket: Fix out-of-bounds read when reading unmasked frame » et sa description énonce que « The original fix for CVE-2026-0716 was incomplete; the same out-of-bounds read can occur if a server sends a malicious unmasked frame to the client ».

Le crédit. C'est le point qu'aucun rapport fictif ne peut produire. Red Hat écrit, verbatim, sur sa page publique :

Et la sévérité honnête. Red Hat classe cette vulnérabilité à 4,8 sur l'échelle CVSS v3.1, parce qu'elle exige une configuration non par défaut. Un rapport sérieux écrit 4,8 et l'explique ; il n'écrit pas « critique » parce que le mot se vend mieux. La discipline de notation est un signe de qualité plus fiable que le nombre de constats.

Le même principe vaut pour un second actif public : CVE-2026-28962, dans WebKit, corrigée dans Safari 26.5 le 13 mai 2026 sous l'advisory Apple 127121. Le crédit y est partagé avec cinq autres chercheurs — Apple liste six noms pour cette entrée. Un auteur identifiable, c'est aussi un auteur qui dit quelle part du travail lui revient. Ces deux références sont vérifiables depuis nos références publiques.

Le retest : la seule section qui prouve qu'une faille est fermée

L'exemple libsoup contient sa propre leçon : le premier correctif était incomplet. La garde avait été posée, mais du mauvais côté d'un test conditionnel, et le défaut a survécu sur un chemin voisin. C'est exactement pourquoi un rapport sans retest ne conclut rien. « Corrigé » est une affirmation de l'équipe qui a corrigé ; « fermé » est une constatation de celui qui a retesté.

Le NIST est précis sur la manière de retester, en section 8.3 de la SP 800-115 :

Un retest valable rejoue le test d'origine à l'identique, même périmètre, mêmes comptes. Relancer un scanner ne vérifie pas le correctif : cela vérifie que l'outil ne détecte plus la condition qu'il détectait. Exigez un addendum daté, constat par constat, avec trois états : fermé, partiellement corrigé, ouvert. Un « partiellement corrigé » est bon signe — il prouve que quelqu'un a regardé.

Ce qu'un rapport ne prouve pas

Deux limites doivent figurer noir sur blanc dans tout rapport honnête, et leur absence est en soi un signal.

L'absence de constat ne prouve pas l'absence de faille. Un test explore un périmètre, dans une durée finie, avec les accès dont disposait l'auditeur. Un rapport sans constat critique dit une chose : sur ce périmètre, dans cette fenêtre, avec cette méthode, rien de critique n'a été trouvé. Il ne dit pas que rien n'existe. Un prestataire qui vous vend un « système sécurisé » à partir d'un rapport vide vous vend une conclusion que le document ne porte pas.

Un rapport est daté. Le NIST le formule en section 6.2 : « Since an assessment provides a snapshot of security at a given point in time, organizations may choose to require more frequent assessments. » Le déploiement du lendemain peut réintroduire ce qui vient d'être fermé. C'est pourquoi la version testée doit figurer dans le périmètre, et pourquoi la fréquence des tests est une décision de gouvernance.

Ce qu'il faut demander avant de signer

Vous n'avez pas besoin d'être technique pour évaluer une offre d'audit. Cinq questions suffisent, et les réponses vous en disent plus qu'une plaquette.

• Puis-je voir un constat anonymisé, en entier ? Pas un rapport complet — un seul constat, avec sa preuve. C'est le test qui sépare le plus vite une méthode d'une plaquette.
• Qui teste, et où vérifier son travail ailleurs ? Une CVE publiée, un crédit éditeur. Une signature vérifiable par un tiers vaut mieux qu'une liste de logos.
• Le retest est-il inclus, sous quel délai ? En option, le devis n'inclut pas la preuve que vos correctifs fonctionnent.
• Qu'est-ce qui est exclu du périmètre ? Une réponse précise est bon signe ; une hésitation aussi, si elle est suivie d'une liste écrite.
• Comment sont notées les sévérités ? L'échelle doit être documentée en annexe, et l'auditeur doit savoir expliquer pourquoi un constat n'est pas critique.

Chez Hydra, le scan préliminaire est gratuit : score de A à F, comptage par sévérité, une faille révélée en clair — de quoi juger de la forme avant de discuter du fond. L'audit complet est établi sur devis, selon le périmètre réel : un périmètre non lu ne se tarife pas. La démarche est décrite sur nos pages services et, pour les revendeurs, sur l'offre destinée aux MSP.