Intégrer SAST, DAST et IAST dans une CI/CD

Les tests de sécurité automatisés ne remplacent ni la revue de code ni la modélisation de menace : ils réduisent le temps entre l’introduction d’un défaut et sa détection. Le compromis central est brutal : plus un test s’approche des conditions réelles d’exploitation, plus il coûte du temps, de l’infrastructure et une couverture de scénarios maintenue.

→ Lire l’explication complète de la marmotte

SAST, DAST et IAST : choisir selon la preuve recherchée

Le SAST (Static Application Security Testing) analyse le code source, les fichiers de configuration et parfois le code compilé sans démarrer l’application. Il suit des motifs syntaxiques, des flux de données et des appels dangereux : concaténation de requête SQL (Structured Query Language), désérialisation non fiable, fonctions cryptographiques obsolètes, validation d’entrée absente ou contournable.

Le DAST (Dynamic Application Security Testing) interagit avec une application déployée via son interface réseau. Il envoie des requêtes malformées, modifie des paramètres, injecte des charges de test et observe les réponses. Sa valeur est une preuve plus proche de l’exploitation : une injection détectée sur un point d’entrée accessible avec une réponse observable mérite une attention immédiate.

L’IAST (Interactive Application Security Testing) instrumente le processus applicatif pendant les tests fonctionnels. L’agent observe les données qui entrent, les fonctions sensibles qu’elles atteignent et les protections appliquées entre les deux. Il peut signaler qu’une valeur issue d’une requête HTTP (Hypertext Transfer Protocol) arrive dans un interpréteur SQL sans paramétrage, même si la réponse externe ne divulgue rien.

La position à tenir est la suivante : démarrer par un SAST calibré, ajouter un DAST sur un environnement jetable représentatif, puis adopter l’IAST seulement si les tests fonctionnels couvrent les parcours critiques et si l’instrumentation est supportée par le runtime. Acheter un IAST sans couverture de tests revient à installer un détecteur de fumée dans une pièce où personne n’entre.

Ces outils ne se remplacent pas :

Approche	Détecte réellement	Ne prouve pas
SAST	Des chemins de code potentiellement dangereux, y compris non exécutés	Qu’un chemin est accessible, exploitable ou atteignable avec une identité réelle
DAST	Des défauts observables sur les routes, méthodes et identités exercées	L’absence de défaut hors des scénarios parcourus
IAST	Des flux dangereux atteints durant l’exécution instrumentée	La couverture des parcours non testés, ni la sécurité de l’infrastructure externe

La revue de code conserve son rôle : évaluer une décision de conception, une règle métier ou une frontière de confiance. Aucun scanner ne déduit de façon fiable qu’un utilisateur peut modifier la ressource d’un autre parce qu’un identifiant est passé dans une URL. Les outils voient des données et des appels, pas l’intention métier. L’intention reste ce truc péniblement humain que les slides promettent d’automatiser depuis fort longtemps.

SAST : couverture maximale, signal à discipliner

Un SAST doit cibler les langages réellement présents, les frameworks actifs et les bibliothèques internes. Activer un catalogue complet de règles sur un monorepo dès le premier jour produit une dette de triage, pas une amélioration de sécurité. Les faux positifs sont normaux : l’analyse ne connaît ni toutes les validations métier ni les garanties offertes par les wrappers internes.

Le calibrage doit suivre trois étapes. D’abord, bloquer uniquement les règles à forte confiance et fort impact : exécution de commandes avec entrée contrôlable, injection SQL évidente, désérialisation arbitraire, désactivation explicite de vérification TLS (Transport Layer Security). Ensuite, établir une base de référence pour les constats existants et ne faire échouer le pipeline que sur les nouveaux constats. Enfin, promouvoir progressivement les règles dont le taux de confirmation est acceptable.

Une suppression de règle doit être locale, motivée et révisable. Un commentaire qui désactive un contrôle sur une ligne précise, avec la validation exécutée juste avant, est acceptable. Exclure un répertoire entier parce qu’il fait du bruit transforme l’outil en décoration de pipeline, catégorie déjà très bien représentée.

Le SAST échoue particulièrement sur les constructions dynamiques : réflexion, génération de requêtes, métaprogrammation, appels indirects et bibliothèques dont les contrats ne sont pas modélisés. Il détecte aussi mal les défauts de logique d’autorisation, les conditions de course et les erreurs de configuration injectées après compilation. Un code propre peut appeler une base de données exposée sur Internet avec un compte administrateur. Le scanner ne répare pas une architecture absurde par télépathie.

DAST : preuve d’exposition, couverture conditionnelle

Le DAST doit s’exécuter contre un environnement isolé, réinitialisable et suffisamment fidèle : mêmes mécanismes d’authentification, mêmes passerelles, mêmes règles de routage et mêmes en-têtes de sécurité. Scanner une maquette sans authentification teste surtout la page de connexion. C’est parfois instructif, mais rarement glorieux.

La couverture dépend des scénarios fournis. Il faut créer des comptes de test à privilèges distincts, parcourir les opérations sensibles et injecter des jeux de données réinitialisables. Tester seulement une identité administratrice masque les défauts d’autorisation horizontale : il faut au moins deux identités de même rôle, propriétaires de ressources différentes, et une identité moins privilégiée.

Le DAST détecte efficacement les en-têtes manquants, certaines injections, les redirections ouvertes, les erreurs de configuration HTTP et des contrôles d’accès défaillants quand les scénarios les atteignent. Il détecte mal les routes cachées, les interfaces non documentées, les flux asynchrones, les vulnérabilités nécessitant plusieurs étapes et les défauts sans effet observable. Une réponse 200 OK ne constitue pas une attestation de sécurité, juste une réponse 200 OK.

Un scanner actif peut modifier des données, déclencher des tâches ou saturer un service. Les cibles doivent porter des marqueurs d’environnement vérifiés avant le lancement, les comptes doivent être non privilégiés hors périmètre de test et les sorties réseau doivent être filtrées. Sans cela, le DAST devient un test de résilience organisationnelle involontaire.

IAST : contexte runtime et dépendance aux tests

L’IAST réduit les faux positifs du SAST en observant les flux réellement exécutés. Pour une injection SQL, l’agent peut identifier la source de la donnée, le point d’appel de la requête et l’absence de requête paramétrée. Cette précision facilite la correction : fichier, ligne, pile d’appel et requête concernée sont souvent disponibles.

Le prix est double. L’agent modifie le processus, donc les performances, la consommation mémoire et parfois le comportement de bibliothèques instrumentées. Il faut mesurer cette surcharge sur l’environnement de test, verrouiller la version de l’agent et vérifier sa compatibilité après chaque montée de version du runtime. Un agent qui disparaît après une mise à jour de Java, Node.js ou .NET n’émet aucune alerte. Le silence d’un contrôle absent est l’un des sons préférés des incidents.

L’IAST ne couvre que les flux joués par les tests automatisés. Il dépend donc d’une suite de tests fonctionnels stable, avec des données réalistes et des identités variées. Il n’est pas un substitut au DAST : l’agent voit l’application, pas nécessairement le proxy inverse, la politique de pare-feu, le cache, ni les erreurs de terminaison TLS.

Exemple de pipeline : SAST rapide et DAST isolé

Le contrôle rapide doit échouer sur les nouveaux défauts critiques. Le DAST, plus lent et potentiellement intrusif, doit être planifié après le déploiement d’un environnement éphémère ou dans une exécution nocturne. L’exemple suivant lance Semgrep pour l’analyse statique et ZAP (Zed Attack Proxy) pour une analyse dynamique de base.

# SAST : à lancer sur la branche modifiée ou avant validation locale.
# Le répertoire .semgrepignore doit exclure les artefacts générés.
semgrep scan \
  --config p/security-audit \
  --error \
  src/

# DAST : cible exclusivement un environnement de test démarré localement.
# ZAP effectue une analyse de base, moins intrusive qu'un scan actif complet.
docker run --rm --network host \
  ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py \
  -t http://127.0.0.1:8080 \
  -m 5 \
  -I

L’option -I empêche l’échec du processus sur les alertes, ce qui convient à une phase d’observation initiale. Elle ne doit pas survivre indéfiniment : après qualification des alertes, le pipeline doit échouer sur un seuil explicite, par exemple une injection confirmée ou une route administrative accessible sans identité. Une exception doit être datée, liée à un risque accepté et supprimée lorsque le correctif arrive.

Les dépendances logicielles, les secrets exposés dans le dépôt et les images conteneur demandent des contrôles distincts. Les confondre avec SAST, DAST ou IAST crée des tableaux de bord luxuriants et des angles morts très réels. La séparation des responsabilités est détaillée dans les rubriques architecture cybersécurité et failles.

Surface d’attaque et conditions d’exploitation

Les outils de test deviennent eux-mêmes une surface d’attaque. Un scanner DAST détient souvent des identifiants de test, des jetons de session et parfois des clés d’interface de programmation applicative. Ces secrets doivent être injectés à l’exécution par le gestionnaire de secrets du pipeline, limités à l’environnement ciblé et expirables. Ne jamais les placer dans un fichier de configuration de scanner versionné, même chiffré : le chiffrement versionné finit fréquemment par être une chasse au coffre dont tout le monde possède une copie.

Les rapports peuvent contenir des URL internes, des paramètres, des extraits de réponse et des identifiants de session. Ils doivent être chiffrés au repos, accessibles au seul groupe de correction concerné et soumis à une durée de conservation définie. La sauvegarde des rapports doit préserver les preuves nécessaires, pas chaque réponse HTTP brute pour l’éternité.

La supervision doit contrôler trois éléments : le taux d’échec technique des scans, la baisse soudaine de couverture et l’âge des signatures ou règles. Un DAST qui ne découvre plus aucune route parce que l’authentification a changé produit un rapport vert et une couverture nulle. Ce cas doit alerter. De même, une indisponibilité du service de règles SAST ne doit jamais être interprétée comme zéro vulnérabilité.

La reprise impose de pouvoir recréer l’environnement de scan, les comptes de test, les politiques de réseau et les règles de filtrage à partir de code versionné. Les secrets, eux, viennent d’une source de vérité distincte avec rotation documentée. Restaurer une sauvegarde d’environnement contenant des jetons expirés est une restauration décorative : elle a l’apparence de la reprise, pas ses propriétés.

🐝 Ce qui arrive si on s’en passe

Sans ces contrôles dans le pipeline, un défaut déjà corrigé peut revenir lors d’une refonte ou d’une fusion sans qu’aucune étape n’échoue, car rien ne rejoue la règle ou le scénario qui l’avait révélé. Chaque version publiée reste une inconnue que seul un audit ponctuel ou une exploitation externe viendra qualifier, et cet audit ne décrit que l’état du code à sa date. En cas d’incident, l’absence d’historique de scans empêche de dater l’apparition de la faille : impossible de savoir quel commit l’a introduite, depuis combien de versions elle est exposée, ni quelle période de journaux examiner pour délimiter l’exploitation possible. La correction se fait alors dans l’urgence, sur du code déjà en production, sans contrôle automatique vérifiant qu’elle n’ouvre pas un autre chemin.

🦫 Explication de la marmotte 🍫

Les tests de sécurité automatisés cherchent des défauts pendant la fabrication d’une application. Une première méthode lit le code sans lancer le programme. Elle repère des écritures dangereuses, par exemple une requête vers une base de données construite avec du texte reçu d’un utilisateur. Elle peut aussi signaler des problèmes qui ne sont pas réellement dangereux, car elle ne connaît pas toutes les règles du programme.

Une deuxième méthode lance l’application de test et lui envoie des demandes inhabituelles. Elle regarde si l’application accepte des données interdites, révèle des informations ou laisse accéder à une action protégée. Elle ne teste que les pages et actions prévues dans les scénarios. Une partie non visitée peut donc garder un défaut.

Une troisième méthode ajoute un programme d’observation à l’application pendant les tests. Elle suit le trajet des données reçues jusqu’aux fonctions sensibles. Elle donne souvent des résultats plus précis, mais dépend elle aussi des actions réellement jouées et peut ralentir l’application.

Le pipeline lance d’abord la lecture rapide du code, puis les contrôles plus longs sur un environnement de test isolé. Les alertes doivent être triées : bloquer immédiatement les défauts graves et confirmés, puis réduire progressivement les alertes inutiles. Les comptes de test, mots de passe et rapports doivent être protégés, renouvelés et surveillés. Si un test ne démarre plus ou ne visite plus les bonnes actions, son résultat vert ne veut rien dire.

Pages voisines

La citent

Intégrer SAST, DAST et IAST dans une CI/CD

Elle cite

Intégrer SAST, DAST et IAST dans une CI/CD

Intégrer SAST, DAST et IAST dans une CI/CD

SAST, DAST et IAST : choisir selon la preuve recherchée

SAST : couverture maximale, signal à discipliner

DAST : preuve d’exposition, couverture conditionnelle

IAST : contexte runtime et dépendance aux tests

Exemple de pipeline : SAST rapide et DAST isolé

Surface d’attaque et conditions d’exploitation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines