01Comment fonctionne le SAST
Les moteurs SAST traduisent le code en représentations intermédiaires – arbres syntaxiques abstraits ou faits de programme relationnels – puis y appliquent des analyses de flux de contrôle, de flux de données et de taint. CodeQL, par exemple, extrait le code dans une base de données et exprime les vulnérabilités comme des requêtes dans une extension de Datalog ; Semgrep reconnaît des motifs structurellement sur l'arbre syntaxique, avec sources, puits et sanitizers comme règles de taint. La profondeur fait la différence : l'analyse au sein d'une fonction est le standard – l'analyse interprocédurale au-delà des frontières de fichiers et de fonctions distingue les classes d'outils et reste, chez Semgrep par exemple, réservée à l'offre commerciale.
02La limite prouvée : l'exactitude est impossible
D'après le théorème de Rice, toutes les propriétés sémantiques non triviales des programmes sont indécidables – une analyse qui trouverait toutes les vulnérabilités sans jamais donner de fausse alerte est mathématiquement impossible. Chaque outil choisit donc un camp : la sur-approximation (aucun cas manqué dans l'espace modélisé, au prix de fausses alertes systématiques – fondement posé par Cousot & Cousot en 1977 avec l'interprétation abstraite) ou la sous-approximation (plus précise, avec des lacunes). Les faux positifs ne sont pas un défaut d'implémentation mais le prix de l'approche – la seule question est de savoir qui les trie.
03Ce que le SAST trouve de façon fiable
Le SAST excelle sur les classes de défauts à forme stable : injection, appels cryptographiques non sûrs, identifiants en dur, erreurs mémoire en C/C++ – avec fichier, ligne et emplacement exacts, bien avant qu'une application testable n'existe. C'est pourquoi OWASP SAMM place les tests statiques et dynamiques automatisés dès le niveau de maturité 1 de son volet Security Testing : ils sont la base scalable sur laquelle s'appuient les tests manuels plus profonds.
04Ce que le SAST ne peut structurellement pas trouver
L'OWASP nomme clairement les angles morts : défauts d'authentification et d'autorisation, mauvais usage de la cryptographie et erreurs de logique métier sont difficiles voire impossibles à détecter automatiquement – et les erreurs de configuration ne figurent même pas dans le code. La mesure le confirme : dans une étude ISSTA de la TU Munich, six analyseurs C/C++ ont manqué 47 à 80 pour cent de 192 vulnérabilités réelles connues ; même la combinaison de tous les outils en laissait passer 30 à 69 pour cent. Ces classes exigent du threat modeling, des revues – ou du raisonnement sémantique.
Page de connaissance Threat Modeling →05La réalité des faux positifs
Selon la littérature consolidée, entre 35 et 91 pour cent des alertes d'analyse statique ne sont pas actionnables. Une étude de terrain de 2025 – financée par un éditeur – sur près de 3 000 dépôts publics a trouvé plus de 91 pour cent de fausses alertes sur trois classes de défauts classiques, avec un cas extrême de 1 166 findings pour 6 vrais. Et l'analyse de plus de 100 millions de findings AppSec issus de 178 organisations montre que seuls 2 à 5 pour cent exigent une action immédiate. L'alert fatigue n'est pas un facteur mou : c'est la première cause d'échec des programmes SAST.
06Ce que Google et Meta font autrement
Les deux leviers les plus efficaces sont publiés : chez Meta, le taux de correction des scans batch nocturnes était proche de zéro ; dès que la même analyse est apparue comme commentaire dans la revue de code du diff, il est monté à plus de 70 pour cent – même moteur, même taux de fausses alertes. Google n'admet en revue que les analyses dont le taux effectif de fausses alertes reste sous 10 pour cent ; en pratique son système Tricorder se situe juste sous 5 pour cent. La leçon : le point de déploiement et la confiance des développeurs priment sur la qualité de l'outil.
07Évaluer les outils sérieusement
L'OWASP Benchmark est une application Java exécutable de 2 740 cas de test réellement exploitables dans 11 catégories ; les outils sont notés sur le taux de vrais positifs contre celui de faux positifs (indice de Youden). La suite Juliet du NIST ajoute des cas synthétiques sur 118 CWE en C/C++ et 112 en Java. Méfiance envers les annonces « 100 % de détection » : les corpus sont publics, l'overfitting est possible – et des benchmarks récents comme CASTLE montrent que chaque classe d'outils a ses propres schémas d'échec : la vérification formelle minimise les fausses alertes mais échoue hors de son modèle ; les LLM brillent sur des extraits et faiblissent quand le code grossit.
08Un paysage d'outils en plein bouleversement
Les coordonnées ont changé en 2024/2025 : Semgrep a placé ses règles maintenues sous licence propriétaire en décembre 2024 – en réaction, un consortium d'une dizaine d'éditeurs de sécurité a forké le moteur sous le nom d'Opengrep (LGPL ; après un an : 43 releases et l'analyse de taint interfonctionnelle en open source). Sonar a également retiré ses analyseurs de langage de la LGPL. GitHub a scindé Advanced Security en avril 2025 en Code Security (30 US-$ par committer actif/mois) et Secret Protection (19 US-$). Et après deux ans de pause, Gartner a relancé le Magic Quadrant pour l'Application Security Testing en octobre 2025 – avec 16 éditeurs et l'ASPM comme dimension d'évaluation.
09Ce que l'IA change au SAST
Les chiffres les plus solides concernent le tri : des agents LLM derrière un SAST classique ont réduit les fausses alertes sur l'OWASP Benchmark jusqu'à 88,6 pour cent avec seulement 3,1 pour cent de perte de rappel ; sur de vraies alertes CodeQL, ils ont identifié jusqu'à 93,3 pour cent des faux positifs. Copilot Autofix de GitHub ramène le temps médian de correction de 1,5 heure à 28 minutes selon la télémétrie bêta. Et des systèmes autonomes comme Google Big Sleep ou les finalistes du DARPA AIxCC trouvent désormais seuls de vraies vulnérabilités. Les limites de la carte 4 se déplacent – sans disparaître : l'IA complète les couches, elle ne les remplace pas.
Approfondir : AI Code Security → 
