SAST : Static Application Security Testing
Sécurité
SAST : Static Application Security Testing. « Test statique de sécurité applicative », par analogie avec l'inspecteur qui épluche les plans d'un immeuble avant qu'on ait coulé la moindre dalle. On analyse le code source, sans l'exécuter, pour y repérer des vulnérabilités.
Principe : L'outil parse le code source, le bytecode ou le binaire, construit une représentation du programme (arbre syntaxique, flot de données) et suit les entrées non fiables jusqu'aux fonctions sensibles. Il repère ainsi des injections, des secrets codés en dur ou des appels cryptographiques douteux.
Intégration : On le branche dans l'éditeur ou dans la chaîne d'intégration continue, à chaque commit ou pull request. Le défaut est signalé au moment où il coûte le moins cher à corriger : quand son auteur se souvient encore de ce qu'il a écrit.
Limites : Sans contexte d'exécution, l'analyse manque les failles de configuration ou de logique métier et produit des faux positifs à la pelle. Vingt ans de métier apprennent que le premier scan d'une base de code existante remonte quatre mille alertes, et que la tentation de toutes les marquer « faux positif » d'un seul clic résiste mieux que n'importe quelle faille.
Face au test dynamique : Le SAST regarde le code de l'intérieur, sans le lancer ; le DAST attaque l'application en fonctionnement, de l'extérieur. Les deux se complètent plus qu'ils ne se remplacent.
Ce qui arrive si on s'en passe
Sans analyse statique, le code source part en production sans qu'aucun outil n'ait suivi ses flux de données. Une entrée utilisateur concaténée dans une requête SQL, une commande système construite à partir d'un paramètre, un secret écrit en dur ou l'appel à une primitive cryptographique obsolète restent invisibles jusqu'à ce qu'un test dynamique, un audit ou un attaquant les rencontre. Le défaut n'apparaît alors qu'une fois le code exécuté et exposé, au moment où sa correction coûte le plus cher : il faut le corriger, relivrer, puis vérifier s'il a déjà été exploité. Le signal au plus près de l'erreur disparaît aussi : rien n'alerte au moment du commit, et un même motif vulnérable peut se recopier dans d'autres modules sans qu'aucune règle ne le signale lors de la revue suivante.
Explication de la marmotte
Un programme informatique, c'est un long texte d'instructions écrit par des humains. Ce genre d'outil relit ce texte sans jamais lancer le programme, un peu comme un correcteur d'orthographe qui chercherait des erreurs dangereuses plutôt que des fautes d'accord : une porte laissée ouverte, un mot de passe écrit en toutes lettres, une information tapée par un inconnu et utilisée sans vérification. Avantage : on repère les problèmes très tôt, avant que quiconque utilise le logiciel. Inconvénient : l'outil se trompe parfois et crie au loup pour rien, alors une personne doit trier ses remarques.
Où ce terme est utilisé
- Intégrer SAST, DAST et IAST dans une CI/CD (12 occurrences)
- Comment revoir le code de sécurité au-delà du linter (1 occurrence)
- Culture de sécurité dans une équipe produit (1 occurrence)
- Revue de sécurité du code généré par un assistant IA (1 occurrence)
- SLSA : niveaux Build, provenance in-toto et vérification (1 occurrence)