SAST vs DAST : choisir l'outil AppSec selon l'étape du SDLC

SAST et DAST sont les deux familles d'outils AppSec de base d'une pipeline DevSecOps. SAST (Static Application Security Testing) analyse le code source sans l'exécuter, DAST (Dynamic Application Security Testing) teste l'application en cours d'exécution depuis l'extérieur. Les deux ne se remplacent pas, ils se complètent à des étapes différentes du SDLC. Selon le rapport OWASP State of Application Security 2025, les équipes qui combinent SAST + DAST + SCA détectent 73 % des vulnérabilités critiques avant la mise en production, contre 34 % pour celles qui n'utilisent qu'un seul outil. Cet article détaille les forces et limites de chaque approche, les patterns d'intégration CI/CD et les pièges à éviter sur le triage des findings.

SAST, l'analyse statique au plus près du commit

Le SAST lit le code source ou le bytecode compilé et cherche des patterns à risque sans jamais lancer l'application. La détection se fait par règles statiques, analyse de flux de données (taint analysis), ou modélisation symbolique selon l'outil.

Cas d'usage typiques détectés :

• Injection SQL via concaténation directe d'une variable utilisateur dans une requête.
• Désérialisation non sécurisée d'un objet provenant d'une entrée externe.
• Secrets hardcodés (clés API, mots de passe) dans le repository.
• Cryptographie faible : MD5, SHA-1, DES, ECB sans IV.
• Validation d'entrée absente ou incomplète sur un endpoint exposé.
• Configuration permissive (CORS wildcard, désactivation de TLS, debug activé).

Le SAST se branche tôt dans le SDLC. Le pattern le plus utile reste le pre-commit hook côté développeur, plus une gate de pull request côté CI qui bloque le merge si une règle de sévérité haute remonte.

Lors d'un audit récent d'une plateforme fintech française, j'ai vu une équipe DevSecOps remonter 1 200 findings Semgrep en une semaine après activation initiale. Sans triage discipliné, ce volume tue la confiance des développeurs et les findings de sévérité haute se noient dans le bruit. La règle pratique : démarrer avec un sous-ensemble de règles OWASP Top 10 (5 à 10 patterns critiques), absorber 3 sprints de triage, puis élargir.

Limites structurelles du SAST

Le SAST a trois angles morts assumés :

1. Configuration runtime : le SAST ne voit pas un container démarré avec --privileged, une variable d'env qui désactive TLS en prod ou un ingress Kubernetes mal configuré.
2. Logique métier complexe : un workflow IDOR (Insecure Direct Object Reference) qui repose sur l'ordre des appels métier reste invisible au scan statique.
3. Dead code et faux positifs : le SAST flag du code qui ne sera jamais exécuté en production, ce qui gonfle les findings et fatigue le triage.

Selon le rapport Snyk State of Open Source Security 2024, le ratio moyen de faux positifs SAST est de 42 % sur les outils non tunés et descend à 12 % après 6 mois de calibration des règles. Ce calibrage est le vrai chantier, pas l'installation.

DAST, le scan dynamique sur l'application en exécution

Le DAST adopte la perspective d'un attaquant externe. Il envoie des requêtes forgées sur l'application en cours d'exécution et observe les réponses pour détecter des vulnérabilités effectivement exploitables.

Catégories de vulnérabilités où le DAST excelle :

• XSS reflected et stored avec exécution réelle dans le navigateur.
• SQL Injection via inférence de réponses (timing-based, error-based).
• SSRF (Server-Side Request Forgery) avec exfiltration vers callback externe.
• XXE (XML External Entity) avec lecture de fichiers locaux.
• Authentication broken : bypass session, tokens prédictibles, replay.
• IDOR via énumération d'identifiants ressources.

Le DAST a deux contraintes opérationnelles qui le rendent plus complexe à câbler que le SAST. La première : il nécessite un environnement applicatif fonctionnel, donc un staging déployé, une base de données seedée, des comptes de test isolés. La seconde : un scan actif peut saturer le service ciblé, ce qui force à scanner en heures creuses ou avec throttling.

Le piège du DAST sur production

Trop d'équipes débutantes pointent leur DAST directement vers la production. Le résultat : pic de charge, alerting infra, et dans le pire cas, blocage de comptes utilisateurs réels par les tentatives d'authentification. La règle de fer reste de scanner staging avec des comptes dédiés, et de réserver la production aux pentests manuels autorisés et au Bug Bounty.

Intégration CI/CD : où placer chaque outil

Le placement dans la pipeline détermine la valeur ajoutée réelle de chaque outil. Trop tôt, on bloque les développeurs avec du bruit. Trop tard, on découvre les vulnérabilités après livraison.

# Exemple GitHub Actions DevSecOps avec SAST + DAST + SCA
name: DevSecOps Pipeline
 
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'  # DAST nocturne sur staging
 
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Semgrep scan
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/owasp-top-ten
          generateSarif: "1"
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif
 
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Trivy scan deps
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          severity: 'HIGH,CRITICAL'
 
  dast:
    if: github.event_name == 'schedule'
    needs: [build, deploy-staging]
    runs-on: ubuntu-latest
    steps:
      - name: ZAP baseline scan
        uses: zaproxy/action-baseline@v0.14.0
        with:
          target: 'https://staging.example.com'
          rules_file_name: '.zap/rules.tsv'

Trois placements à retenir :

• SAST en pull request gate : feedback rapide au développeur, bloque le merge si sévérité haute.
• SCA en parallèle du SAST : détecte les dépendances vulnérables (Log4Shell CVE-2021-44228, OpenSSL CVE-2022-3786, etc.), souvent plus actionnable que le SAST sur le code maison.
• DAST en scan nocturne sur staging : pas de friction sur les développeurs, résultats triés le matin par l'équipe sécurité.

L'IAST (Interactive Application Security Testing) ajoute une 4e couche utile, en instrumentant l'application en runtime staging pendant les tests fonctionnels. Outils : Contrast Security, Veracode IAST. Ce format reste moins répandu mais combine la précision du SAST avec le contexte runtime du DAST.

Triage : le vrai défi opérationnel

Selon l'enquête CESIN 2025 sur la maturité AppSec, 67 % des équipes qui abandonnent leur outillage AppSec citent le volume de findings non triés comme cause principale, pas la qualité de l'outil. Le triage n'est pas un sujet outil, c'est un sujet processus.

Quelques règles pragmatiques pour le triage :

1. Whitelist des règles déclenchées au démarrage : commencer par 10 règles OWASP Top 10, pas par 200 règles default.
2. Suppression contextualisée : une ligne // nosec justifiée par un commentaire vaut mieux qu'un faux positif récurrent qui pollue les diffs.
3. Triage en pair : développeur + ingénieur sécurité ensemble sur les premiers sprints, jamais en silo.
4. Métriques côté équipe : taux de findings résolus / taux de faux positifs marqués / temps moyen de triage. Pas juste le nombre de findings ouverts.

Cas concret : pipeline d'une ESN française CAC 40

Lors d'un audit chez un client ESN qui développe des applications transactionnelles pour le secteur bancaire, j'ai accompagné la mise en place d'une pipeline AppSec complète sur 3 mois. Voici l'architecture finale :

• Pre-commit hooks : Semgrep en mode rapide (5 règles), gitleaks pour les secrets, talisman en complément.
• Pull request gate : Semgrep en mode complet (40 règles OWASP), Trivy sur les dépendances Maven et npm, fail sur sévérité Critical.
• Build pipeline : SonarQube en sécurité + qualité, génération SBOM avec Syft, signature des artefacts avec Cosign.
• Staging post-deploy : ZAP scan baseline en nocturne, Nuclei avec templates communautaires + 12 templates métier custom.
• Production : Falco pour la détection runtime Kubernetes, AWS GuardDuty, Bug Bounty privé sur HackerOne.

Résultat à 6 mois : passage de 0 visibilité à 142 findings critiques triés, dont 38 corrigés en code (35 par les développeurs, 3 escaladés en pentest manuel). Le ROI ne se mesure pas en findings mais en vulnérabilités exploitables corrigées avant prod.

Pour les développeurs qui veulent monter en compétence sur ces sujets de manière structurée, voir le panorama des formations cybersécurité pour profils tech. Le retour de terrain de Naïm Aouaichia, ingénieur cybersécurité avec un parcours DevOps Capgemini et DevSecOps IN Groupe, alimente régulièrement la chaîne YouTube Zeroday Cyber Academy sur ces sujets pratiques.

Pour aller plus loin

• Intégrer la sécurité dans le SDLC : roadmap pratique
• Sécuriser une pipeline GitLab CI : exemples concrets
• DevSecOps expliqué simplement : principes et premiers réflexes
• Référentiels externes : OWASP Application Security Verification Standard (ASVS) et MITRE CWE Top 25.

Points clés à retenir

• SAST et DAST sont complémentaires, pas substituables. Le SAST gagne tôt dans le SDLC, le DAST gagne sur l'application en exécution.
• Le ROI vient du triage discipliné, pas de l'outil installé. Selon CESIN 2025, 67 % des abandons AppSec viennent du volume de findings, pas de la qualité de l'outillage.
• Combiner SAST + DAST + SCA + secrets scanning + IaC scanning donne une couverture sérieuse sur un SDLC moderne.
• Ne jamais scanner la production en DAST actif. Staging avec comptes de test, Bug Bounty pour la prod.
• Commencer petit en règles (10 patterns OWASP), absorber 3 sprints, puis élargir.