SAST vs DAST vs IAST : comparatif technique 2025

SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing) et IAST (Interactive Application Security Testing) sont les trois techniques majeures de test de sécurité applicative en 2025, chacune avec sa mécanique interne distincte, ses forces et angles morts. SAST analyse le code source ou bytecode sans exécution via parsing d'AST (Abstract Syntax Tree) + analyse de flux de données taint, détection au moment du commit ou du build. DAST teste l'application en cours d'exécution depuis l'extérieur via requêtes HTTP, aveugle au code interne, détection en pré-prod. IAST instrumente l'application en cours d'exécution via un agent qui observe simultanément les entrées HTTP et les appels de fonctions internes, corrélation précise des deux, détection en QA avec tests fonctionnels. Chaque technique a un profil distinct de faux positifs (SAST 15-35 %, DAST 5-15 %, IAST 1-5 %), de couverture (SAST 100 % du code / IAST 40-60 % code exécuté / DAST surface externe), et de phase SDLC optimale. Aucune ne remplace les autres. Un programme AppSec 2025 mature combine les trois complémentairement, avec une couche SCA (Software Composition Analysis) et RASP (Runtime Application Self-Protection) en défense opérationnelle. Cet article détaille la mécanique interne de chaque, le tableau comparatif complet, les outils open source et commerciaux 2025, les stratégies d'intégration CI/CD et de tuning, avec les coûts de déploiement réalistes pour une ETI française.

1. Les trois techniques en 90 secondes

Les trois techniques répondent à des questions distinctes. SAST : « mon code contient-il des patterns vulnérables ? ». DAST : « mon application exposée sur le réseau est-elle exploitable ? ». IAST : « pendant les tests fonctionnels, quelles données utilisateur atteignent des sinks dangereux ? ». Pour le positionnement AppSec global, voir Roadmap AppSec Engineer et Roadmap secure coding.

2. SAST en détail : parsing statique et taint analysis

2.1 Mécanique interne

Un SAST moderne (Semgrep, CodeQL, SonarQube, Snyk Code, Checkmarx, Veracode) opère en 4 étapes :

SAST — pipeline interne
────────────────────────
1. Parsing
   ─► Lecture du code source langage par langage
   ─► Production d'un Abstract Syntax Tree (AST) par fichier
 
2. Construction d'un graphe
   ─► Call Graph (appels de fonctions)
   ─► Control Flow Graph (CFG) par fonction
   ─► Data Flow Graph (DFG) inter-fonctions
   ─► Résolution des types (si langage typé)
 
3. Analyse de patterns / taint
   ─► Identification des sources (req.body, req.params, user input)
   ─► Suivi de la propagation via assignments, appels, retours
   ─► Détection d'arrivée dans un sink (exec, SQL, response HTML)
   ─► Vérification des sanitizers éventuels sur le chemin
 
4. Reporting
   ─► Règle matchée + trace source → sink
   ─► Sévérité (CWE, OWASP, CVSS propriétaire)

2.2 Forces de SAST

• Couverture du code complet — y compris branches non-exécutées par les tests.
• Intégration précoce — au commit ou PR, feedback dev en minutes.
• Règles personnalisables — Semgrep et CodeQL permettent d'écrire des règles métier spécifiques en 10-30 lignes (ex: interdire l'usage de os.system avec paramètre dynamique).
• Accès aux versions historiques — un SAST peut scanner toute la branche et identifier quand une vulnérabilité a été introduite.

2.3 Angles morts de SAST

• Faux positifs élevés par nature : le SAST ne peut pas toujours prouver l'exploitabilité réelle (ex: une concat SQL dans du code mort reste signalée).
• Broken Access Control (OWASP A01) — exige compréhension du modèle d'autorisation métier, non dérivable du code seul.
• Insecure Design (OWASP A04) — les erreurs de conception ne se voient pas à l'échelle d'un fichier.
• Configuration runtime — TLS, headers serveur, secrets rotation : hors scope.
• Dépendances tierces — SAST ne scanne pas node_modules, vendor, jars ; couvert par SCA distinct.

2.4 Exemple règle Semgrep custom

# règle Semgrep : détecte les requêtes HTTP sortantes sans allowlist
rules:
  - id: ts-outbound-http-no-allowlist
    pattern-either:
      - pattern: fetch($URL, ...)
      - pattern: axios.get($URL, ...)
      - pattern: axios.post($URL, ...)
    pattern-not-inside: |
      if (ALLOWED_HOSTS.has(...)) {
        ...
      }
    message: >
      Appel HTTP sortant sans allowlist apparente. Risque SSRF si $URL
      est dérivée d'un input utilisateur. Voir principes-secure-coding.
    severity: WARNING
    languages: [typescript, javascript]
    metadata:
      cwe: CWE-918
      owasp: A10:2021

Voir le principe SSRF allowlist détaillé dans Principes de secure coding.

3. DAST en détail : scan dynamique black-box

3.1 Mécanique interne

Un DAST (OWASP ZAP, Burp Suite Enterprise, Acunetix, Qualys WAS, Rapid7 AppSpider) opère comme un attaquant humain outillé :

DAST — pipeline d'exécution
─────────────────────────────
1. Crawling
   ─► Spider passif (suit liens, forms) + actif (fuzzing paramètres)
   ─► Enregistrement de la surface d'attaque (endpoints, params, cookies)
 
2. Scan actif
   ─► Envoi de payloads malicieux sur chaque paramètre observé
      (SQLi tautology, XSS polyglot, SSRF OOB, XXE, SSTI, command injection)
   ─► Analyse de la réponse (contenu + status code + timing)
 
3. Validation d'exploitabilité
   ─► Preuve via OOB (DNS / HTTP callback vers collaborator server)
   ─► Ou via contenu réfléchi, erreur SQL visible, output non-sanitized
 
4. Reporting
   ─► Findings avec request / response complètes comme preuve
   ─► Priorisation par CVSS + exploitabilité confirmée

3.2 Forces de DAST

• Pas de faux positifs théoriques — le DAST n'affirme qu'une vulnérabilité réellement déclenchable depuis l'extérieur.
• Couverture des configurations runtime — TLS, HSTS, CSP manquant, cookie flags, headers de sécurité.
• Aveuglement au langage et au framework — fonctionne sur Java/.NET/PHP/Node/Python/Ruby indifféremment.
• Valide les WAF / reverse proxies — teste la chaîne complète telle que l'attaquant la voit.

3.3 Angles morts de DAST

• Couverture limitée par le crawling — routes non-accessibles depuis le spider (API avec auth complexe, endpoints cachés, fonctionnalités admin) sont ratées.
• Exécution lente — scan complet d'une app moyenne de 30-200 endpoints prend 4-24h.
• Authentification complexe (OAuth2, MFA, SSO) requiert configuration manuelle ou scripts Selenium.
• Logique métier — DAST ne comprend pas les workflows métier (panier / paiement / approbation) et rate les vulnérabilités BUSL du WSTG OWASP.
• Non-intégrable en CI/CD sur chaque commit — trop lent, nécessite environnement déployé.

3.4 Cas d'usage DAST en pipeline

# GitHub Actions — DAST ZAP baseline scan en post-deploy staging
name: DAST ZAP baseline
on:
  workflow_run:
    workflows: ["Deploy to staging"]
    types: [completed]
 
jobs:
  zap-baseline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: ZAP baseline scan
        uses: zaproxy/action-baseline@v0.10.0
        with:
          target: https://staging.example.com
          rules_file_name: .zap/rules.tsv
          cmd_options: "-a"
          allow_issue_writing: false
          fail_action: true

4. IAST en détail : instrumentation runtime

4.1 Mécanique interne

IAST (Contrast Security, Checkmarx IAST, HCL AppScan, Synopsys Seeker) est techniquement le plus sophistiqué des trois :

IAST — pipeline d'instrumentation
──────────────────────────────────
1. Déploiement agent
   ─► Agent attaché au runtime Java / .NET / Node / Python
      via instrumentation bytecode (Java agent), Profiler API (.NET),
      require-hook (Node), importlib hook (Python)
 
2. Hooks sur sources et sinks
   ─► Sources : req.body, getParameter, headers, cookies, session
   ─► Sinks : exec, query(), render(), writeFile, deserialize
   ─► Transformations : chaque appel modifie le taint metadata
 
3. Exécution fonctionnelle normale
   ─► Tests Playwright / Cypress / Postman / manuel QA
   ─► L'agent suit le taint sur les données observées
 
4. Détection corrélée
   ─► Quand une donnée tainted atteint un sink sans sanitizer reconnu
      → vulnérabilité confirmée (pas juste pattern match)
   ─► Enregistrement : HTTP request d'origine + stack trace + sink
 
5. Reporting temps réel
   ─► Dashboard : chaque finding lié à une requête QA précise
   ─► Suggestions de correction avec la ligne de code exacte

4.2 Forces de IAST

• Précision maximale — corrélation input HTTP + exécution interne, faux positifs 1-5 %.
• Pas de crawling nécessaire — suit les tests fonctionnels existants.
• Stack trace complète — indique exactement quelle ligne est vulnérable et avec quelle payload.
• Couverture des chemins complexes — si un test fonctionnel navigue un workflow admin, IAST observe les vulnérabilités sur ce chemin, contrairement à DAST.

4.3 Angles morts de IAST

• Couverture limitée aux chemins exécutés — 40-60 % du code typique. Les erreurs sur branches non-testées restent invisibles.
• Dépendance à la qualité des tests fonctionnels — si les tests Playwright couvrent 20 % de l'app, IAST couvre 20 %.
• Support langage limité — agents disponibles sur Java, .NET, Node.js, Python, Ruby ; pas ou peu sur Go, Rust, C++.
• Coût runtime — overhead typique 5-15 % sur les environnements instrumentés, interdit en production.
• Licensing commercial — peu d'options open source viables en 2025.

5. Comparatif synthétique

6. Intégration SDLC réelle

Séquence recommandée pour un programme AppSec 2025 aligné OWASP DevSecOps Guideline :

6.1 Au commit / pré-commit (local dev)

• Linter secrets : gitleaks, truffleHog. Durée < 5 secondes.
• SAST rapide : Semgrep avec règles ciblées (~50-100 règles, pas catalogue complet). Durée < 30 secondes.

6.2 En Pull Request (CI)

• SAST complet : Semgrep ou Snyk Code sur le diff + touched files. Durée 2-10 minutes.
• SCA : Trivy ou Snyk sur dépendances modifiées. Durée < 2 minutes.
• IaC scan : Checkov / Terrascan sur Terraform / Helm. Durée < 1 minute.
• Container scan : Trivy ou Grype sur image buildée. Durée 2-5 minutes.

6.3 En merge sur main (CI)

• SAST complet full codebase périodique (nightly). Durée 15-60 minutes.
• Rebuild container images + scan + push registry signé.
• SBOM génération (CycloneDX / SPDX) pour supply chain.

6.4 En QA / staging (post-deploy)

• IAST agent attaché, tests fonctionnels automatisés Playwright / Cypress exécutés.
• DAST baseline (ZAP baseline scan, ~15-30 min) sur les routes publiques.

6.5 En pré-prod / prod

• DAST full une fois par semaine ou après changement significatif.
• RASP (Runtime Application Self-Protection) agent pour détection / blocage en prod.

Timeline SDLC AppSec 2025
──────────────────────────────────
Commit ─► secrets scan ─► SAST ciblé   (pre-commit hook)
   │
   ▼
Pull Request ─► SAST full diff ─► SCA ─► IaC scan ─► Container scan
   │
   ▼
Merge main ─► SAST nightly ─► SBOM ─► Image signing
   │
   ▼
Deploy staging ─► IAST attached ─► E2E tests ─► DAST baseline
   │
   ▼
Deploy prod ─► DAST weekly ─► RASP runtime protection

7. Outils open source et commerciaux 2025

7.1 SAST

7.2 DAST

7.3 IAST

Pour une vision plus large de l'écosystème outillage DevSecOps, voir Étapes pour devenir DevSecOps et l'article court complémentaire SAST vs DAST.

8. Faux positifs : tuning en pratique

Les faux positifs dégradent l'adoption dev et les équipes finissent par ignorer les findings. Trois pratiques réduisent massivement le bruit :

8.1 Règles ciblées métier plutôt que catalogue complet

Un Semgrep ou CodeQL déployé avec 100 % des règles par défaut génère 3-5 findings par fichier modifié et tue l'adoption. Mieux : activer 50-150 règles ciblées sur les classes de vulnérabilités pertinentes pour le stack (backend Python Flask : injection SQL, XSS Jinja2, pickle, CSRF Flask-WTF ; frontend TypeScript : XSS React dangerouslySetInnerHTML, prototype pollution, ouvertures URL). Puis ajouter progressivement.

8.2 Suppression contextuelle, pas globale

# ❌ mauvaise pratique : désactivation globale
# nosemgrep
 
# ✅ suppression ciblée avec justification
query = "SELECT * FROM logs WHERE timestamp > NOW() - INTERVAL 1 DAY"  # nosemgrep: python-sql-string-concat -- query constante, pas d'input utilisateur

8.3 Baseline et failwire progressif

Première semaine d'intégration : fail_on_severity: none, on accumule les findings existants (baseline). Semaine 2 : fail_on_severity: critical pour les nouveaux introduits uniquement. Semaine 4-8 : fail_on_severity: high. Semaine 12+ : fail_on_severity: medium. Cette montée progressive évite de bloquer d'emblée les équipes et concentre l'effort sur les nouveaux findings, plus faciles à corriger que la dette.

9. Compléments obligatoires : SCA, RASP, MAST

Les trois techniques SAST/DAST/IAST ne couvrent pas toute la surface. Quatre compléments :

• SCA (Software Composition Analysis) : Trivy, Snyk Open Source, Dependency-Check, OSV-Scanner. Couvre les vulnérabilités dans les dépendances tierces (A06 OWASP). Voir le mécanisme dans Désérialisation insecure qui montre pourquoi la chaîne de dépendances compte.
• RASP (Runtime Application Self-Protection) : Contrast Protect, Sqreen (Datadog), Signal Sciences. Bloque en production les exploitations connues. Complément d'IAST côté prod.
• MAST (Mobile Application Security Testing) : équivalent SAST/DAST pour iOS / Android. Outils : MobSF open source, NowSecure, HCL AppScan Mobile.
• API Security testing : 42Crunch, Salt Security, Traceable.ai — spécialisé sur l'OWASP API Top 10 2023.

Points clés à retenir

• Définitions : SAST = statique code-level, DAST = dynamique externe black-box, IAST = instrumentation runtime hybride.
• Faux positifs : SAST 15-35 % (5-10 % tuné), DAST 5-15 %, IAST 1-5 % mais couverture limitée.
• Complémentarité SDLC : SAST en commit/PR, IAST en QA staging, DAST en pré-prod/prod. Aucun substituable.
• Couverture OWASP Top 10 : chacune ~60-70 % seule, complémentarité nécessaire. A04 Insecure Design exige humain + threat modeling.
• Open source 2025 : Semgrep (SAST), ZAP (DAST), Contrast CE restreint (IAST). IAST reste majoritairement commercial.
• Coût programme ETI : 80-200 k€/an en mix open source + commercial ciblé (SAST+DAST gratuits + IAST commercial), 200-400 k€/an en stack entièrement commerciale.
• Compléments obligatoires : SCA (dépendances), RASP (runtime prod), MAST (mobile), API security tools.

Pour le parcours AppSec Engineer complet, voir Roadmap AppSec Engineer. Pour le mapping avec les vulnérabilités concrètes, Introduction OWASP Top 10 et Principes de secure coding.