Le SAST analyse le code sans exécuter l’application afin de repérer tôt des flux de données dangereux, erreurs de validation, secrets ou usages risqués d’API. Il est utile dans une CI, mais ne prouve jamais qu’une application est sécurisée.
Un bon déploiement SAST commence sur les changements de code, avec des règles adaptées au langage et une procédure de tri. Il doit être complété par la revue humaine, l’analyse des dépendances, la recherche de secrets et des tests dynamiques.
Limite essentielle : OWASP souligne les faux positifs et la faible visibilité du SAST sur l’authentification, les contrôles d’accès, la configuration et le comportement réel à l’exécution.
Analyse
Code au repos
Moment
Commit et CI
Résultat
Alertes à vérifier
Que détecte réellement un outil SAST ?
Selon le langage et le moteur, le SAST peut suivre des données depuis une entrée non fiable jusqu’à une fonction sensible, signaler une injection potentielle, un secret codé en dur, une fonction cryptographique faible ou une erreur de mémoire.
Il ne « pirate » pas l’application. Il raisonne sur le code, le bytecode ou parfois les binaires. Cette visibilité facilite la localisation d’une ligne fautive, mais elle dépend de la qualité du modèle et du contexte disponible.
Comment intégrer le SAST dans une CI/CD
- Lancez une analyse complète pour établir une base, sans bloquer immédiatement tous les déploiements.
- Analysez chaque pull request et affichez les alertes sur les lignes modifiées.
- Bloquez seulement les vulnérabilités nouvelles, critiques et suffisamment fiables.
- Attribuez un propriétaire et un délai de traitement à chaque alerte acceptée.
- Mesurez les faux positifs, le délai de correction et les régressions.
- Mettez à jour règles, parseurs et versions de langage.
SAST, DAST, SCA et secret scanning : quelles différences ?
- SAST : cherche des faiblesses dans le code sans exécution.
- DAST : teste une application déployée depuis l’extérieur.
- SCA : inventorie les dépendances et vulnérabilités connues.
- Secret scanning : repère clés, jetons et mots de passe exposés.
- Revue manuelle : vérifie la logique métier, les autorisations et les hypothèses.
Comment réduire les faux positifs sans masquer le risque
Commencez par les règles à forte confiance, fournissez au moteur les frameworks utilisés et documentez chaque suppression. Une alerte ne doit être ignorée qu’avec une justification, un périmètre et une date de révision. Les exclusions globales par fichier ou catégorie créent rapidement des angles morts.
Les outils open source peuvent convenir à un premier périmètre, mais la page liée affiche une date future au 25 juillet 2026 et ne doit pas servir de preuve d’actualité. Comparez plutôt la couverture réelle du langage, l’intégration à votre forge et la qualité du tri.
Quels indicateurs suivre ?
Évitez de piloter uniquement le nombre d’alertes. Suivez la part de dépôts couverts, les vulnérabilités nouvelles, le temps médian de tri et de correction, les réouvertures et le taux de faux positifs. Reliez les résultats à votre modèle de menace et aux incidents observés.
Le NIST recommande l’analyse de code parmi plusieurs pratiques de vérification. Cette combinaison réduit la surface d’attaque des applications, sans remplacer les tests de sécurité des fonctions sensibles.
Le point GTLF
Le meilleur SAST n’est pas celui qui génère le plus d’alertes, mais celui que l’équipe peut trier et corriger durablement. Commencez par empêcher les nouvelles vulnérabilités critiques, puis réduisez la dette existante.
Questions fréquentes
Que signifie SAST ?
SAST signifie Static Application Security Testing : l’analyse de sécurité d’un code sans exécuter l’application.
Le SAST remplace-t-il un test d’intrusion ?
Non. Il manque le contexte d’exécution, la configuration, certaines autorisations et la logique métier.
Faut-il bloquer la CI sur toutes les alertes ?
Non. Bloquez progressivement les vulnérabilités nouvelles, critiques et à forte confiance après avoir mesuré les faux positifs.
Quelle différence entre SAST et SCA ?
Le SAST analyse le code de l’application ; le SCA inventorie surtout les composants tiers et leurs vulnérabilités connues.
Quand lancer le SAST ?
Sur les pull requests pour un retour rapide, et périodiquement sur l’ensemble du dépôt pour détecter les effets de nouvelles règles.
Sources
- OWASP — Source Code Analysis Tools
- OWASP — Static Code Analysis
- NIST — Secure Software Development Framework
L’autrice
Laura Jung
Rédactrice en chef de GTLF, Laura Jung couvre les tendances culturelles, le lifestyle, la maison, la technologie et les usages numériques, avec une attention particulière portée à la clarté des informations et des sources.