Quelle est la différence entre SAST, DAST et IAST ?

Ces trois acronymes décrivent des façons complémentaires de trouver des vulnérabilités dans une application, et un bon candidat explique les compromis plutôt que de réciter des définitions.

Statique (SAST)

Le Static Application Security Testing analyse le code source, le bytecode ou les binaires sans les exécuter. Il trace le flux de données depuis les entrées non fiables (sources) jusqu'aux opérations dangereuses (sinks) pour signaler des choses comme l'injection SQL ou le XSS. Parce qu'il voit tout le code, il s'exécute tôt — souvent à chaque commit ou pull request — et pointe la ligne exacte. Le coût, ce sont les faux positifs : il ne peut pas dire si un chemin signalé est réellement atteignable à l'exécution, donc la charge de tri est réelle.

Dynamique (DAST)

Le Dynamic Application Security Testing attaque l'application en cours d'exécution depuis l'extérieur, comme un attaquant non authentifié, sans vue sur le code source. Il trouve des problèmes réellement exploitables — authentification cassée, mauvaises configurations, injections qui se déclenchent vraiment — et produit moins de faux positifs. Les inconvénients : il s'exécute tard (il faut un environnement déployé), la couverture dépend de la qualité du parcours de l'application, et il ne peut pas pointer le code fautif.

Interactif (IAST)

L'Interactive Application Security Testing place un agent à l'intérieur de l'application en cours d'exécution et observe l'exécution du code pendant que l'application est sollicitée (souvent par des tests fonctionnels ou DAST existants). En corrélant le flux de données runtime au code réel, il fournit des résultats précis avec un contexte au niveau de la ligne — moins de faux positifs que le SAST, plus de visibilité sur le code que le DAST. Le hic : il nécessite une instrumentation runtime, le support du langage/runtime, et une bonne couverture de tests pour solliciter les chemins.

Ce qu'aucun ne détecte bien

Les failles de logique métier, les autorisations cassées et les faiblesses de conception échappent aux trois — celles-ci nécessitent la modélisation des menaces et une revue manuelle.

Ce que recherchent les recruteurs

Ils veulent que vous positionniez ces outils comme des couches d'un pipeline, que vous nommiez une force et une faiblesse concrètes de chacun, et que vous reconnaissiez que l'analyse automatisée ne remplace jamais la revue humaine.