[Aller au contenu principal](#main-content) # SAST (Static Application Security Testing) devsecops ## Définition Le [SAST (Static Application Security Testing)](/glossaire/sast) est une méthode d'analyse de sécurité applicative consistant à examiner le code source, le bytecode ou le binaire d'une application sans l'exécuter, afin de détecter des vulnérabilités structurelles avant même la compilation ou le déploiement. Les outils SAST — SonarQube, [Checkmarx](/glossaire/checkmarx), [Veracode](/glossaire/veracode), Semgrep, Fortify — parcourent le code à la recherche de patterns dangereux connus : injections SQL potentielles, absence de validation d'entrée, usage de fonctions cryptographiques obsolètes, gestion incorrecte des exceptions révélant des informations sensibles, ou hardcoding de secrets. Contrairement au DAST qui teste l'application en fonctionnement, le SAST intervient au plus tôt du cycle de développement (shift-left), directement dans l'IDE du développeur ou en pipeline CI/CD, permettant de corriger une faille avant qu'elle n'atteigne la production, à un coût de remédiation nettement inférieur. Sa principale limite réside dans un taux de faux positifs relativement élevé, nécessitant un travail de tuning des règles et de triage par les équipes sécurité pour éviter la fatigue d'alerte des développeurs. Le SAST couvre les référentiels [OWASP Top 10](/glossaire/owasp-top-10-web) et CWE, et constitue un pilier des pratiques [DevSecOps](/glossaire/devsecops) aux côtés du SCA (analyse de composants tiers) et du DAST, avec lesquels il est souvent combiné pour une couverture complète du cycle de développement logiciel sécurisé (SSDLC). Le **SAST** (*Static Application Security Testing*, ou analyse statique de sécurité applicative) désigne l'ensemble des techniques permettant d'**examiner le code source, le bytecode ou le binaire d'une application afin d'y détecter des vulnérabilités, sans jamais l'exécuter**. Là où un test d'intrusion observe le comportement d'une application vivante, le SAST raisonne sur le texte du programme lui-même : il lit, modélise et parcourt le code comme le ferait un relecteur — mais à l'échelle de millions de lignes et en quelques minutes. On parle également de test « boîte blanche », puisque l'outil dispose d'une visibilité totale sur l'implémentation. ### Comment fonctionne un moteur SAST Un analyseur statique moderne ne se contente pas de chercher des motifs textuels. Le traitement se déroule généralement en quatre étapes : - **Parsing et construction de l'AST** : le code est transformé en *Abstract Syntax Tree*, une représentation arborescente qui capture la structure syntaxique réelle (fonctions, appels, affectations) indépendamment de la mise en forme. - **Graphes de flux** : l'outil dérive un *Control Flow Graph* (chemins d'exécution possibles) et un *Data Flow Graph* (propagation des valeurs entre variables). - **Analyse de teinte (*taint analysis*)** : c'est le cœur du SAST. Le moteur identifie des **sources** de données non fiables (paramètres HTTP, fichiers, variables d'environnement), des **puits** dangereux (exec(), requête SQL concaténée, désérialisation) et vérifie s'il existe un chemin reliant les deux *sans passer par un assainisseur* (*sanitizer*) reconnu. - **Application de règles** : les résultats sont confrontés à une base de règles écrites par l'éditeur ou par l'équipe, souvent mappées sur les référentiels **CWE** et **OWASP Top 10**. Les outils les plus répandus illustrent trois philosophies différentes. **SonarQube** combine qualité de code et sécurité dans une plateforme centralisée avec suivi de la dette technique. **Semgrep** mise sur des règles lisibles écrites dans une syntaxe proche du code analysé, ce qui rend la personnalisation accessible aux développeurs. **CodeQL** (GitHub) va plus loin en traitant le code comme une base de données interrogeable via un langage de requête déclaratif, permettant des recherches de vulnérabilités très fines — c'est l'approche retenue pour la plupart des campagnes de *variant analysis* après la découverte d'une faille. ### Ce que le SAST détecte concrètement - **Injections** : SQL, LDAP, XPath, commandes système, injection de templates côté serveur (SSTI). - **Secrets codés en dur** : clés API, mots de passe, jetons, certificats privés committés dans le dépôt. - **Désérialisation non sécurisée** : appels à pickle.loads(), ObjectInputStream ou unserialize() sur des données externes. - **Cryptographie faible** : usage de MD5/SHA-1 pour du hachage de mot de passe, mode ECB, vecteurs d'initialisation statiques, générateurs pseudo-aléatoires non cryptographiques. - **Contrôles d'accès manquants** sur des routes ou des méthodes exposées, et **XSS** par rendu non échappé. - **Path traversal** et écritures de fichiers pilotées par une entrée utilisateur. Exemple typique : une fonction Python qui construit cursor.execute("SELECT * FROM users WHERE id = " + request.args['id']) déclenchera une alerte d'injection SQL, car le moteur trace le chemin entre la source request.args et le puits execute() sans requête paramétrée intermédiaire. ### Place du SAST dans une chaîne DevSecOps Le SAST est le maillon le plus précoce du *shift left* : il intervient dès l'écriture du code, quand la correction coûte le moins cher. Il se complète — sans se substituer — à d'autres briques : - le **DAST**, qui teste l'application en cours d'exécution et découvre les problèmes de configuration ou d'environnement invisibles dans le code ; - le **SCA** (*Software Composition Analysis*), qui inventorie les dépendances tierces et leurs CVE, un périmètre que le SAST ne couvre pas ; - l'**IAST**, hybride instrumentant l'application pour corréler code et trafic réel ; - la **SBOM** et la signature d'artefacts, pour la traçabilité de la chaîne d'approvisionnement logicielle. ### Limites à connaître Le SAST souffre structurellement de **faux positifs** : n'ayant pas de contexte d'exécution, il signale des chemins théoriquement atteignables mais neutralisés en pratique. Symétriquement, il génère des **faux négatifs** face au code dynamique (réflexion, eval, injection de dépendances), aux failles de logique métier et aux erreurs d'autorisation contextuelles. Un scanner ne remplace ni la revue de code humaine, ni la modélisation de menaces. ### Bonnes pratiques de mise en œuvre - **Intégrer au plus tôt** : pré-commit ou IDE pour les règles rapides, pipeline CI pour l'analyse complète, avec un rapport publié sur chaque *pull request*. - **Adopter le *diff scanning*** : n'échouer la build que sur les vulnérabilités introduites par le changement, et traiter l'historique via un plan de réduction de dette dédié. - **Calibrer avant d'imposer** : démarrer en mode observation, trier les alertes, désactiver ou affiner les règles bruyantes, puis passer en blocage sur les seules sévérités critiques et hautes. - **Écrire des règles maison** pour les conventions internes : appel obligatoire à une fonction d'assainissement, interdiction d'une API dépréciée, contrôle d'usage d'un client HTTP validé. - **Documenter les exceptions** : toute suppression d'alerte doit être justifiée, datée et révisable, jamais un commentaire d'inhibition anonyme. - **Mesurer** : densité de vulnérabilités pour 1 000 lignes, délai moyen de remédiation, taux de faux positifs — ces indicateurs alimentent utilement un tableau de bord de conformité (ISO 27001, NIS 2, exigences de développement sécurisé). Bien intégré, le SAST transforme la sécurité applicative en boucle de rétroaction continue plutôt qu'en audit ponctuel de fin de cycle : le développeur reçoit le signal pendant qu'il a encore le contexte en tête, ce qui reste le levier de correction le plus efficace. ## **Articles liés Un projet cybersécurité ? Expert dispo · Réponse 24h Devis ** **