Le rapport est arrivé. Il contient des vulnérabilités, des preuves et des recommandations. Le travail suivant consiste à organiser les décisions : quoi traiter, qui s’en charge, et comment savoir qu’un risque a réellement diminué. Voici un cadre de travail à adapter avec vos équipes.
En résumé
- Une restitution doit clarifier le périmètre testé, les limites et les constats avant de lancer les corrections.
- La priorité combine l’exposition, l’impact métier, les possibilités d’exploitation et les mesures déjà présentes.
- Chaque action a besoin d’un responsable, d’une échéance et d’un critère de validation.
- Une mesure temporaire et un risque accepté doivent être suivis et réexaminés.
- Le re-test vérifie un périmètre défini ; il ne constitue pas une garantie générale de sécurité.
1. Organiser une restitution à deux niveaux
Réunissez les personnes qui peuvent décider et celles qui vont corriger. La direction a besoin de comprendre les conséquences possibles et les arbitrages attendus. Les équipes techniques ont besoin du scénario, de la preuve et des conditions de reproduction autorisées. Un même constat doit pouvoir circuler entre ces deux lectures.
Commencez par les limites : actifs exclus, comptes indisponibles, créneaux réduits, dépendances externes. Un périmètre non testé ne devient pas sûr parce qu’il ne figure pas dans la liste des vulnérabilités. Le guide de restitution OWASP propose de distinguer notamment la synthèse destinée aux décideurs et les résultats techniques.
2. Construire une priorité argumentée
Le score technique est un point de départ. Ajoutez l’exposition réelle, les privilèges nécessaires, les données accessibles et l’impact d’une interruption. Faites apparaître ce qui est établi et ce qui reste à confirmer. Une dépendance difficile à corriger ne doit pas faire disparaître le risque du tableau de suivi.
Exemple fictif : deux défauts ont une gravité technique comparable. Le premier affecte un service public contenant des données clients ; le second un environnement de test isolé avec des données synthétiques. Leur calendrier peut différer, à condition de documenter cette différence et de vérifier que l’isolation annoncée existe.
3. Transformer le constat en action vérifiable
- Constat : identifiant stable, actif concerné et observation datée.
- Action : modification attendue, dépendances et précautions de déploiement.
- Responsable : une personne ou une équipe qui accepte la prise en charge.
- Échéance : date convenue et circuit d’escalade si elle ne peut pas être tenue.
- Validation : résultat attendu et preuve nécessaire pour clôturer.
Évitez « sécuriser l’application ». Préférez une action contrôlable, par exemple vérifier côté serveur qu’un utilisateur ne peut consulter que les dossiers auxquels il est autorisé. Le modèle de constat et le canevas de plan d’action donnent une structure de départ.
4. Traiter les reports comme des décisions
Lorsqu’un correctif durable n’est pas disponible, consignez la mesure temporaire, son périmètre et sa date de réexamen. L’acceptation d’un risque appartient au responsable habilité ; elle ne se résume pas à déplacer le ticket dans une colonne « plus tard ». Gardez également les raisons d’un refus ou d’une exception.
5. Préparer le re-test et le suivi
Convenez des constats à revoir, des environnements, des accès et du calendrier. Une correction annoncée doit être confrontée au critère défini, puis aux éventuelles régressions. La preuve de clôture indique la version et la date contrôlées. Une évolution ultérieure peut justifier une nouvelle évaluation.
Kenaudit peut servir à centraliser les constats et suivre les actions. Découvrir la plateforme permet de préparer un échange sur votre façon de piloter la remédiation, sans confondre le statut d’un ticket avec une vérification technique.