Après le rapport de test d’intrusion : le guide pratique du praticien pour le triage, la remédiation et le retest

TL;DR : Moins de la moitié des constats de tests d’intrusion sont un jour corrigés, et même les plus critiques restent ouverts plus d’un mois après l’expiration du SLA. Le rapport n’a jamais été le livrable qui comptait. Ce que vous en faites, voilà ce qui compte. Ceci est un cadre pratique pour trier les constats, prioriser les correctifs et boucler la boucle avec un véritable retest, et non simplement un autre balayage annuel.

La plupart des organisations traitent un rapport de test d’intrusion comme la ligne d’arrivée. Le PDF arrive, quelques tickets sont créés, et l’attention retourne à la feuille de route, jusqu’à ce que le prochain test annuel révèle la moitié des mêmes constats sous un nouveau CVE.

Les données le confirment. Seulement 48 % des vulnérabilités identifiées sont un jour corrigées, et même les constats les plus sévères n’atteignent qu’un taux de correction de 69 %, laissant environ un tiers des risques de premier niveau ouverts, avec un délai médian de résolution de 37 jours contre un SLA typique de deux semaines. L’écart est le plus marqué pour les constats liés à l’IA et aux LLM : ils apparaissent à un taux plus de 2,5 fois supérieur à celui des autres constats, mais ne sont corrigés que 38 % du temps, le taux le plus faible de tous les types d’actifs.
Rien de tout cela n’est un problème de test. C’est un problème de remédiation, et c’est un problème qu’on peut résoudre avec un processus structuré appliqué après chaque mandat.

Pourquoi les constats stagnent

Avant de corriger le processus, il est utile de nommer où il se brise réellement. En pratique, ce n’est rarement une seule défaillance spectaculaire. C’est une poignée de petits écarts qui s’accumulent :

La déduplication n’a jamais lieu

Un test d’application Web et un test d’API révèlent la même faille d’autorisation sous-jacente sous deux angles différents. Sans recoupement, elle apparaît comme deux tickets, est corrigée partiellement une fois, puis réapparaît au test suivant.

La responsabilité est ambiguë

Un constat dans une bibliothèque tierce se situe entre l’équipe d’ingénierie qui l’a intégrée et l’équipe de sécurité qui l’a signalé. Ni l’une ni l’autre ne s’approprie le correctif, donc ni l’une ni l’autre ne le priorise.

La sévérité est aplatie

Un score CVSS seul ne dit pas à un responsable d’ingénierie si un constat est réellement atteignable en production, ou théorique. Tout ce qui dépasse « Moyen » finit dans le même arriéré indifférencié.

Il n’y a pas de boucle de retest

Le constat est marqué « résolu » sur la base d’un changement de code, pas d’un test de vérification. Il est mis en production, et le correctif régresse silencieusement six mois plus tard.
Chacun de ces éléments est un écart de processus, pas un problème technique, ce qui signifie que chacun est solvable sans nouvel outillage.

Un cadre de triage qui priorise réellement

Remplacez la « sévérité » comme seule variable de tri par un prisme en trois volets appliqué à chaque constat :

1. Exploitabilité. Ce constat est-il atteignable par un attaquant non authentifié, ou nécessite-t-il un point d’ancrage interne déjà compromis ? Les constats que votre équipe de test d’intrusion a pu réellement enchaîner pour obtenir un accès supplémentaire pendant le mandat devraient sauter la file d’attente. C’est un signal qu’aucun score CVSS ne capture entièrement.
2. Impact commercial. Devant quoi se trouve ce constat ? Un contrôle d’accès défaillant sur un point de terminaison de facturation client n’est pas le même risque que la même faille sur un outil d’administration interne utilisé par trois personnes. Associez les constats aux données ou au système qu’ils exposent, pas seulement à leur description technique.
3. Coût du correctif. Certains constats de haute sévérité représentent un changement de configuration d’une seule ligne. Certains constats de sévérité moyenne nécessitent une refonte architecturale. Séquencer d’abord les correctifs rapides à fort impact crée un élan et réduit l’exposition réelle plus vite que de travailler strictement selon une liste de sévérité.

Notez chaque constat selon ces trois dimensions, et vous obtenez un ordre de priorisation qui reflète la réduction de risque réelle par unité d’effort d’ingénierie, pas simplement une liste triée selon l’opinion d’un scanneur automatisé.

Boucler la boucle : bâtir une habitude de retest, pas seulement un évènement annuel

Un correctif qui n’a pas été retesté est une hypothèse, pas une résolution. Les organisations qui referment l’écart de remédiation traitent le retest comme une partie permanente du mandat, et non comme une décision d’achat distincte prise des mois plus tard :

• Fixez un point de contrôle de retest à un intervalle fixe après que la remédiation est déclarée, et non « chaque fois que le prochain test annuel aura lieu ».
• Retestez selon la preuve de concept originale, pas seulement le chemin de code corrigé. Les attaquants ne respectent pas les limites de votre correctif.
• Suivez les constats « rouverts » comme une métrique à part entière. Un taux de réouverture en hausse est un signal précoce de rupture de processus, bien avant qu’il ne se manifeste sous forme de brèche.

C’est exactement l’écart que les tests d’intrusion continus d’Orenda sont conçus pour combler. La même rigueur qui distingue une exposition réelle d’un simple constat signalé s’applique aussi à la remédiation : un correctif qui n’a pas été retesté demeure une simple affirmation, pas un résultat validé. Plutôt qu’un correctif qui reste sur un ticket « résolu » jusqu’au prochain mandat annuel, les tests d’intrusion continus maintiennent un point de contrôle de retest à l’agenda comme une composante permanente de la relation, sans nouvelle conversation de cadrage à chaque fois. Les constats sont retestés selon la preuve de concept originale à une cadence fixe, les constats rouverts sont suivis comme une métrique continue plutôt que comme une surprise, et la fenêtre de retest devient une composante intégrée au mandat plutôt qu’un rappel que l’équipe doit planifier elle-même. L’habitude ne s’installe que si la cadence est structurelle, et c’est exactement le problème que l’engagement continu est conçu pour résoudre.

Les constats liés à l’IA et aux LLM ont besoin de leur propre SLA

Étant donné le taux de correction actuel de 38 % pour les constats liés à l’IA et aux LLM, les traiter selon le même SLA qu’une vulnérabilité d’application Web standard fait partie du problème. Ces constats touchent souvent un territoire peu familier pour les équipes d’ingénierie, notamment l’injection de prompt, l’appel d’outils non sécurisé et le traitement des sorties du modèle, et méritent un SLA plus court et un responsable désigné, pas une place dans l’arriéré général où les constats peu familiers ont tendance à stagner le plus longtemps.

Le rapport n’a jamais été le but

Un rapport de test d’intrusion est un instantané du risque à un moment donné. Sa valeur est entièrement déterminée par ce qui se passe dans les semaines qui suivent sa livraison. Les organisations qui referment l’écart de remédiation ne font pas nécessairement plus de tests. Elles font tourner une boucle triage-à-retest plus serrée autour des tests qu’elles font déjà.

Si votre dernier rapport reste en grande partie sans réponse, ce n’est pas une raison d’attendre le prochain cycle annuel. C’est la raison de bâtir la boucle maintenant. Savoir ce qui est réellement exploitable, pas seulement ce qui a été signalé, n’est que la moitié de l’équation. L’autre moitié, c’est savoir ce qui a été réellement corrigé, pas seulement ce qui a été déclaré comme tel. Les mandats de tests d’intrusion continus d’Orenda sont bâtis exactement autour de cette cadence : constats structurés, points de contrôle de retest clairs, et validation qu’un correctif tient réellement, pas seulement un PDF et une poignée de main.

Demandez un devis pour plus d’informations