Scan statique et attaque en marche
Deux familles d'analyse de sécurité qui ne regardent pas le même objet. Le **scan statique** lit le code source au repos et signale les motifs qu'il reconnaît comme dangereux : secret écrit en dur, requête construite par concaténation, entrée jamais validée. L'**attaque en marche** démarre l'application, lui envoie de vraies requêtes hostiles et observe ce qui cède : parcours d'authentification rejoué, identifiant modifié dans l'adresse, champ retourné qui n'aurait pas dû l'être. La première voit ce qui est écrit, la seconde voit ce qui se passe. Une règle d'accès mal branchée n'existe nulle part dans un fichier : elle n'apparaît qu'une fois les pièces assemblées et le service en route. C'est la raison pour laquelle un tableau de bord entièrement vert ne dit rien tant qu'on ignore laquelle des deux analyses l'a produit.
Forces
- Sépare deux couvertures que le vocabulaire courant confond, donc rend lisible ce qui manque encore
- Donne un critère de tri utilisable : la faille tient-elle dans une ligne, ou dans un enchaînement ?
Limites
- La frontière se brouille sur les analyses interactives, qui instrumentent le code pendant qu'il tourne
- Connaître la distinction ne dit pas quoi corriger en premier : c'est une grille de lecture, pas une priorisation
Pour qui
- Développeur qui met en ligne une interface de programmation manipulant des données d'utilisateurs
- Responsable produit qui doit lire un rapport de sécurité sans savoir ce qui a été mesuré