Une vulnérabilité déclarée corrigée n’est pas nécessairement corrigée : un correctif peut être appliqué partiellement, contourné par un autre chemin, annulé par un déploiement ultérieur, ou traité sur un serveur mais pas sur les autres.
Le retest consiste à rejouer précisément les scénarios ayant permis d’identifier chaque constat du rapport initial et à statuer sur leur état réel. C’est le document qui permet d’affirmer devant un tiers — direction, client, assureur, ou auditeur — que les corrections ont été vérifiées et non simplement déclarées.
Une prestation commandée séparément
Le retest n’est pas inclus dans un test d’intrusion. Il intervient après vos travaux de correction, à une date que vous choisissez, et suppose une nouvelle autorisation d’intervention.
Cette séparation est aussi ce qui lui donne sa valeur : un retest a du sens quand les correctifs sont réellement en place, pas quelques jours après la remise du rapport.
Déroulement
- Reprise du rapport initial et du journal d’actions associé.
- Rejeu de chaque scénario dans les mêmes conditions que lors du test initial.
- Recherche de contournements lorsque le correctif appliqué traite le symptôme plutôt que la cause.
- Statut par constat : corrigé, partiellement corrigé, non corrigé, ou risque accepté par le client.
Périmètre
Le retest porte uniquement sur les constats du rapport initial. Les modifications intervenues depuis, les nouveaux services et les évolutions du périmètre ne sont pas couverts. Lorsque l’environnement a significativement changé, un nouveau test d’intrusion apporte davantage qu’un retest.
Livrable
Un rapport de retest reprenant chaque constat, son état, les preuves de vérification, et le cas échéant les raisons pour lesquelles la correction n’est pas jugée suffisante. Ce document est utilisable comme pièce justificative auprès d’une direction, d’un client ou d’un assureur.