Template de rédaction de findings
Structure et formulation des vulnérabilités dans un rapport de pentest
Structure d'un finding
Chaque vulnérabilité doit contenir ces 7 sections :
1 Titre court prcis orient impact2 Svrit Critical High Medium Low Info3 CVSS Score v31 avec vecteur complet4 Description explication technique neutre5 Preuve PoC capture payload log6 Impact consquence mtier concrte7 Remdiation action prcise priorise
Template Markdown
### [SEV] — Titre du Finding| Champ | Valeur ||--------------|-------------------------------------|| **Sévérité** | Critical / High / Medium / Low || **CVSS** | 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) || **CWE** | CWE-89 — SQL Injection || **Composant**| Application web — /login endpoint || **Découvert**| {{DATE}} |#### Description[Explication technique du problème, sans jargon inutile. Une phrase sur le mécanisme, une sur pourquoi c'est exploitable.]#### Preuve de concept\```bash# Payload utilisésqlmap -u "http://{{TARGET}}/login" -p username --dbs\```> Résultat : extraction de la base `users` avec 1 247 enregistrements.#### ImpactUn attaquant non authentifié peut extraire l'intégralité de la base de données, incluant les credentials utilisateurs, les informations PII et les secrets applicatifs. Risque de compromission totale de l'application et des systèmes connexes.#### Remédiation- Utiliser des requêtes paramétrées (PreparedStatements) — ne jamais concaténer l'input user dans une requête SQL- Mettre en place un WAF avec des règles SQLi (ModSecurity, AWS WAF)- Effectuer un audit complet des requêtes SQL de l'application**Priorité de correction** : Immédiate (< 72h)
Grille de sévérités
| Sévérité | CVSS | Délai correction | Exemples | |----------|---------|-----------------|--------------------------------------| | Critical | 9.0–10 | < 72h | RCE sans auth, SQLi admin, LPE kernel | | High | 7.0–8.9 | < 1 semaine | SSRF, XXE, auth bypass, privesc local | | Medium | 4.0–6.9 | < 1 mois | XSS stocké, IDOR, info disclosure | | Low | 0.1–3.9 | Prochain cycle | Version disclosure, headers manquants | | Info | 0.0 | Best effort | Observations, recommandations archi |
Formulations à éviter / à utiliser
| ❌ À éviter | ✓ À utiliser | |---------------------------------|----------------------------------------------------| | "Nous avons hacké..." | "Un attaquant peut exploiter..." | | "La sécurité est nulle" | "L'absence de contrôle X permet..." | | "Mettez un firewall" | "Filtrer le paramètre X avec une whitelist de..." | | "C'est dangereux" | "Cela permet l'accès non autorisé à..." | | "Comme vu sur exploit-db..." | "Cette vulnérabilité est connue sous CVE-XXXX-XXXX"|
Numérotation et référencement
FINDING-001 Critical RCE via deserialization CVE-2021-44228)FINDING-002 High Broken Access Control sur /api/adminFINDING-003 Medium Reflected XSS sur le paramtre searchFINDING-004 Low Version Apache expose dans Server headerFINDING-005 Info Absence de politique de rotation des tokens
Toujours lier chaque finding à un impact métier concret : "accès aux données clients", "arrêt de service", "compromission du domaine". Les équipes non-techniques ne lisent que cette partie.