SAST (Static Application Security Testing)
Le SAST analyse le code source sans l'exécuter pour repérer les vulnérabilités au plus tôt : injections, secrets codés en dur, flux de données dangereux.
Le Static Application Security Testing, ou SAST, analyse le code source d'une application sans l'exécuter. L'outil suit les flux de données depuis les entrées utilisateur jusqu'aux fonctions sensibles, la fameuse analyse de teinte, et signale les chemins dangereux : une valeur qui arrive d'un formulaire et finit dans une requête SQL sans échappement, un secret codé en dur, une désérialisation risquée. Tout cela dès l'écriture du code, avant le moindre déploiement.
C'est l'outil du "shift left" : plus une vulnérabilité est détectée tôt, moins elle coûte cher à corriger. Le talon d'Achille du SAST traditionnel, en revanche, est connu de toutes les équipes qui l'ont subi : le bruit. Sans compréhension du contexte, l'analyse purement syntaxique noie les vraies failles sous les faux positifs, et les développeurs finissent par ignorer l'outil. C'est précisément le verrou que les modèles de langage font sauter, en apportant la compréhension du contexte qui manquait aux règles.
Nous comparons les approches dans SAST, DAST, IAST : que change l'IA, et notre module de SAST AI-native applique cette logique : l'analyse statique propose, l'IA contextualise et vérifie.
Ce que l'analyse statique ne peut pas voir
Le SAST excelle sur les défauts locaux au code : concaténation d'une entrée utilisateur dans une requête, secret écrit en dur, algorithme de chiffrement obsolète, désérialisation d'une donnée non fiable. Il bute sur tout ce qui dépend de l'exécution, et cette limite est structurelle, pas une question de maturité d'outil. La configuration réelle du serveur, les règles portées par un pare-feu applicatif, les droits accordés par la base, l'ordre effectif des middlewares : rien de tout cela n'est dans le code source. Un chemin dangereux peut être inatteignable en production, et l'inverse est vrai. C'est pour cela que le DAST reste indispensable : lui teste l'application telle qu'elle tourne.
Le vrai coût du bruit
Le taux de faux positifs d'un SAST ne se paie pas en licence, il se paie en attention. Une équipe qui reçoit plusieurs centaines d'alertes à la première exécution ne les traite pas : elle désactive des règles entières, et souvent les bonnes en même temps que les mauvaises. Le déploiement qui fonctionne est progressif : on n'échoue la CI que sur les alertes critiques introduites par le changement en cours, la dette existante étant traitée à part, à son propre rythme. Notre comparatif SAST, DAST, IAST et ce que l'IA change situe les approches, et l'analyse de SonarQube, ses prix et ses alternatives traite le cas de l'outil le plus répandu.
Questions fréquentes
Le SAST détecte-t-il les failles des bibliothèques tierces ?
Non, ce n'est pas son rôle. Il analyse le code que vous écrivez. L'inventaire et le contrôle des dépendances relèvent de la SCA, qui les confronte aux bases de vulnérabilités connues.
Faut-il bloquer une livraison sur un finding SAST ?
Seulement sur un périmètre restreint et assumé : les alertes critiques introduites par le changement en cours. Bloquer sur l'ensemble de la dette existante arrête la livraison sans améliorer la sécurité, et le contournement devient vite la norme.
Le SAST fonctionne-t-il sur du code généré par IA ?
Oui, avec le même angle mort qu'ailleurs. Il repère les motifs dangereux, pas les décisions d'architecture. Or ce qui manque le plus souvent dans du code généré, ce sont les contrôles d'autorisation, justement hors de portée de l'analyse statique.