Rapport de pentest : structure, CVSS 4.0, PASSI 2026

Un rapport de pentest (ou rapport de test d'intrusion, rapport d'audit de sécurité offensif) est le livrable principal d'une mission de pentest : un document structuré de 40 à 80 pages qui consolide le périmètre négocié, la méthodologie appliquée (PTES, OWASP WSTG v4.2, NIST SP 800-115 ou chapitre VI.6 du référentiel PASSI v2.2 pour les missions qualifiées ANSSI), les vulnérabilités validées manuellement avec preuves d'exploitation, leur scoring de sévérité (CVSS 3.1 dominant en 2026, CVSS 4.0 en adoption progressive depuis sa publication FIRST.org en novembre 2023), leur impact business contextualisé, et les recommandations de remédiation priorisées. La structure canonique combine un executive summary de 3-8 pages destiné aux décideurs non techniques (direction, RSSI, DPO, auditeur externe), une section méthodologie et scope de 3-5 pages, et un bloc findings techniques de 30-60 pages où chaque vulnérabilité fait l'objet d'une fiche standardisée (ID, titre, sévérité CVSS, vecteur, CWE, CVE le cas échéant, description, preuve d'exploitation, impact, steps to reproduce, recommandation). Cet article détaille la structure officielle d'un rapport de pentest en 2026, chaque section avec ses pièges courants, le scoring CVSS 4.0 appliqué, les exigences spécifiques PASSI ANSSI, et l'outillage actuel (Dradis, Ghostwriter, PlexTrac, AttackForge).

1. Fonction et enjeux d'un rapport de pentest

Le rapport remplit cinq fonctions simultanées, souvent en tension les unes avec les autres.

La tension principale : un rapport trop technique sera inexploitable par le comité de direction qui décide du budget ; un rapport trop managérial sera insuffisant pour corriger les vulnérabilités. Le rapport double-couche (executive summary + rapport technique détaillé) résout cette tension.

2. Structure canonique d'un rapport de pentest

La structure standard s'appuie sur le Penetration Testing Execution Standard (PTES, publié en 2014, chapitre Reporting toujours de référence), enrichi par le chapitre VI.6 du référentiel PASSI v2.2 pour les missions qualifiées ANSSI. Sept sections :

2.1 Ordre de lecture vs ordre de rédaction

L'ordre de lecture du rapport par le client suit cette numérotation. L'ordre de rédaction par le testeur est inverse : annexes et détail des findings en premier (captures, payloads, logs collectés pendant le test), méthodologie ensuite, synthèse et executive summary en dernier (vue d'ensemble, qui nécessite d'avoir produit tout le contenu).

3. Executive Summary : le pilier client

C'est la section que le sponsor lira en entier. Les findings techniques ne sont parcourus que par 10-20 % des destinataires ; l'executive summary est lu par 100 % d'entre eux. Sa qualité détermine la perception commerciale de la mission.

3.1 Structure imposée de l'executive summary

Six sous-sections, ordre strict :

1. Contexte et rappel du périmètre (0,5-1 page) : dates de la mission, applicatifs testés, type de test (black-box / grey-box / white-box), profil d'attaquant simulé (externe non authentifié, interne collaborateur, sous-traitant compromis).
2. Synthèse quantitative (0,5-1 page) : tableau des findings par sévérité, graphique (camembert ou bar chart), taux de couverture du scope, éventuellement comparaison avec un pentest précédent.
3. Top findings critiques (1-2 pages) : 3 à 5 vulnérabilités maximum, chacune décrite en 5-10 lignes en langage business (pas de jargon), avec impact chiffré ou chiffrable (exfiltration possible de N enregistrements clients, prise de contrôle totale du domaine AD, etc.).
4. Scénario d'attaque réaliste (1-2 pages) : narration en 10-20 lignes d'un attaquant qui aurait chaîné les vulnérabilités pour atteindre un objectif critique. C'est la partie la plus impactante pour un comité de direction.
5. Qualificatif de la posture sécurité (0,5 page) : une phrase argumentée parmi insuffisante / partielle / correcte / mature, avec 2-3 éléments factuels qui justifient le qualificatif.
6. Recommandations stratégiques (0,5-1 page) : 5-7 bullets actionables classés par horizon temporel (court terme < 30 j, moyen terme 30-90 j, long terme > 90 j), sans détail technique.

3.2 Règles absolues de l'executive summary

• Pas de terme technique non expliqué : si tu écris XXE, SSRF, IDOR, l'acronyme doit être développé et le concept expliqué en 1 phrase à la première occurrence.
• Pas de liste brute de CVE : les CVE appartiennent aux findings techniques, pas au résumé exécutif.
• Pas plus de 2 pages dédiées aux top findings sinon ce n'est plus un executive summary.
• Chiffres d'impact business quantifiés dès que possible : nombre d'utilisateurs potentiellement impactés, nombre de transactions possibles, volume de données exfiltrables.
• Scénario d'attaque rédigé comme une histoire : « Un attaquant externe anonyme exploite la vulnérabilité X pour obtenir un accès initial limité, puis utilise Y pour escalader ses privilèges jusqu'à... » Pas de tableau, pas de liste — du texte narratif.

4. Contexte, périmètre et méthodologie

4.1 Contexte et périmètre

Section critique pour la sécurité juridique du prestataire et du commanditaire. Elle doit reprendre à l'identique la convention de pentest signée (aussi appelée Rules of Engagement, Règles d'Engagement ou Autorisation de test).

Éléments obligatoires :

• Périmètre technique : URLs, IPs, applicatifs, services, comptes de test fournis, systèmes explicitement exclus.
• Périmètre temporel : dates et créneaux horaires autorisés.
• Autorisations : signature de l'autorisation, référence au contrat cadre.
• Types de tests autorisés : exclusion des DoS/DDoS, des social engineering sauf négociation, des tests destructifs.
• Profil d'attaquant simulé : non authentifié externe / authentifié utilisateur / authentifié administrateur / compromission latérale simulée.
• Contacts d'escalade : RSSI, sponsor, point de contact technique en cas d'incident détecté ou de vulnérabilité critique à signaler immédiatement.

4.2 Méthodologie appliquée

Référencer explicitement un ou plusieurs référentiels reconnus est attendu par les auditeurs externes et les assureurs cyber. Les référentiels standards 2026 :

Le rapport doit lister les référentiels appliqués, les phases PTES couvertes (Pre-engagement, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, Reporting) et l'outillage utilisé (avec versions exactes : Nmap 7.95, Burp Suite Pro 2025.2, Metasploit Framework 6.4, Nuclei 3.3, BloodHound CE 6.x, Impacket 0.12, etc.).

5. Détail des findings : la fiche de vulnérabilité

5.1 Structure canonique d'une fiche de finding

Chaque vulnérabilité doit faire l'objet d'une fiche standardisée identique d'un finding à l'autre. La structure de référence 2026 comporte 12 champs :

# template-finding-pentest.yml
# Template Markdown / YAML a remplir pour chaque vulnerabilite validee.
 
finding:
  id: PT-2026-042                 # Identifiant interne mission
  titre: "SQL Injection authentifiee dans /api/v2/reports/search"
  severite: Critical              # Critical / High / Medium / Low / Info
  cvss_vector_v31: "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
  cvss_score_v31: 8.8
  cvss_vector_v40: "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N"
  cvss_score_v40: 8.7
  cwe: CWE-89                     # Code Injection
  categorie_owasp: "A03:2021 - Injection"
  asset_impacte: "api.example.com"
  endpoint: "POST /api/v2/reports/search"
  parametre_vulnerable: "filter[orderBy]"
 
  description: |
    L'endpoint POST /api/v2/reports/search traite le parametre
    filter[orderBy] sans validation ni parametrisation. Un utilisateur
    authentifie peut injecter une clause SQL arbitraire qui s'execute
    sur la base de donnees de production (PostgreSQL 15).
 
  impact: |
    Exfiltration complete de la base de donnees incluant les 1,2 M
    comptes clients (emails, hashes bcrypt, donnees de facturation),
    lecture et modification arbitraire des tables, execution de fonctions
    PostgreSQL via pg_read_file() si droits SUPERUSER (non confirme).
 
  preuve_exploitation: |
    Payload utilise (time-based blind, UNION-based):
    filter[orderBy]=1,(SELECT CASE WHEN (SUBSTRING(version(),1,10)='PostgreSQL')
    THEN pg_sleep(5) ELSE pg_sleep(0) END)
 
    Captures: voir annexe A.3 (requete, reponse, screenshot Burp).
 
  steps_to_reproduce:
    - "Authentifier avec compte standard (email/password)"
    - "Intercepter requete POST /api/v2/reports/search"
    - "Modifier filter[orderBy]=name par payload ci-dessus"
    - "Observer delai 5s confirmant time-based injection"
    - "Extraire tables via sqlmap --technique=T --level=5"
 
  recommandation: |
    1) Parametrer toutes les requetes SQL via ORM ou prepared statements
       (recommande: TypeORM ou Knex pour Node.js).
    2) Valider strictement filter[orderBy] contre une allowlist.
    3) Appliquer principe du moindre privilege : compte applicatif DB
       sans droit SUPERUSER, uniquement SELECT sur tables necessaires.
    4) WAF en couche complementaire (Cloudflare, AWS WAF) avec regles
       OWASP CRS 4.0 activees.
 
  horizon_remediation: "Court terme - 72h"
  effort_remediation: "2 a 5 jours-homme"
  references:
    - "OWASP WSTG v4.2 - WSTG-INPV-05"
    - "CWE-89"
    - "PortSwigger Web Security Academy - SQL injection UNION attacks"

5.2 Principe du scoring CVSS 4.0

CVSS 4.0 (Common Vulnerability Scoring System, FIRST.org, novembre 2023) remplace progressivement CVSS 3.1. Quatre groupes de métriques :

1. Base Metrics (obligatoires) : Attack Vector (AV), Attack Complexity (AC), Attack Requirements (AT) — nouveau en v4, Privileges Required (PR), User Interaction (UI), Vulnerable System Impact (VC/VI/VA), Subsequent System Impact (SC/SI/SA) — nouveau en v4.
2. Threat Metrics (anciennement Temporal en v3.1) : Exploit Maturity. Les métriques Remediation Level et Report Confidence de v3.1 ont été retirées.
3. Environmental Metrics : permet de surcharger les métriques de base selon le contexte déploiement client (Confidentiality/Integrity/Availability Requirement).
4. Supplemental Metrics (optionnelles, pas d'impact sur le score numérique) : Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency.

Le score final se décline en CVSS-B (Base seul), CVSS-BT (Base + Threat), CVSS-BE (Base + Environmental) ou CVSS-BTE (complet). Un même finding peut afficher des scores différents selon le contexte client — ce qui est précisément la justification de CVSS 4.0 vs 3.1 où le clustering autour de Critical/High était mal calibré.

5.3 Traduction score → sévérité

5.4 Preuve d'exploitation : non négociable

Chaque finding Critical ou High doit contenir :

• Requête exacte envoyée (HTTP, SQL, commande shell selon contexte).
• Réponse reçue ou screenshot démontrant l'exploitation.
• Payload précis utilisé, reproductible.
• Impact factuel : donnée extraite (anonymisée), action effectuée, accès obtenu.

Un finding sans preuve devient une hypothèse, pas une vulnérabilité validée. Les findings Medium peuvent parfois se contenter d'un screenshot ou d'une extraction d'en-tête HTTP. Les findings Low et Info peuvent se baser sur des observations passives.

6. Chaîne d'attaque et narrative

Un rapport mature ne se limite pas à une liste de findings. Il raconte le chemin d'attaque qu'un adversaire réaliste suivrait en chaînant les vulnérabilités. Cette section (typiquement 1-3 pages) fait la différence entre un rapport mécanique et un rapport qui convainc un COMEX.

Structure recommandée :

• Objectif de l'attaquant simulé (exfiltration données RH, prise de contrôle domaine AD, rançongiciel sur production, etc.).
• Point d'entrée initial : finding n°X permet un accès initial limité.
• Élévation de privilège : finding n°Y permet de passer d'utilisateur standard à administrateur local.
• Mouvement latéral : finding n°Z permet d'atteindre un autre segment.
• Atteinte de l'objectif : résultat final démontré ou démontrable.

Le cadre MITRE ATT&CK Enterprise est idéal pour structurer cette narrative : chaque étape du chemin d'attaque mappée à une tactique (TA0001 Initial Access, TA0004 Privilege Escalation, TA0008 Lateral Movement, TA0010 Exfiltration) et une technique (T1190 Exploit Public-Facing Application, T1068 Exploitation for Privilege Escalation, T1021 Remote Services, T1041 Exfiltration Over C2 Channel).

7. Recommandations et plan de remédiation

7.1 Principe : une recommandation par finding + un plan global

Chaque finding a sa recommandation technique spécifique (voir §5.1 champ recommandation). La section 6 du rapport consolide ces recommandations en un plan de remédiation priorisé et actionnable.

Structure recommandée :

7.2 Bonne pratique : effort et owner explicites

Pour chaque recommandation :

• Effort estimé en jours-homme (1j, 2-5j, 5-20j, 20j+).
• Owner pressenti : équipe applicative, équipe infra, RSSI, direction générale.
• Prérequis éventuels (achat licence, migration préalable, décision d'architecture).

Un rapport sans estimation d'effort est un rapport inexploitable opérationnellement — le sponsor ne peut pas arbitrer budget vs priorité.

8. Spécificités PASSI ANSSI

Les prestataires qualifiés PASSI (Prestataires d'Audit de la Sécurité des Systèmes d'Information, référentiel ANSSI v2.2 publié juin 2024) respectent cinq exigences de rapport spécifiques, non optionnelles :

1. Format défini au chapitre VI.6 du référentiel PASSI : plan imposé, rubriques obligatoires, format de livraison (typiquement PDF signé électroniquement).
2. Profil d'attaquant simulé négocié et documenté explicitement avec le commanditaire avant le test, reproduit dans le rapport.
3. Contact permanent avec l'audité pendant le test : notification préalable avant toute action à risque de dysfonctionnement, trace dans le journal de mission.
4. Justification explicite de toute vulnérabilité non exploitée (instabilité suspectée, risque métier trop élevé, scope limitation). L'absence de test sur un vecteur identifié doit être écrite et justifiée.
5. Communication à l'ANSSI de toute vulnérabilité non publique découverte (0-day de fait), via formulaire dédié avec accord du commanditaire.

Cinq portées PASSI existent, chacune avec ses exigences de rapport propres : audit d'architecture, audit de configuration, audit organisationnel et physique, audit de code source, test d'intrusion. Un prestataire peut être qualifié sur une ou plusieurs portées.

Les audits PASSI sont exigés dans certains contextes réglementaires : LPM OIV (Opérateurs d'Importance Vitale), certaines procédures d'homologation d'État, parfois NIS 2 pour les entités essentielles en secteur régulé. Le prix d'un audit PASSI est 30-80 % supérieur à un pentest non qualifié équivalent.

9. Outillage 2026 de rédaction

La rédaction manuelle sous Word ou LaTeX reste majoritaire en 2026 mais des outils spécialisés accélèrent significativement la production.

Pattern recommandé : prise de notes en markdown pendant le test (Obsidian, Notion, Hackmd) puis génération automatique du rapport avec Pandoc + template LaTeX ou Word. Les plateformes commerciales (PlexTrac, AttackForge) deviennent pertinentes au-delà de 20-30 missions par an par testeur.

10. Pièges fréquents à éviter

Dix pièges récurrents observés sur les rapports de pentest en contexte français 2024-2026.

1. Executive summary trop technique : utilise « RCE via désérialisation Java » au lieu de « prise de contrôle à distance du serveur applicatif ». Sponsor perdu dès la page 2.
2. Findings Critical sans preuve d'exploitation démontrée : décrit l'hypothèse mais pas l'exploitation. Le client refuse la sévérité, le rapport perd sa valeur.
3. Copier-coller de descriptions génériques (CWE, OWASP) sans contextualisation au stack client. Rapport perçu comme « industrialisé ».
4. Recommandations vagues : « mettre en place un WAF » sans nommer de produit, sans effort estimé, sans owner identifié. Inexploitable opérationnellement.
5. Absence de Rules of Engagement reproduites dans le contexte. Fragilise juridiquement le prestataire.
6. Sévérité CVSS mal calibrée : Critical appliqué à tout, même à des findings Medium. Décrédibilise le reste du rapport.
7. Pas de chaîne d'attaque narrative : liste plate de findings sans storytelling. Loupe le 80 % de l'impact COMEX.
8. Screenshots de données réelles non anonymisées (vrais emails, vrais numéros de téléphone). Risque RGPD, risque client pour l'auditeur.
9. Rapport en format non modifiable non éditable livré trop tôt : pas de possibilité de corrections après relecture client. Privilégier une version draft Word/Markdown puis un PDF final signé.
10. Absence de retest post-remédiation planifié. Le rapport devrait prévoir un budget retest de 2-4 jours 30-60 jours après livraison pour valider les corrections sur les findings Critical.

11. Livraison, présentation et suivi

Le rapport ne remplace pas la restitution orale. Trois moments structurent la livraison standard en 2026 :

1. Pre-briefing en fin de mission (J+0 à J+3) : email ou call 30 min avec RSSI et sponsor pour signaler en avance les findings Critical / High. Permet au client de démarrer les patches urgents sans attendre le rapport final (J+10 à J+20).
2. Livraison rapport draft (J+10 à J+15) : version Word/Markdown éditable, permettant au client d'annoter, corriger les éléments factuels, valider les scopes.
3. Restitution orale (J+15 à J+25) : présentation 1-2 heures devant le sponsor et les équipes techniques, Q&A, validation du plan de remédiation.
4. Livraison rapport final (J+20 à J+30) : PDF signé, versionné, archivé.
5. Retest optionnel (J+60 à J+120) : validation des corrections sur les findings Critical/High, émission d'un rapport de retest court (5-10 pages).

La ressource étapes pour devenir pentester détaille le parcours vers la capacité à produire un rapport client. Pour l'angle marché et les TJM facturés, la ressource TJM pentester freelance documente les tarifs 2026, et salaire pentester couvre la voie CDI.

Points clés à retenir

• Rapport de pentest = livrable contractuel double-couche : executive summary pour décideurs (3-8 pages) + findings techniques (30-60 pages).
• Référentiels 2026 : PTES, OWASP WSTG v4.2, NIST SP 800-115, OSSTMM, PASSI v2.2 pour missions qualifiées ANSSI.
• Chaque finding = fiche standardisée 12 champs : ID, titre, CVSS, CWE, description, impact, preuve, steps to reproduce, recommandation, effort, owner, horizon.
• CVSS 4.0 depuis novembre 2023 : Base / Threat / Environmental / Supplemental. CVSS 3.1 reste dominant sur le marché FR 2026.
• Chaîne d'attaque narrative obligatoire : mappée MITRE ATT&CK, 1-3 pages, format storytelling.
• Rules of Engagement reproduites dans le rapport = protection juridique art. 323-1 Code pénal.
• Peer review senior non négociable avant livraison, que la mission soit à 5 ou 50 jours.
• Retest 30-120 j post-livraison à planifier dès la conception de la mission.