Selon la méthode, elle peut inspecter le code source, des représentations intermédiaires, le bytecode ou les binaires compilés. Les techniques vont de la correspondance de motifs à l'analyse de flux de contrôle, de flux de données et de marquage qui trace les données non fiables vers des opérations sensibles.
Parce que le SAST travaille sur la représentation interne du logiciel, les constats peuvent souvent identifier un fichier, une fonction et une ligne ou un chemin de code que les développeurs peuvent revoir. Il peut fonctionner tôt et de façon répétée dans un éditeur, une pull request ou un build. Son indice est cependant une affirmation fondée sur un modèle du code — pas une preuve qu'un attaquant peut atteindre et exploiter la condition dans le système déployé.
Points clés
Indices examinésCode propriétaire ou artefacts compilés, contexte de build, sémantique du langage et chemins modélisés entre entrées, transformations de données et opérations sensibles pour la sécurité.
Constats typiquesChemins d'injection, opérations mémoire dangereuses, usage cryptographique faible, secrets codés en dur, API non sûres et violations des règles de codage définies par l'organisation.
Exploitation saineFaire correspondre les analyseurs aux langages et frameworks pris en charge, préserver des réglages de scan reproductibles, valider les constats à fort impact et réinjecter les défauts confirmés dans les standards d'ingénierie.
Limite importanteLe SAST peut produire faux positifs et faux négatifs. Il manque couramment la configuration de déploiement, l'état d'exécution, le comportement des services externes et assez de contexte métier pour identifier de nombreuses failles d'autorisation ou de flux de travail.