SAST vs DAST vs IAST : comparatif, 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. Pour des outils non réglés, Snyk et d'autres évoquent des taux de faux positifs très élevés sur le SAST classique, là où les approches contextuelles tombent bien plus bas. Ce bruit se paie deux fois, en licence et en heures de tri.

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. C'est un excellent outil… si votre maturité QA suit.

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

On arrive au cœur du sujet. 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. C'est le type même de faille qu'un humain repère en lisant le code… et qu'un regex ne verra jamais. 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. Mieux : 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. Le DAST cesse d'être un crawler bête pour devenir un testeur qui s'adapte. C'est la logique qu'on détaille dans pentest automatisé piloté par l'IA. 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 tout l'enjeu 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 ?

La bonne nouvelle, c'est qu'on ne choisit pas un outil. On les empile intelligemment dans le pipeline, 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.
• 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