SAST (Static Application Security Testing).

Le SAST analyse le code en le transformant en représentations intermédiaires — un arbre syntaxique abstrait (AST), un graphe de flot de contrôle (CFG) et un graphe de flot de données (DFG) — puis applique des règles de motifs ou de l'analyse de taint pour détecter des constructions non sûres associées aux identifiants CWE. L'analyse de taint est le moteur central : elle marque les sources non fiables (un paramètre HTTP, la lecture d'un fichier), suit la propagation de ces données à travers les variables et les appels de fonction, et lève un résultat lorsqu'elles atteignent un sink dangereux (une requête SQL, exec, une réponse HTML) sans être passées par un assainisseur reconnu. Comme rien ne s'exécute, le SAST fonctionne dans les IDE, les hooks pre-commit et la CI, et peut analyser le code bien avant sa livraison.

Ses angles morts sont bien documentés. Le SAST est performant sur les bugs déterministes (injection SQL, sinks XSS, secrets codés en dur, cryptographie faible) mais génère des faux positifs sur des chemins inatteignables à l'exécution, et passe à côté des failles de configuration, de logique d'authentification et purement runtime — c'est pourquoi les programmes matures le couplent au SCA et au DAST. Le réglage des rulesets et le tri du bruit constituent les véritables coûts opérationnels. Des standards tels qu'OWASP ASVS et le NIST SSDF font référence à l'analyse statique comme contrôle de vérification. Parmi les moteurs courants figurent Semgrep, GitHub CodeQL (qui interroge le code comme une base de données), SonarQube, Checkmarx, Fortify et Snyk Code.

flowchart LR
  SRC[Code source / bytecode] --> P[Parsing en AST + CFG + DFG]
  P --> T[Analyse de taint + règles]
  SO[Source non fiable] -. flux suivi .-> T
  T --> SK{Atteint un sink<br/>sans assainisseur ?}
  SK -->|Oui| F[Résultat mappé à un CWE]
  SK -->|Non| OK[Aucune alerte]
  F --> TR[Triage : corriger ou marquer faux positif]