Rapport et priorités : faire corriger

Prérequis : cours précédents (preuves propres).

Pourquoi

Un rapport illisible = des failles non corrigées. Le but n'est pas d'impressionner mais de faire corriger, dans l'ordre, avec vérification. Le rapport est un outil de pilotage, pas un trophée.

Concepts

• Structure : résumé exécutif (3 lignes pour la direction : risque business, pas technique), findings notés (titre, criticité, preuve, impact business, correction précise, retest), annexes techniques.
• Priorités : exploitabilité × exposition × données. Une critique internet avant dix moyennes internes. Chaque finding = responsable + deadline (critique : jours, pas mois).
• Retest : revérifier chaque correction (le fix casse parfois autrement). « Corrigé » sans retest = peut-être corrigé.

Exemple : un finding qui fait agir

[XSS stockée — Critique] Pseudo non échappé (preuve : capture + requête).
Impact : vol de sessions de tous les visiteurs.
Fix : échappement framework + DOMPurify sur le Markdown, CSP en renfort.
Deadline : 7 jours. Retest : prévu le JJ.

Cas réel

Rapport de 80 pages, 45 findings « moyens », zéro résumé : 6 mois plus tard, 2 corrigés. Refonte en 5 critiques actionnables + retest daté : tout corrigé en 3 semaines. La forme fait la correction.

Pièges

• Jargon sans impact business : « XSS stockée » ne parle pas à la direction ; « vol de sessions clients » si.
• 45 findings sans ordre : trier impitoyablement, le reste en annexe.
• Pas de retest : 30 % des « corrigé » ne le sont pas (fix partiel, autre endpoint). Revérifier toujours.

À retenir

Exécutif business + findings actionnables + deadlines + retest : le rapport sert à corriger.