Comment écrire un Rapport de Pentest Professionnel

Pourquoi un rapport est-il important ?#

Un rapport de pentest est le seul livrable tangible remis au client. Il a pour but de :

• Documenter toutes les vulnérabilités trouvées
• Proposer des solutions claires et réalistes
• Aider les décideurs à comprendre les risques métier
• Servir de base pour les futures corrections et audits

Un bon rapport est compréhensible par des personnes techniques (ex : DevSecOps) et non techniques (ex : PDG, chefs de projet).

C’est une compétence souvent ignorée par les juniors, jusqu’au jour où ils doivent le faire.

Structure recommandée d’un bon rapport#

Basé sur les standards pro (PTES, OWASP), un bon rapport est divisé comme suit :

1. Assessment Overview (Vue d’ensemble du test)#

Objectif#

• Décrire les buts du test : identifier les vulnérabilités, valider les contrôles, etc.

Méthodologie utilisée#

• PTES, OWASP Testing Guide, NIST SP800-115...

Exemple :#

Méthodologie : PTES (Planning → Discovery → Attack → Reporting)
Date de test : 01/05/2025 - 02/05/2025
Durée : 2 jours
Équipe : RedTeam VulnTrust

2. Severity Ratings (Notation de gravité)#

But :#

• Donner une vision prioritaire des risques pour aider le client à savoir quoi corriger d’abord.

🔢 Basé sur CVSSv3 :#

Exemple d’utilisation :#

La faille SQLi est classée Critique (CVSS 9.8) car elle permet de bypasser l’authentification sans droits.

3. Risk Factors (Facteurs de risque)#

Objectif :#

Analyser chaque vulnérabilité selon deux axes :

• Likelihood (probabilité que ça soit exploité)
• Impact (gravité de la conséquence)

Exemple :#

4. Scope (Périmètre du test)#

But :#

Définir ce qui était autorisée à être testé et ce qui ne l’était pas.

À inclure :#

• Domaines, IPs, webapps testées
• Plage horaire (si imposée)
• Autorisation signée (ex : contrat ou e-mail)

Exemple :#

In-Scope:
- https://example.com
- IP Range: 192.168.1.0/24
 
Out-of-Scope:
- API de paiement
- Réseau interne

5. Executive Summary (Résumé Exécutif)#

But :#

Faire un résumé non technique destiné aux responsables (PDG, RSSI...)

Contenu attendu :#

• Nombre total de failles
• Niveau de gravité global
• Forces et faiblesses
• Recommandations stratégiques

Exemple :#

Résumé :
- 6 vulnérabilités découvertes (2 critiques, 3 moyennes, 1 faible)
- Risques majeurs : SQLi, accès admin non protégé
- Bonnes pratiques en place : WAF actif, sessions sécurisées
- Recommandation : corriger urgemment les failles critiques et planifier un retest sous 30 jours.

6. Technical Findings (Détails techniques)#

Cette section est l’âme technique du rapport. Chaque finding doit être complet, clair, et vérifiable.

Pour chaque faille :#

1. Titre clair : SQL Injection in Login Form
2. Description : Ce que fait la faille + pourquoi c’est dangereux
3. Cible : IP ou endpoint exact (/login, /api/users/1)
4. Gravité CVSS : Avec justification
5. Risque : Ce que l’attaquant peut faire (ex: voler des comptes)
6. Outils utilisés : Burp, Gobuster, Hydra...
7. Références : CVE, OWASP...
8. Preuves : Payload + screenshot + réponse serveur
9. Remédiation : Conseils clairs (pas juste "patcher")

Exemple de finding :#

###  Vulnerability: SQL Injection
- **Endpoint**: POST /login
- **Payload utilisé**:
    ' OR 1=1 --
- **Outils**: Burp Suite, sqlmap
- **Impact**: Bypass complet de l'authentification
- **Gravité**: CVSS 9.8 (Critique)
- **Capture**: voir `/screenshots/sqli_login.png`
- **Recommandation**: Utiliser des requêtes préparées + filtrer les entrées utilisateur

Conclusion#

Une fois tout documenté, finir avec une conclusion claire :

• Le système est-il globalement sécurisé ?
• Quelles sont les urgences ?
• Faut-il un retest ?

Exemple :#

Conclusion :
Le test a révélé plusieurs vulnérabilités critiques. Des actions immédiates sont nécessaires. Un second test est recommandé dans 4 à 6 semaines après corrections.