SAST vs DAST vs IAST vs RASP : différences, avantages et comment choisir

Mardi, 14h. Votre équipe dev vient de livrer une nouvelle version de l’application client. Le code a été relu, les tests fonctionnels sont au vert, tout le monde est satisfait. Reste une question que personne n’a vraiment vérifiée : un attaquant pourrait-il exploiter cette version en production, et avec quel outil le saurait-on avant lui ?

C’est précisément le moment où quelqu’un, dans la salle, pose la question qui revient systématiquement dans les comités sécurité : faut-il choisir entre static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST) et runtime application self protection (RASP), ou ces quatre méthodes sont-elles toutes nécessaires en même temps ?

La réponse courte : cela dépend de ce que vous protégez et à quel moment du cycle de vie de l’application. La réponse longue, qui évite de se tromper sur un investissement souvent coûteux, tient dans la suite de cet article.

À retenir

• Le static application security testing (SAST) analyse le code source, le bytecode ou les fichiers de configuration sans exécuter l’application. Il intervient pendant le développement.

• Le dynamic application security testing (DAST) teste une application en cours d’exécution sans accès au code source. Il s’utilise en test ou en production.

• L’interactive application security testing (IAST) combine analyse statique et dynamique grâce à des agents installés dans l’application, avec une précision élevée mais un déploiement plus complexe.

• Le runtime application self protection (RASP) ne se contente pas de détecter : il bloque activement les attaques pendant que l’application tourne en production.

• Aucun de ces outils ne remplace les autres : ils couvrent des phases différentes du cycle de développement.

• Pour la majorité des organisations qui veulent identifier des vulnérabilités sur un périmètre déjà en production sans dépendre des équipes de développement, le DAST reste le point d’entrée le plus rapide à déployer.

• Ensemble, SAST, DAST, IAST et RASP forment le socle des méthodes de test et de protection applicative disponibles aujourd’hui.

SAST, DAST, IAST et RASP ne sont donc pas quatre variantes d’un même outil, mais quatre réponses à quatre moments différents du risque applicatif : avant l’exécution pour le SAST, pendant un test pour le DAST, pendant le développement avec instrumentation pour l’IAST, et pendant l’exploitation réelle en production pour le RASP.

Le débat SAST vs DAST revient le plus souvent dans les premières discussions de mise en place d’une démarche AppSec, précisément parce que ce sont les deux méthodes les plus simples à opposer : l’une regarde le code, l’autre regarde le comportement. RASP s’ajoute en complément des deux, une fois qu’une application critique est déjà en production et qu’on veut une protection active plutôt qu’un simple constat.

Le static application security testing, ou SAST, analyse le code source, le bytecode ou les fichiers de configuration d’une application sans jamais l’exécuter. C’est une méthode dite en boîte blanche, à l’opposé du black box testing : l’outil voit l’intérieur du moteur, pas seulement ce qui sort du capot.

C’est comparable au travail du correcteur qui relit un manuscrit avant publication. Il ne sait pas comment les lecteurs vont réagir au livre une fois sur les étals, mais il repère les incohérences, les fautes et les passages mal construits directement dans le texte, avant que quiconque ne l’ait lu. Le SAST fonctionne de la même manière avec du code : il corrige ce qui posera problème plus tard, avant même que l’application ne soit réellement exécutée.

Concrètement, les outils SAST parcourent chaque ligne de code à la recherche de patterns dangereux : une requête construite par concaténation de chaînes, une fonction de hash obsolète, une variable utilisateur jamais validée avant d’être affichée. Cette analyse se fait avant même que l’application ne soit déployée, ce qui en fait l’outil naturel des équipes de développement, intégré directement dans le pipeline CI/CD pour des tests automatisés à chaque commit.

Ce qui fait sa force : détecter un problème au moment où il est écrit coûte beaucoup moins cher que le corriger une fois en production. Un développeur qui reçoit une alerte SAST dans son IDE corrige en quelques minutes ce qui, découvert plus tard par un pentest, demanderait un correctif d’urgence, une revalidation et potentiellement une fenêtre de maintenance.

Ce qui le limite : le SAST analyse du code, pas un comportement réel. Il ne voit ni les erreurs de configuration serveur, ni les failles qui n’émergent qu’à l’exécution, ni ce qui touche à l’infrastructure plutôt qu’au code applicatif lui-même. Il génère aussi, historiquement, un volume important de faux positifs : un pattern qui ressemble à une faille dans le code n’en est pas toujours une une fois le contexte d’exécution pris en compte.

Le dynamic application security testing, ou DAST, fait l’inverse : il teste une application en cours d’exécution, sans avoir accès à son code source. C’est une méthode de black box testing, parfois en boîte grise quand le test dispose d’un compte utilisateur standard pour explorer les fonctionnalités authentifiées.

Reprenons l’analogie du correcteur, et ajoutons cette fois un client mystère envoyé dans un magasin. Il n’a jamais vu les fiches de poste des vendeurs ni le manuel interne de l’enseigne. Il entre, teste le service, essaie de payer sans carte, demande un remboursement abusif et observe ce qui se passe vraiment. Le DAST fonctionne de la même manière avec une application : il ne regarde jamais le manuel, il teste le comportement réel, en situation, exactement comme le ferait un attaquant qui n’a jamais eu accès à vos sources.

Concrètement, un test DAST envoie de vraies requêtes à l’application web, exactement comme le ferait un navigateur ou un attaquant : tentatives d’injection SQL, payloads XSS, manipulation de paramètres, vérification des en-têtes de sécurité, contrôle de la configuration TLS. L’outil surveille le comportement de l’application pour repérer ce qui clignote anormalement : un message d’erreur trop verbeux, une authentification qu’on peut contourner, un fichier qu’on ne devrait pas pouvoir importer. C’est l’une des méthodes les plus utilisées pour identifier des vulnérabilités sans toucher à une seule ligne de code.

Ce qui fait sa force : le DAST ne dépend d’aucun accès au code ni d’aucune coopération de l’équipe de développement. Il s’applique aussi bien à une application développée en interne qu’à une application web achetée sur étagère ou maintenue par un prestataire dont vous n’avez jamais vu une ligne de code. C’est aussi la méthode la plus proche de la réalité d’une attaque : elle teste ce qui est réellement exploitable depuis l’extérieur, pas ce qui est théoriquement présent dans le code.

Ce qui le limite : le DAST ne voit que ce que l’application expose à l’exécution. Une faille profondément enfouie dans une fonction jamais déclenchée par les scénarios de test ne sera pas détectée. Le déploiement peut aussi demander un peu plus de préparation qu’un simple scan, puisqu’il faut une version fonctionnelle de l’application à tester, sans la faire planter au passage.

L’interactive application security testing, ou IAST, cherche à prendre le meilleur des deux mondes en installant des agents directement dans l’application, qui observent son comportement à l’exécution tout en ayant accès au code et aux data flows en interne.

C’est l’équivalent d’un coureur professionnel équipé de capteurs biométriques pendant une vraie course, plutôt qu’analysé sur un tapis de course en laboratoire ou simplement chronométré depuis les gradins. Les capteurs voient à la fois ce qui se passe à l’intérieur du code et comment l’application réagit en situation réelle, avec une précision que ni l’analyse statique ni le simple test dynamique ne permettent.

Concrètement, ces agents instrumentent l’application : ils suivent les requêtes, les réponses et les chemins d’exécution du code, puis corrèlent une vulnérabilité détectée avec la ligne de code exacte qui en est responsable. Cette double visibilité réduit fortement les faux positifs par rapport au SAST seul, puisque l’IAST confirme qu’un pattern de code suspect est réellement atteint et exploitable à l’exécution.

Ce qui fait sa force : une précision de détection élevée et une localisation immédiate du problème dans le code, ce qui accélère la correction côté développeurs.

Ce qui le limite, et c’est significatif : l’IAST nécessite d’instrumenter l’application avec des agents, ce qui suppose un accès à l’environnement de développement ou de test, une maintenance technique continue et souvent une coordination plus étroite entre équipes SecOps et DevOps que pour les autres méthodes. Pour des applications tierces, achetées ou maintenues hors de votre périmètre de contrôle direct, l’IAST n’est généralement pas une option.

Le runtime application self protection, ou RASP, change de registre par rapport aux trois précédents : il ne s’agit plus seulement de tester ou de détecter, mais de bloquer activement une attaque pendant que l’application tourne en production.

Le correcteur a relu le manuscrit, le client mystère a testé le magasin, le coureur a été analysé sous tous les angles. Le RASP, c’est l’agent de sécurité posté à l’entrée du magasin le jour de l’ouverture officielle, celui qui n’attend pas un rapport d’audit pour agir : s’il voit quelqu’un forcer la caisse en direct, il intervient immédiatement, sur le moment, sans attendre qu’un manager analyse la vidéo le lendemain.

Concrètement, le RASP s’intègre directement dans le runtime de l’application et surveille en continu son comportement réel : une tentative d’injection SQL détectée n’est pas seulement loggée, elle est interceptée et neutralisée avant d’atteindre la base de données. C’est la seule des quatre approches qui agit comme un mécanisme de défense actif plutôt que comme un outil de détection ou de test.

Ce qui fait sa force : une protection en temps réel qui ne dépend pas d’un cycle de scan, particulièrement utile sur des vulnérabilités découvertes après mise en production, le temps qu’un correctif définitif soit développé et déployé.

Ce qui le limite : comme l’IAST, le RASP demande une intégration directe dans l’application et peut introduire un coût de performance ou de complexité opérationnelle, ce qui le réserve généralement à des applications critiques plutôt qu’à un déploiement systématique sur tout un parc applicatif.

Vous développez votre propre application, en interne, avec une équipe dev structurée. Le SAST trouve naturellement sa place dans le pipeline CI/CD, pour intercepter les défauts avant qu’ils n’atteignent la production. C’est un investissement qui paie sur la durée, mais qui suppose une organisation capable de l’intégrer sans ralentir les livraisons.

Vous devez sécuriser un périmètre déjà en production, sans dépendre du code ni de l’équipe de développement. C’est le scénario le plus fréquent pour un RSSI qui hérite d’un parc applicatif hétérogène, avec des applications développées par des prestataires successifs, achetées sur étagère ou dont la documentation a disparu avec les développeurs d’origine. Le DAST est ici la méthode la plus rapide à déployer, puisqu’elle ne demande ni accès au code ni coopération préalable d’une équipe externe.

Vous avez une équipe DevSecOps mature, un volume de développement important et les ressources pour maintenir une instrumentation. L’IAST devient pertinent en complément du SAST, en particulier sur les applications critiques où la précision de détection et la vitesse de correction justifient l’investissement.

Dans la pratique, ces trois approches sont complémentaires plutôt que substituables. Aucune ne couvre seule l’ensemble du risque applicatif : le SAST rate ce qui n’existe qu’à l’exécution, le DAST rate ce qui n’est jamais déclenché par les scénarios de test, l’IAST rate tout ce qui n’est pas instrumenté.

Pour une organisation qui n’a pas encore structuré sa démarche AppSec, le DAST a un avantage opérationnel décisif : zéro dépendance. Pas besoin d’accès au code, pas besoin que les équipes de développement libèrent du temps pour intégrer un outil dans leur pipeline, pas besoin d’attendre la prochaine release pour commencer à voir des résultats.

C’est aussi la méthode la plus alignée avec une logique de surveillance continue de la surface d’attaque externe plutôt que d’audit ponctuel : un DAST déployé en continu détecte une nouvelle faille dès qu’elle devient exploitable depuis l’extérieur, pas une fois par an lors d’un audit planifié. Cette logique recoupe directement ce qu’on développe dans notre article sur les types de pentest : le DAST et le pentest externe en boîte noire répondent à la même intuition, celle de tester ce qu’un attaquant verrait réellement, pas ce que la documentation prétend exposer.

Patrowl propose une approche DAST en boîte noire, sans agent ni accès au code, avec un déploiement annoncé en moins de 30 minutes et une priorisation des failles selon leur exploitabilité réelle plutôt que leur seul score CVSS. Chaque détection critique est validée par l’équipe CERT avant remontée, pour éviter le bruit qu’un DAST mal calibré peut générer.

Patrowl, page produit DAST · OWASP · Fortinet, Cyberglossary DAST · LeMagIT, comparatif SAST/DAST/IAST.