SAST vs DAST vs IAST : comparatif, sept configurations SAST mesurées, et ce que
l'IA change

SAST, DAST, IAST : trois sigles qu'un même commercial vous vendra dans la même réunion, souvent comme s'ils faisaient la même chose. Ils ne regardent pourtant pas votre application au même moment, ni au même endroit, ni avec les mêmes angles morts. Et depuis que chaque éditeur colle IA sur sa plaquette, séparer le vrai gain du repeint marketing est devenu un exercice à part entière.

Aucun des trois n'est meilleur dans l'absolu. Le SAST lit le code à l'arrêt, le DAST tape sur l'application qui tourne, l'IAST écoute de l'intérieur : trois points de vue, trois listes de faux positifs différentes. Reste à savoir lequel placer où, ce que l'analyse par IA améliore vraiment au tri du bruit, et quels outils regarder au moment de signer un bon de commande.

Les trois familles, en une phrase chacune

La meilleure image reste celle de l'inspection d'une voiture :

• SAST (analyse statique) lit le plan et démonte le moteur à l'arrêt. Il analyse le code source sans exécuter l'application, boîte blanche.
• DAST (analyse dynamique) prend le volant et essaie de casser la voiture en roulant. Il attaque l'application en fonctionnement depuis l'extérieur, boîte noire.
• IAST (analyse interactive) colle des capteurs partout dans le moteur pendant que vous roulez. Il instrumente le runtime et observe le code de l'intérieur pendant les tests, boîte grise.

SAST : voit tout, y compris ce qui n'existe pas

Le SAST est le champion du shift-left : il tourne dès le commit, avant même que l'application ne démarre. Il couvre 100 % des chemins de code, y compris les branches rarement exécutées, et s'intègre nativement dans la CI/CD. Il attrape donc les failles tôt, là où elles coûtent le moins cher à corriger.

Le revers : il analyse le code hors contexte d'exécution. Il ne sait pas si un chemin vulnérable est réellement atteignable, ni si un framework valide l'entrée dans une couche qu'il ne modélise pas. Résultat : une montagne de faux positifs, qui se paie deux fois, en licence et en heures de tri.

Sept configurations SAST mesurées : CodeQL en tête, et 38 % de faux positifs quand même

"Beaucoup de faux positifs", ça se chiffre. Le 7 octobre 2026, j'ai passé sept configurations SAST sur l'OWASP Benchmark for Java v1.2 : 2 740 servlets de test, dont 1 415 réellement vulnérables, avec la vérité terrain officielle et une même règle de comptage pour tous. Le score retenu est l'indice de Youden, taux de vrais positifs moins taux de faux positifs, en moyenne sur les onze catégories du corpus : zéro, c'est le hasard, cent, la perfection.

Trois lectures. D'abord, même le premier ne fait pas de miracle : CodeQL trouve les 1 415 failles réelles mais signale en moyenne 38 % des cas sains, et 207 requêtes SQL sûres sur 232. Ensuite, entre Semgrep et SpotBugs, l'écart tient dans un ou deux points et change avec le pack ou le seuil choisi : ce sont des différences de réglage, pas de qualité. Le même Semgrep perd 18,2 points avec le pack p/owasp-top-ten, qui ne contient ni la règle d'aléa faible ni celle du cookie sans attribut Secure. Enfin, SonarQube Community n'a pas l'analyse de teinte de Sonar, réservée à SonarQube Server à partir de l'édition Developer et à SonarQube Cloud : aucun cas trouvé dans six catégories sur onze, dont le XSS et l'injection de commande.

La pré-passe de SecAI, notre produit, est dans le graphique et il faut la lire avec deux précautions. Elle a été mesurée sans le vérificateur LLM qui trie ses candidats en production, et son moteur a été réglé sur ce même Benchmark : c'est un score d'entraînement, qui la flatte. Il reste sous CodeQL, Semgrep et SpotBugs. Sa position face à SonarQube dépend de la correspondance entre règles et CWE retenue, je ne les classe donc pas l'un par rapport à l'autre. Le corpus, enfin, est synthétique, en Java, et public depuis 2015 : tous les outils le connaissent. La méthode complète et les limites sont dans l'article sur la revue de code sécurité, qui détaille aussi ce que le banc ne mesure pas du tout : le contrôle d'accès.

Outils SAST : lesquels tester

Le marché du SAST tient sur une poignée d'outils qu'on retrouve dans presque tous les appels d'offres. SonarQube reste la porte d'entrée, avec une édition Community gratuite et des paliers payants ; sa gratuité et ses limites réelles sont détaillées dans le guide SonarQube prix, limites et alternatives. Snyk vient surtout du monde des dépendances (SCA) et facture à un compteur qui surprend souvent : on décortique sa grille dans le guide Snyk prix et alternatives. Checkmarx vise l'entreprise, sur devis, avec un coût de réglage que personne ne budgète : c'est l'objet du guide Checkmarx prix et alternatives. La vraie question à leur poser tient en une ligne : combien de faux positifs de moins, pas combien de règles de plus.

DAST : ne voit que ce qui est vraiment exposé

Le DAST attaque l'application qui tourne, comme le ferait un attaquant. Il excelle sur les vulnérabilités de runtime invisibles au statique : erreurs de configuration, problèmes côté serveur, comportements spécifiques à l'environnement, un jeton CSRF présent dans le formulaire mais jamais vérifié côté serveur. Et comme il teste le comportement réel, ses findings sont nettement moins bruyants que ceux du SAST : s'il déclenche une injection SQL, c'est qu'elle marche.

Ses angles morts : il ne voit pas le code non atteint (faux négatifs), galère sur les workflows multi-étapes qui exigent un état d'authentification précis, et exige une application déployée et fonctionnelle, donc impossible à lancer en tout début de cycle. Le fonctionnement détaillé, ses angles morts et où le brancher sont repris dans l'article dédié le DAST (Dynamic Application Security Testing). Pour la frontière entre scan et test réel, voyez aussi pentest vs scan de vulnérabilité.

IAST : définition, et pourquoi il ment le moins

L'IAST instrumente l'application avec un agent qui observe le code pendant les tests fonctionnels. Quand une requête arrive, l'agent suit l'entrée non fiable méthode par méthode, à travers le middleware du framework, et si elle atteint une fonction dangereuse sans assainissement, il remonte la faille avec fichier, ligne et stack trace exacts. C'est pour ça qu'il a le taux de faux positifs le plus bas des trois : il confirme l'atteignabilité en conditions réelles.

Le prix à payer : il faut faire tourner l'appli (donc il rate la pure revue de code), l'agent ajoute un peu d'overhead, et son efficacité dépend directement de la couverture de vos tests automatisés. Pas de tests qui passent dans les bons recoins, pas de détection.

Le comparatif en un coup d'œil

Les trois familles se départagent sur cinq axes qui décident du choix : l'approche (accès au code ou non), le moment du cycle où l'outil intervient, le besoin d'une application en marche, le niveau de faux positifs, et l'angle mort qu'on accepte en échange. Le tableau ci-dessous les met côte à côte.

Ce qui ressort du tableau : le SAST arrive le plus tôt et couvre le plus large, au prix du bruit ; le DAST arrive le plus tard mais ne remonte que de l'exploitable ; l'IAST est le plus précis, à condition d'avoir des tests qui exercent les bons chemins. Aucune colonne n'est sans angle mort, ce qui explique pourquoi on les empile plutôt qu'on ne les oppose.

Ce que l'IA change : SAST IA et DAST IA

Pendant des années, le SAST a posé une seule question : "ce bout de code correspond-il à un motif connu comme dangereux ?" D'où le bruit : le motif matche, mais le contexte rend la faille inexploitable. Le SAST IA change la question en : " ce changement rend-il l'application moins sûre, compte tenu du reste du code ?".

Cette bascule, documentée par plusieurs analyses de marché récentes, débloque trois choses concrètes :

1. Analyse contextuelle multi-fichiers

L'analyse porte sur plusieurs fichiers à la fois, ce qui fait ressortir les failles de logique, les IDOR et les trous d'autorisation dont la chaîne traverse plusieurs fichiers, là où le pattern-matching mono-fichier est complètement aveugle. Ces trous d'autorisation occupent d'ailleurs la première place de l'OWASP Top 10 (Broken Access Control).

2. Atteignabilité (reachability) et exploitabilité

L'IA trace le flux d'une entrée utilisateur jusqu'au sink sensible et, en corrélant avec le graphe de flux de contrôle, écarte le code mort. Plusieurs éditeurs revendiquent ainsi une réduction massive du volume d'alertes. Au lieu d'afficher toutes les failles "à égalité", les outils récents priorisent d'abord les vulnérabilités exploitables, à la manière d'un statut VEX. Plusieurs éditeurs, Snyk en tête, mettent en avant des agents autonomes qui trient par atteignabilité. Un tel agent ne s'improvise pas : le vrai coût et la méthode pour l'entraîner sur des traces d'exploitation sont détaillés dans construire un dataset pour un agent IA offensif.

Côté DAST IA, le gain est ailleurs : l'IA auto-découvre la surface d'attaque (endpoints, paramètres, workflows multi-étapes), auto-configure les tests selon la techno détectée, et valide par rejeu avant de remonter une alerte. Ce que donnent les outils actuels face à une cible réelle, on l'a mesuré dans notre banc de pentest automatisé. Et quand c'est l'IA qui écrit le code plutôt que de l'analyser, elle laisse des trous très prévisibles : on en démonte deux dans vibe coding et sécurité. Lorsque le code analysé appelle lui-même un modèle, une classe de faille s'ajoute que ces trois familles d'outils n'ont pas été conçues pour voir : la prompt injection, qui se joue dans les capacités données à l'agent bien plus que dans le code lui-même. Ces assistants et agents s'installent d'ailleurs souvent sans passer par la DSI, et deviennent eux-mêmes une surface à recenser : c'est le sujet du shadow AI. Pour le détail technique côté outillage, le panorama de DryRun Security sur le SAST IA est une bonne lecture.

DevSecOps : qui met-on, où, et quand ?

On ne choisit pas un outil : on les empile dans le pipeline DevSecOps, et le travail commence même avant la première ligne de code : le threat modeling place les défenses là où les attaques vont porter, ce qu'aucun scanner ne déduit tout seul. Ensuite, l'approche par phase recommandée :

1. Au commit / PR : SAST (idéalement IA, contextuel) pour le feedback immédiat au dev, façon shift-left. On bloque tôt, on coûte peu.
2. En staging : DAST pour confronter l'appli déployée à des attaques réelles et valider l'exploitabilité.
3. Sur les applis critiques : IAST pendant les tests fonctionnels, pour la précision chirurgicale et la localisation exacte.
4. En continu : SCA sur chaque build pour surveiller les dépendances et les nouvelles CVE.

Le format SARIF est le ciment de tout ça : il normalise les findings de tous ces outils dans un langage commun que votre CI (GitHub, GitLab, Jenkins) sait afficher dans les PR. Sans normalisation, vous avez quatre tableaux de bord et zéro vue d'ensemble. Le câblage concret, où placer chaque outil, comment brancher SARIF et écrire un security gate qui bloque sans noyer les devs, est détaillé dans intégrer SAST et DAST dans sa CI/CD.

SAST IA en produit, pentest humain en service

Chez own2pwn (THE HIVE, certification OSWE, hébergement dans l'Union européenne), le parti pris est le même que celui de cet article : ni tout-automatique, ni tout-humain, le bon outil au bon endroit. Deux portes d'entrée selon le besoin :

• SecAI, la plateforme AppSec en self-service : un SAST piloté par IA qui suit le flux de données (taint), un SCA filtré par atteignabilité, l'analyse IaC et la détection de secrets, corrélés en une seule passe et priorisés par exploitabilité. Sorties SARIF pour GitHub Code Scanning, une Action GitHub avec seuil de sévérité et un CLI pour GitLab et Jenkins. La vérification humaine des findings reste un pentest à part, jamais une promesse de l'outil.
• Pentest web whitebox, quand vous voulez un humain qui fait la revue de code sécurité et combine SAST et DAST avec un contexte métier qu'aucune machine ne déduit (ce que ça coûte ? on détaille le prix d'un test d'intrusion). Pour du test externe sans accès au code, voyez le pentest blackbox.

À retenir

• SAST voit tout le code tôt (mais beaucoup de bruit), DAST voit ce qui est vraiment exposé (mais rate le code non atteint), IAST combine les deux avec une précision maximale (mais dépend de vos tests).
• Ce ne sont pas des concurrents : on les empile dans le pipeline DevSecOps, du commit à la prod, avec le SCA pour les dépendances.
• Mesuré sur 2 740 cas, le meilleur SAST du banc, CodeQL, obtient 62,0 de Youden et signale encore 38 % des cas sains ; SonarQube Community, sans analyse de teinte, ne trouve rien dans six catégories sur onze.
• L'IA attaque le vrai problème, les faux positifs, via l'analyse contextuelle de l'atteignabilité et la priorisation par exploitabilité.
• Mais "IA" est parfois un sticker sur un vieux scanner. Exigez des preuves sur la réduction des faux positifs, pas un chatbot.
• La seule métrique qui compte : les failles réelles corrigées, pas les alertes générées.

Envie de voir à quoi ressemble un SAST qui ne vous noie pas ? Jetez un œil à SecAI, ou parlez-en directement avec un humain.

Questions fréquentes