Comment lire un finding de sécurité automatisé
Une méthode courte pour juger les preuves, la confiance et la prochaine action dans un rapport de sécurité web.
Par Luca Deguin
Une longue liste d’alertes ne fait pas un rapport de sécurité utile. Ce qui compte, c’est ce que chaque alerte démontre réellement. Un finding clair permet de relier une observation à une conclusion, puis de décider s’il faut corriger, reproduire ou enquêter.
Lire l’observation avant la sévérité
Commencez par la requête, la réponse et les conditions dans lesquelles le résultat est apparu. Le scanner a-t-il observé un comportement qui expose des données ou contourne un contrôle ? Ou déduit-il un risque d’un en-tête, d’un nom de route ou d’un indice de configuration ? Ces niveaux de preuve sont différents.
La sévérité décrit un impact potentiel. La confiance indique à quel point les preuves disponibles soutiennent la conclusion. Une hypothèse à fort impact peut garder une faible confiance. Le rapport doit rendre cette différence visible.
Exemple synthétique. L’absence de l’en-tête est observée, mais aucune attaque XSS exploitable n’a été démontrée.
Choisir la suite selon les preuves
Un résultat confirmé mérite une correction reproductible. Un résultat probable peut demander une vérification manuelle ciblée. Une heuristique invite à examiner une configuration ou un comportement précis. Une observation informationnelle aide à comprendre le système sans devenir automatiquement une vulnérabilité.
Par exemple, une route publique ne prouve pas à elle seule un défaut de contrôle d’accès. La question décisive est de savoir si elle renvoie des données que la personne courante ne devrait pas voir. De même, l’absence d’un en-tête défensif peut signaler une amélioration utile sans démontrer une attaque exploitable.
Conserver le contexte utile à une personne
Un bon rapport nomme la surface concernée, explique la conséquence de sécurité et propose une manière sûre de reproduire le résultat. Il indique aussi clairement ce qui reste incertain. Captures et réponses brutes peuvent aider, mais elles ne doivent pas exposer des jetons, des données personnelles ou d’autres secrets à toutes les personnes qui consultent le rapport.
Les tests automatisés sont précieux parce qu’ils répètent les contrôles de façon cohérente. Une revue humaine reste nécessaire lorsque le sens d’une réponse dépend du comportement de l’application, des règles d’autorisation ou du contexte métier.
La première question à poser face à une alerte est simple : qu’a observé l’outil, et que prouve cette observation ? On peut alors traiter les risques confirmés, vérifier les pistes plausibles et garder le reste comme contexte. VICE suit cette approche fondée sur les preuves dans son moteur open source et dans les rapports de la plateforme.