Comprendre le rapport d'un pentest : comment lire la criticité des failles

Un rapport de test d’intrusion arrive souvent avec une liste de constats classés « critique », « élevé », « moyen », « faible », assortis de scores à deux décimales. Ces chiffres inspirent confiance, et c’est précisément le risque : ils sont calculés à partir d’hypothèses standardisées qui ne connaissent rien de votre métier.

Savoir les lire, c’est savoir quand les suivre et quand les corriger.

Ce que mesure le score CVSS

Le CVSS (Common Vulnerability Scoring System) attribue une note de 0 à 10 à partir de caractéristiques techniques de la faille, dans sa version de base :

• Vecteur d’attaque : la faille est-elle exploitable depuis Internet, depuis le réseau local, ou faut-il un accès physique ?
• Complexité : l’exploitation est-elle systématique, ou dépend-elle de conditions favorables ?
• Privilèges requis : faut-il un compte, et avec quels droits ?
• Interaction utilisateur : faut-il qu’une victime clique sur quelque chose ?
• Portée : l’exploitation permet-elle de sortir du composant vulnérable ?
• Impact sur la confidentialité, l’intégrité et la disponibilité.

Les seuils qualitatifs usuels : 9,0–10,0 critique ; 7,0–8,9 élevé ; 4,0–6,9 moyen ; 0,1–3,9 faible.

L’intérêt du CVSS est sa reproductibilité : deux auditeurs évaluant la même faille aboutissent à des notes proches, et le calcul est vérifiable, chaque score étant accompagné d’un vecteur normalisé.

Ce que le score ne mesure pas

Le score de base ignore volontairement le contexte. Trois angles morts en découlent.

La valeur des données concernées. Une lecture non autorisée est notée de la même façon qu’il s’agisse de préférences d’affichage ou du dossier médical de trente mille personnes. Le CVSS distingue l’ampleur de l’impact technique, pas la nature métier de la donnée.

La réalité de votre exposition. Une faille théoriquement critique dans un composant que vous n’exposez pas, ou protégé en amont par un contrôle spécifique, ne présente pas le même risque effectif.

L’effet de combinaison. Trois constats notés « moyen » qui s’enchaînent (une fuite d’identifiants internes, un contrôle d’accès imparfait, une élévation de privilèges limitée) peuvent constituer un chemin complet vers les données de tous vos clients. Chaque maillon isolé reste moyen ; la chaîne est critique.

C’est pourquoi un bon rapport comporte, à côté du score CVSS, une criticité contextualisée attribuée par l’auditeur en connaissance de votre métier. Quand les deux divergent, l’écart doit être expliqué. Un rapport qui ne donne que le score brut sous-traite à un calcul générique une décision qui vous appartient.

Les cinq informations à chercher dans chaque constat

Un constat exploitable contient toujours :

1. La localisation précise : endpoint, paramètre, fichier, ligne. « L’application est vulnérable aux IDOR » n’est pas un constat, c’est un thème.
2. Le mécanisme, expliqué : pourquoi le contrôle ne fonctionne pas, et pas seulement le fait qu’il ne fonctionne pas.
3. La preuve : requête, capture, jeu de données permettant à votre équipe de reproduire puis de vérifier la correction.
4. L’impact décrit en termes métier : « permet à tout utilisateur authentifié de lire les factures des autres organisations » plutôt que « violation de confidentialité ».
5. Une recommandation actionnable, adaptée à votre pile technique. « Valider les entrées » n’est pas une recommandation.

Si l’un de ces éléments manque, demandez-le. Un prestataire sérieux le fournit sans discuter.

Construire votre propre priorisation

Le classement du rapport est un point de départ, pas un ordre de traitement. Une priorisation utile croise trois dimensions.

La criticité contextuelle, telle que vous l’évaluez, en tenant compte de la sensibilité réelle des données et de vos obligations réglementaires.

Le coût de correction. Un constat élevé corrigé en deux heures passe avant un constat critique demandant une refonte de trois semaines, dont il faut commencer la conception en parallèle.

La portée de la correction. Certains correctifs traitent un symptôme, d’autres suppriment une classe entière de défauts. Déplacer le filtrage multi-tenant dans la couche d’accès aux données coûte plus cher que corriger trois endpoints, et rend structurellement impossibles les dizaines de cas que l’auditeur n’a pas eu le temps d’examiner.

Une trame de traitement raisonnable : corriger sous 72 heures ce qui est exploitable sans authentification et touche des données clients ; sous deux semaines ce qui est exploitable depuis un compte standard ; dans le trimestre le reste, en regroupant par cause commune.

Les mentions à ne pas survoler

Le périmètre et ses limites. La section la plus importante du rapport, et la moins lue. Elle indique ce qui n’a pas été testé : c’est là que se trouve votre risque non mesuré.

Les constats « informatifs ». Souvent relégués en annexe, ils décrivent des éléments non exploitables en l’état mais qui facilitent une attaque future : version de composant exposée, message d’erreur trop précis, absence d’en-tête de sécurité. Leur traitement est peu coûteux.

L’absence de constat sur un composant. Elle peut signifier « examiné, rien trouvé » ou « pas eu le temps ». Ce n’est pas la même information, et le rapport doit permettre de trancher.

Ce qu’un rapport ne dit jamais

Il ne dit pas que votre application est sûre. Il dit qu’à une date donnée, sur un périmètre donné, avec un temps donné, un auditeur a trouvé ces éléments-là. Un rapport sans constat critique est une bonne nouvelle relative, pas un certificat.

La bonne question à poser à votre prestataire n’est d’ailleurs pas « combien de failles critiques ? », mais : « si vous aviez eu cinq jours de plus, où auriez-vous cherché ? » La réponse vaut souvent plus que la moitié du rapport.