Corriger et retester les constats d'un pentest : méthode et preuves

Niveau : débutant à intermédiaire.

Prérequis : savoir lire un constat de pentest, distinguer vulnérabilité, impact, sévérité et priorité, et comprendre les notions d'environnement, de version et de preuve. Aucun outil offensif n'est requis.

Le processus présenté suppose que le test initial et le retest sont autorisés, avec un périmètre, des règles d'engagement et des données de test. L'exercice utilise uniquement un dossier fictif dans un document local. Les délais, responsabilités et critères d'acceptation doivent être adaptés à l'organisation, au contrat et aux obligations applicables.

La remise du rapport ne termine pas le traitement. Chaque constat doit recevoir un identifiant stable, un propriétaire, une décision, une priorité, une échéance, un critère de correction et un statut. Le propriétaire coordonne le résultat, même si plusieurs équipes réalisent les changements. Sans cette attribution, les recommandations restent des intentions.

Commence par une réunion de clarification. Le testeur explique l'observation, les préconditions, l'impact, les actifs concernés et les limites. L'équipe technique confirme la version, le composant responsable et les dépendances. Le responsable du risque arbitre l'urgence à partir de la sévérité, de l'exposition, de la criticité métier et des contrôles compensatoires. La priorité ne doit pas être copiée mécaniquement depuis un score.

Le registre distingue au moins quatre décisions : correction, mesure compensatoire temporaire, acceptation formelle du risque ou investigation complémentaire. « Faux positif » exige une justification fondée sur les faits, pas une fermeture rapide. Un constat peut aussi être dupliqué, hors périmètre de l'équipe ou déjà corrigé dans une version ultérieure, mais chaque statut doit pointer vers une preuve.

Le NIST SP 800-115 décrit les activités postérieures au test, dont l'analyse des causes, les recommandations et la réduction des vulnérabilités. Ce cadre aide à maintenir une continuité entre le test, la décision et la vérification, sans imposer un outil de tickets particulier.

Une recommandation de rapport indique souvent un objectif, mais l'équipe doit le transformer en changement réalisable. Pour un défaut d'autorisation, « contrôler les droits côté serveur pour chaque objet » est un objectif. Le plan précise ensuite le composant, la règle attendue, les rôles concernés, la stratégie de déploiement et les tests qui démontreront le résultat.

Le critère de correction doit être écrit avant le changement. Il décrit ce qui doit réussir, ce qui doit être refusé et ce qui doit rester inchangé. Il évite les formulations invérifiables comme « sécuriser complètement l'API ». Un critère utile peut demander que le compte fictif A ne lise plus la ressource fictive B, que le propriétaire légitime conserve son accès et que l'événement de refus soit journalisé sans données sensibles.

Corriger la cause vaut mieux que masquer le symptôme. Cacher un bouton ne remplace pas un contrôle serveur. Bloquer une seule valeur ne corrige pas une validation générale. Mettre à jour une dépendance sans vérifier la version réellement déployée ne prouve rien. Une analyse de cause peut révéler un modèle d'autorisation absent, un test automatisé manquant ou une configuration réintroduite à chaque déploiement.

Le plan inclut une voie de retour, les validations nécessaires et l'observabilité. Il sépare la correction durable des mesures temporaires, par exemple limiter une exposition ou renforcer une alerte en attendant le changement principal.

La preuve de correction n'est pas une capture portant seulement la mention « corrigé ». Elle doit permettre de relier le changement au constat. Un dossier utile contient l'identifiant du constat, la version du code ou de la configuration, l'environnement, la date de déploiement, le responsable, les tests exécutés et leurs résultats. Un lien vers une demande de changement ou une revue peut compléter l'ensemble.

Les preuves varient selon le problème : résultat d'un test unitaire, test d'intégration, extrait de configuration expurgé, journal de pipeline, capture d'un comportement attendu ou compte rendu d'une revue. Il faut montrer à la fois le cas auparavant défaillant et les cas légitimes importants. Une correction qui interdit tout accès peut faire disparaître le constat tout en cassant le service.

Le NIST SP 800-53 Rev. 5, contrôle CA-5 traite des plans d'action et jalons pour documenter les mesures correctives et suivre leur progression. Cette référence soutient la traçabilité, mais le niveau de formalisation doit rester proportionné au contexte.

Minimise les preuves. Masque les secrets, jetons et données personnelles. Préfère des comptes et objets synthétiques. Définis les destinataires, la durée de conservation et le canal de partage. Une preuve moins volumineuse, mais reliée précisément au résultat, est souvent plus forte qu'une archive brute difficile à interpréter et risquée à conserver.

Le retest, ou contre-vérification, vise les constats convenus. Il ne commence pas par une promesse vague de « tout vérifier à nouveau ». Le bon de retest énumère les identifiants, les actifs, les versions, l'environnement, les comptes, les créneaux, les contacts, les méthodes autorisées et les conditions d'arrêt. Il précise si des tests de régression limités sont inclus.

Avant le créneau, l'équipe transmet le statut de chaque correction et sa preuve. Le testeur confirme que l'environnement représente bien la version annoncée et que les comptes fonctionnent. Si un constat concernait la production, un retest en préproduction ne permet une conclusion sur la production que si la comparabilité est établie et documentée.

Le scénario reprend les préconditions et le résultat attendu du constat initial. La preuve antérieure sert de référence, mais elle ne doit pas être répétée aveuglément si elle risquait d'altérer le service ou d'exposer des données. Les règles d'engagement peuvent imposer une preuve encore plus limitée.

Le Web Security Testing Guide de l'OWASP fournit une structure de vérifications Web et insiste sur des exigences de test dérivées du contexte. Pour le retest, cette logique aide à traduire chaque correction en cas attendu, tout en gardant une portée annoncée. Le testeur ne doit pas élargir spontanément la contre-vérification à des fonctions hors mandat.

Un retest peut produire plusieurs statuts. Corrigé signifie que le constat n'est plus reproductible dans les conditions et la version testées, et que les contrôles attendus inclus ont réussi. Partiellement corrigé signifie qu'une variante, un rôle ou un actif reste affecté. Non corrigé indique que le comportement initial persiste. Non vérifiable s'applique lorsque l'environnement, les accès ou les preuves ne permettent pas de conclure.

Un statut doit être accompagné des conditions, observations et limites. « Corrigé » ne signifie pas que toute la classe de vulnérabilités a disparu du système. Si une seule API, un seul rôle et un seul objet ont été retestés, la conclusion reste bornée à cet échantillon. Une campagne de régression ou un nouvel audit peut être nécessaire pour obtenir une couverture plus large.

Si une gravité technique est recalculée, la spécification CVSS v4.0 de FIRST permet d'expliciter le vecteur et les métriques. Le score ne ferme toutefois pas le risque à lui seul. Une mesure compensatoire peut réduire l'exposition sans supprimer la faiblesse, tandis qu'une correction technique peut laisser un risque de processus ou une dette sur d'autres composants.

Le rapport de retest conserve les identifiants initiaux, décrit la nouvelle version, indique le statut, fournit une preuve minimisée et liste les limites. Toute nouvelle faiblesse observée suit le mécanisme convenu : signalement séparé, qualification et autorisation avant approfondissement.

Un tableau de bord utile suit les constats ouverts, les échéances décidées, l'âge, les propriétaires, les blocages et les résultats de retest. Il peut montrer le délai médian de traitement par priorité ou le taux de réouverture. Ces métriques aident à repérer un problème de capacité ou de processus, mais elles peuvent être manipulées si la fermeture compte davantage que la preuve.

La qualité vient des critères et des contrôles. Pour les causes récurrentes, ajoute des tests dans le cycle de développement, des règles de configuration, des revues ou des contrôles de déploiement. Un constat d'autorisation peut produire un test automatisé par rôle. Une dépendance obsolète peut conduire à améliorer l'inventaire et la politique de mise à jour. La remédiation devient alors une amélioration du système, pas seulement la fermeture d'un ticket.

Les référentiels de qualification PASSI de l'ANSSI replacent le rapport, les constats et la restitution dans une prestation structurée. Pour une mission qualifiée ou réglementée, les exigences contractuelles et documentaires applicables doivent guider le processus exact.

Organise enfin une revue après quelques cycles : constats réouverts, preuves insuffisantes, retests bloqués, corrections symptomatiques et régressions. Le résultat observable attendu est une règle améliorée, un modèle de ticket, un test ajouté ou une responsabilité clarifiée, pas seulement une réunion de plus.

Travaille uniquement dans un document local, sans outil offensif ni cible réelle. Le constat fictif WEB-017 indique qu'un compte de test mila pouvait consulter le dossier synthétique DOSSIER-B attribué au compte noe sur portail.exemple.test. Le rapport limite l'observation à ces deux comptes, à un type de dossier et à la version 1.4.0.

Crée une fiche avec : propriétaire, cause supposée à confirmer, décision, mesure temporaire, correction durable, version cible, échéance décidée, preuve attendue et statut. Définis trois tests locaux ou documentaires : mila reçoit un refus pour DOSSIER-B, noe conserve son accès légitime et le refus produit un journal expurgé. Ajoute une vérification pour un autre dossier synthétique seulement si elle est incluse dans le périmètre fictif.

Prépare ensuite un bon de retest indiquant la version 1.4.1, l'environnement local, les deux comptes fictifs, les trois résultats attendus, la condition d'arrêt et la règle de minimisation. Termine par un mini-rapport proposant les statuts corrigé, partiel, non corrigé et non vérifiable, avec la preuve requise pour chacun.

Critère observable

L'exercice est réussi si l'identifiant reste stable, si chaque changement pointe vers une preuve, si les accès refusé et légitime sont tous deux testés, et si la conclusion reste limitée à la version, aux comptes et au type de dossier annoncés.

Erreurs et limites

Ne ferme pas le constat sur la seule déclaration d'un développeur. Ne confonds pas déploiement et preuve. Ne marque pas « corrigé » si l'accès légitime est cassé ou si l'environnement ne correspond pas. Ce scénario entraîne au suivi et au retest, mais ne représente ni toutes les régressions, ni un nouveau pentest complet, ni une garantie de sécurité future.