Que contient un rapport de pentest ?

Niveau : débutant à intermédiaire.

Prérequis : connaître les notions de vulnérabilité, de risque, d'impact, de périmètre et de test d'intrusion. Savoir distinguer une observation d'une conclusion facilite la lecture. Aucun outil de pentest n'est requis.

Un rapport ne légitime pas les tests décrits. Les vérifications doivent avoir été réalisées dans un périmètre explicitement autorisé, avec des règles d'engagement et des conditions d'arrêt. Les preuves peuvent contenir des secrets, des données personnelles ou des informations facilitant une attaque. Elles doivent être minimisées, expurgées et réservées aux destinataires autorisés. L'exercice reste entièrement sur papier et emploie uniquement un cas fictif.

Le rapport de pentest relie trois éléments : ce qui a été testé, ce qui a été observé et ce que l'organisation peut faire ensuite. Un export de scanner peut contribuer aux notes de travail, mais il ne remplace pas cette analyse. Il peut contenir des doublons, des résultats non confirmés et des scores dépourvus de contexte métier.

Le rapport commence à se préparer avant les tests. Le commanditaire et le prestataire définissent les destinataires, le format, la langue, le niveau de détail, la classification, les délais et les canaux de remise. Ils précisent aussi si des points d'avancement, une alerte immédiate sur les risques critiques, une restitution orale ou un rapport de contre-vérification sont attendus.

Pendant la mission, le testeur conserve des notes horodatées et relie chaque preuve à une cible, un compte de test et une hypothèse. Cette traçabilité évite de reconstruire les faits à partir de souvenirs ou de captures isolées. Les secrets et données inutiles sont masqués dès la collecte lorsque cela est possible. Une capture sans date, cible ni contexte peut être impressionnante tout en restant impossible à interpréter.

Après les tests, l'analyse qualifie les constats, recherche les causes, évalue les conséquences et propose des mesures proportionnées. Le rapport doit être lisible par plusieurs publics sans confondre leurs besoins. Le NIST SP 800-115 indique qu'un rapport peut inclure la méthodologie, les résultats, l'analyse et des recommandations de réduction du risque. Il insiste également sur la protection des résultats, car ils décrivent des faiblesses potentiellement exploitables.

Un bon livrable ne cherche pas à dramatiser. Il permet au décideur de comprendre les scénarios importants et à l'équipe technique de retrouver le contrôle défaillant. Il sépare les faits établis, les interprétations et les hypothèses. Cette séparation rend les échanges plus efficaces et limite les généralisations qui ne seraient pas soutenues par les tests.

La première partie identifie le document et son contexte. Elle contient généralement le titre de la mission, le commanditaire, le bénéficiaire, la version, la date, l'historique des modifications, les auteurs, les relecteurs, les destinataires et la classification. Elle rappelle ensuite les objectifs, les critères et les dates de l'évaluation.

Le périmètre doit être précis : adresses, applications, API, versions, environnements, rôles et fonctions inclus. Les comptes, informations et documents fournis sont listés. Les méthodes et référentiels sont nommés. Les exclusions, restrictions, horaires et conditions d'arrêt sont décrits. Si une autorisation dépend d'un tiers, ce point doit avoir été traité dans le cadrage et non supposé après coup.

Cette partie évite des conclusions abusives. Si une API, un rôle, une région cloud ou une fonction de paiement n'a pas été inclus, l'absence de constat à son sujet ne signifie rien sur sa sécurité. De même, un pentest conduit en préproduction ne s'applique à la production que si les environnements sont suffisamment comparables. Les différences connues doivent être indiquées.

Les limites décrivent les difficultés susceptibles d'avoir réduit la couverture : compte inutilisable, indisponibilité d'un composant, documentation incomplète, temps insuffisant, restrictions opérationnelles ou échantillonnage. Elles ne servent pas à excuser une mission mal préparée. Elles permettent au lecteur de comprendre la portée réelle des conclusions et d'identifier un éventuel besoin complémentaire.

Les référentiels de qualification PASSI de l'ANSSI constituent une source stable pour retrouver les exigences applicables aux prestations d'audit qualifiées. Ils replacent le rapport dans une mission définie par une convention, une préparation, une réalisation et une restitution. Le rapport doit aussi mentionner les documents et versions réellement consultés afin que sa base factuelle reste vérifiable.

La synthèse managériale s'adresse à des lecteurs qui doivent arbitrer des risques, des budgets et des responsabilités sans nécessairement reproduire les constats techniques. Elle rappelle brièvement le besoin à l'origine du pentest, les systèmes évalués et les principales limites.

Elle présente ensuite les résultats qui modifient réellement la compréhension du risque. Une formulation utile explique le scénario, les fonctions ou données concernées, les conséquences plausibles et les premières priorités. Elle évite les détails de protocole, les longues suites de captures et les qualificatifs alarmistes. Dire qu'un risque est catastrophique sans préciser les conditions ni les actifs concernés n'aide personne à décider.

Un nombre de constats ne constitue pas à lui seul une synthèse. Dix constats mineurs ne sont pas automatiquement plus préoccupants qu'un seul défaut affectant une fonction essentielle. Un graphique par sévérité peut aider, mais il ne remplace pas l'explication des scénarios, des dépendances entre constats et des contrôles compensatoires déjà présents.

La synthèse expose également les réserves importantes. Si un rôle administratif n'a pas été testé ou si un système critique est resté indisponible, le décideur doit le savoir avant d'interpréter l'appréciation générale. Elle peut regrouper les mesures par horizon : réduction immédiate de l'exposition, correction technique, amélioration durable du processus et vérification après mise en œuvre.

L'OWASP Web Security Testing Guide, section Reporting distingue une synthèse destinée aux décideurs et des constats techniques détaillés. Cette séparation ne signifie pas que les deux parties racontent des histoires différentes. Les messages importants, les limites et les niveaux de risque doivent rester cohérents. La synthèse reformule et hiérarchise ; elle ne masque pas les réserves ni n'invente une certitude que les tests ne permettent pas.

La partie technique commence souvent par un tableau récapitulatif donnant l'identifiant, le titre, les actifs concernés, la gravité et le statut de chaque constat. Elle développe ensuite une fiche par vulnérabilité ou par scénario.

Une fiche exploitable contient généralement :

1. Un identifiant stable et un titre factuel. Ils servent dans les tickets, les réunions et les contre-vérifications.
2. Le périmètre affecté. Il précise les composants, fonctions, versions et rôles concernés.
3. Les préconditions. Il indique si un compte fourni ou un accès réseau particulier était nécessaire.
4. L'observation. Elle décrit le comportement réellement constaté, séparément de son interprétation.
5. Le résultat attendu. Il rappelle le contrôle qui aurait dû s'appliquer.
6. Une preuve minimale. Une capture expurgée, un extrait de journal ou un échange technique limité peuvent suffire. Les mots de passe, jetons et données personnelles inutiles sont masqués.
7. L'impact et le scénario de risque. Ils expliquent ce qu'un acteur placé dans les mêmes conditions pourrait obtenir et pourquoi cela compte.
8. La gravité justifiée. La méthode de classement et les hypothèses sont explicites.
9. La recommandation. Elle cible la cause, les mesures temporaires possibles et les critères de correction.
10. Les références et limites. Elles citent une exigence ou indiquent les variantes non testées.

Le niveau de détail doit permettre à l'équipe autorisée de comprendre et de vérifier la correction, sans publier inutilement une procédure offensive réutilisable. Un élément particulièrement sensible peut être placé dans une annexe chiffrée ou remis par un canal séparé. La minimisation n'affaiblit pas la preuve : elle conserve ce qui soutient le constat et retire ce qui augmente le risque sans aider la décision.

Il faut distinguer fait, interprétation et hypothèse. « Le compte A a affiché le document fictif B » décrit une observation. « Le contrôle d'autorisation n'a pas empêché cet accès » est une interprétation soutenue par le test. « Tous les documents sont accessibles » serait une généralisation injustifiée si un seul document a été examiné. La fiche doit nommer l'échantillon et employer un langage conditionnel pour les conséquences non démontrées.

La reproductibilité signifie ici que l'équipe autorisée dispose d'assez d'informations pour comprendre le défaut et confirmer sa correction. Elle ne justifie pas l'inclusion de secrets actifs, de données réelles ou d'une chaîne d'exploitation complète dans un document largement diffusé.

La gravité décrit le risque associé à un constat selon une méthode annoncée. Elle peut combiner la vraisemblance, les préconditions, les privilèges nécessaires, l'exposition et les effets sur la confidentialité, l'intégrité ou la disponibilité. Un score CVSS peut compléter l'analyse lorsqu'il est demandé, mais il ne remplace pas le contexte métier.

La priorité de correction répond à une autre question : dans quel ordre l'organisation doit-elle agir ? Elle tient compte de la gravité, mais aussi de la criticité de l'actif, de l'exposition réelle, des obligations applicables, des dépendances, de la disponibilité d'une mesure temporaire, du coût et du délai. Le rapport évite donc de copier la sévérité d'un outil ou de convertir mécaniquement un score en échéance.

La spécification CVSS v4.0 de FIRST fournit un langage structuré pour caractériser une sévérité. Si CVSS est utilisé, la version et le vecteur doivent apparaître. Le score n'est toutefois ni une mesure universelle du risque métier, ni une décision automatique de traitement. Les hypothèses et les facteurs propres à l'organisation restent nécessaires.

Une recommandation utile cible la cause plutôt que le symptôme. Elle peut distinguer une mesure immédiate réduisant l'exposition, la correction technique durable, une amélioration du développement ou du déploiement, la surveillance et la vérification après correction. « Sécuriser l'application » est trop vague. À l'inverse, imposer un produit ou une architecture complète sans connaître les contraintes peut être irréaliste. Le rapport peut définir l'objectif de sécurité et les critères de validation.

Le document contient des informations sensibles : chemins d'accès, défauts non corrigés, architecture et captures. Il est marqué, chiffré et transmis par un canal convenu. Les droits d'accès, la durée de conservation, les sauvegardes et la procédure de destruction sont définis. Une restitution orale permet de discuter des scénarios et de corriger un malentendu, mais les décisions et réserves importantes restent écrites.

Après remédiation, une contre-vérification indique pour les constats convenus un statut tel que corrigé, partiellement corrigé, non corrigé ou non vérifiable. Elle précise la date, l'environnement et les versions. Elle ne constitue pas automatiquement un nouveau pentest complet. Une correction peut fermer le constat initial tout en introduisant une régression ailleurs ; la recherche de ces régressions demande un périmètre supplémentaire.

Cet exercice se déroule uniquement sur papier ou dans un document local. Le constat est fourni. Tu ne dois reproduire aucune action, utiliser aucun outil ni contacter aucun service.

Cas fictif

Le portail documentaire documents.exemple.test est imaginaire. Deux comptes de test, lea-test et sam-test, possèdent le même rôle. Au cours d'une mission autorisée, lea-test a pu afficher un document synthétique attribué à sam-test. La preuve disponible est une capture expurgée montrant le compte actif, la référence fictive DOC-002 et le résultat observé. Aucun autre rôle, type de document ou environnement n'a été testé.

À partir de ces seules informations, rédige un identifiant et un titre factuel ; le périmètre, les comptes et la précondition ; l'observation et le résultat attendu dans deux paragraphes séparés ; une description de la preuve sans inventer son contenu ; un impact conditionnel ; une gravité provisoire avec trois facteurs ; une recommandation demandant un contrôle d'autorisation côté serveur pour chaque document ; une mesure temporaire ; les limites de l'échantillon ; et le critère de contre-vérification. Ajoute trois phrases de synthèse managériale et une règle de diffusion à valider avec le commanditaire.

Crée enfin un tableau de suivi avec les colonnes ID, propriétaire, action, priorité, échéance décidée, preuve de correction et statut. Laisse les décisions organisationnelles vides plutôt que de les inventer.

Critère de réussite

Le texte distingue l'observation, l'interprétation et l'hypothèse. Il identifie les deux comptes et l'unique document observé, sans généraliser à tous les documents ou à tous les rôles. La preuve est minimisée. La recommandation décrit un objectif de contrôle et un résultat attendu, pas une procédure offensive. La contre-vérification porte sur le comportement corrigé dans une version et un environnement identifiés.

Limite générale à rappeler

Même un rapport sans constat ne prouve pas qu'un système est sécurisé. Il indique seulement qu'aucun constat n'a été retenu dans le périmètre, la durée, les méthodes et les conditions de la mission. Le rapport est une photographie datée. Les logiciels, les configurations, les menaces et les usages évoluent. Sa conclusion ne promet donc ni exhaustivité, ni absence de vulnérabilité, ni sécurité future.