---
title: "Template de rédaction de findings"
domain: security
subdomain: pentest
phase: 06-reporting
type: template
tags: [reporting, findings, vuln, pentest, template]
difficulty: intermediate
status: stable
updated: "2025-05-10"
---
## Structure d'un finding

Chaque vulnérabilité doit contenir ces 7 sections :

```
1. Titre — court, précis, orienté impact
2. Sévérité — Critical / High / Medium / Low / Info
3. CVSS Score — v3.1 avec vecteur complet
4. Description — explication technique neutre
5. Preuve (PoC) — capture, payload, log
6. Impact — conséquence métier concrète
7. Remédiation — action précise, priorisée
```

## Template Markdown

```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.

#### Impact

Un 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/admin
FINDING-003 — Medium   — Reflected XSS sur le paramètre search
FINDING-004 — Low      — Version Apache exposée dans Server header
FINDING-005 — Info     — Absence de politique de rotation des tokens
```

<Tip>
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.
</Tip>