Pipeline SAST DAST SCA 2026 : architecture, outils et intégration CI/CD

Pourquoi un pipeline SAST + DAST + SCA en 2026

La sécurité applicative en 2026 ne se résume plus à un audit annuel mené par un cabinet externe. Trois forces convergent qui rendent l’inspection continue indispensable. D’abord, la pression réglementaire : le Cyber Resilience Act européen (entrée en vigueur progressive jusqu’en décembre 2027), la directive NIS2 et l’Executive Order 14028 américain exigent désormais un inventaire logiciel à jour et la traçabilité des composants tiers. Ensuite, la vélocité de release : un dépôt actif moyen reçoit plusieurs commits par heure, chaque merge introduisant potentiellement une régression de sécurité. Enfin, la sophistication des attaques sur la chaîne d’approvisionnement — l’incident SolarWinds reste la référence, mais l’année 2026 a déjà connu deux compromissions de Trivy elles-mêmes (versions v0.69.4 et tags aquasecurity/trivy-action compromis en mars 2026, corrigées en v0.70.0).

Le triplet SAST, DAST, SCA correspond aux trois angles complémentaires qu’un attaquant exploite : le code écrit en interne, le comportement de l’application en cours d’exécution, et les bibliothèques tierces embarquées. Aucune de ces couches ne couvre les deux autres. Un pipeline industriel les combine, automatise leur exécution sur chaque pull request, agrège les findings dans un seul tableau de bord et bloque le merge dès qu’une nouvelle vulnérabilité critique apparaît. C’est ce que cet article cartographie, depuis les concepts jusqu’au choix d’outils et à l’architecture cible.

Comprendre les trois familles : SAST, DAST, SCA

Le SAST (Static Application Security Testing) analyse le code source ou le bytecode sans l’exécuter. Il parcourt l’arbre syntaxique du programme, suit le flot des données entre sources non fiables (entrée HTTP, lecture de fichier) et puits sensibles (requête SQL, exécution de commande shell), et lève une alerte quand une donnée transite sans assainissement. Les outils modernes — SonarQube Community Build 26.4.0, Semgrep 1.161.0, CodeQL 2.25.2 — vont au-delà de la simple recherche de motifs et raisonnent sur le graphe de contrôle. Leur force : détecter les vulnérabilités introduites au plus tôt, dans l’IDE ou sur la pull request, avant qu’elles ne quittent la machine du développeur. Leur faiblesse : ils ne voient pas la configuration runtime, ne comprennent pas l’authentification implémentée par un middleware, et produisent un volume conséquent de faux positifs sur les codes patrimoniaux.

Le DAST (Dynamic Application Security Testing) attaque l’application déployée. Un proxy intercepte les requêtes émises pendant un parcours de test, modifie systématiquement les paramètres pour tester l’injection SQL, le cross-site scripting, la traversée de répertoire, l’authentification cassée. OWASP ZAP 2.17.0 reste la référence open source, complété chez les éditeurs commerciaux par Burp Suite Enterprise et Invicti. Le DAST détecte des problèmes que le SAST manque structurellement : header de sécurité absent, redirection ouverte, fuite d’information dans les messages d’erreur, configuration TLS faible. Sa contrainte majeure : il faut un environnement applicatif fonctionnel, peuplé de données représentatives, avec des comptes de test pour atteindre les surfaces authentifiées.

Le SCA (Software Composition Analysis) cible les dépendances. À partir du package-lock.json, du go.sum, du Cargo.lock ou du requirements.txt, il croise chaque composant avec la base nationale des vulnérabilités (NVD), les advisories GitHub, OSV.dev et le flux de l’éditeur. Trivy, Grype, Snyk Open Source et Dependabot couvrent ce périmètre. En 2026, le SCA s’étend à la génération de SBOM (Software Bill of Materials) au format CycloneDX 1.7 ou SPDX 2.3, requise par le Cyber Resilience Act pour tout produit logiciel commercialisé en Europe.

La place du runtime et de l’IAST

Deux familles complètent le triptyque. L’IAST (Interactive Application Security Testing) instrumente l’application via un agent qui observe les flux de données pendant les tests fonctionnels. L’agent corrèle le code source, la requête HTTP entrante et le chemin emprunté, ce qui réduit drastiquement les faux positifs par rapport au SAST pur. Contrast Assess et Seeker en sont les représentants commerciaux ; Inspectit et le futur module IAST de Sonar montent en puissance côté open source.

La sécurité runtime, incarnée par Falco 0.43.0 (graduated CNCF depuis février 2024), Tetragon et Sysdig Secure, ne se substitue pas au triptyque SAST/DAST/SCA mais le prolonge en production. Falco lit les appels système via eBPF et déclenche une alerte sur des comportements anormaux : ouverture d’un shell dans un conteneur, lecture de /etc/shadow, connexion sortante vers un domaine non listé. Le runtime sert de filet de sécurité pour ce que la chaîne CI/CD n’a pas vu — typiquement les vulnérabilités zero-day révélées après le déploiement.

Cartographie des outils 2026 : forces, limites, coûts

Le choix d’un outillage ne se réduit pas à comparer des fonctionnalités. Il dépend de l’écosystème (Java enterprise, micro-services Go, monorepo TypeScript), de la taille d’équipe, du modèle de financement et du niveau de durcissement attendu. Le tableau ci-dessous résume les options disponibles en open source ou freemium en mai 2026.

Architecture de référence d’un pipeline DevSecOps

Une architecture industrielle mature s’articule en quatre étages. Au plus près du développeur, l’IDE héberge un pre-commit hook léger qui appelle Semgrep en mode --config auto et un linter de secrets comme gitleaks protect --staged. Le développeur reçoit un retour en moins de deux secondes ; aucune tentative de commit n’est bloquée pour ne pas casser le flow, mais une notification visuelle le sensibilise.

L’étage suivant est la pull request. Sur chaque ouverture ou push, le pipeline CI déclenche en parallèle quatre jobs : un SAST différentiel (Semgrep ou Sonar sur le diff uniquement, pour rester sous la barre des cinq minutes), un SCA (Trivy fs --scanners vuln,secret,license), un build d’image Docker scanné dans la foulée par Trivy image, et un job DAST léger sur l’environnement de preview déployé automatiquement. Les findings sont ensuite poussés dans DefectDojo via son API, avec un identifiant de pull request comme tag pour permettre le rapprochement.

Le troisième étage tourne sur la branche principale, après merge. Le SAST tourne en mode complet — y compris les règles cross-file et les analyses de flot longues à exécuter — et le résultat alimente le mur SonarQube qui historise la dette technique de sécurité. Le DAST passe en mode full crawl, parcourant l’application authentifiée pendant 30 à 60 minutes la nuit. Le SCA produit le SBOM CycloneDX 1.7 publié en artefact à côté de l’image Docker signée par cosign.

Le dernier étage opère en production. Falco tourne en DaemonSet sur chaque nœud Kubernetes, ses alertes filent vers le SIEM (Wazuh, Loki, ou un service managé). Un re-scan périodique des images en exécution avec Trivy image détecte les CVE découvertes après le déploiement. L’ensemble nourrit un même backlog de remédiation, géré par DefectDojo, avec SLA différenciés selon la criticité.

Métriques DevSecOps à instrumenter dès le départ

Sans mesure, un programme sécurité dérive vite vers la conformité de façade. Quatre indicateurs structurent la discussion entre l’équipe sécurité et l’engineering. Le MTTR sécurité (Mean Time To Remediate) mesure le délai médian entre la détection d’une vulnérabilité critique et son correctif en production ; l’objectif d’une équipe mature en 2026 se situe sous 7 jours pour les CVSS ≥ 9, sous 30 jours pour les CVSS ≥ 7. Le taux de couverture rapporte les dépôts effectivement scannés sur la totalité du portefeuille — un chiffre souvent surestimé tant que personne n’a confronté l’inventaire réel des dépôts à l’inventaire CMDB.

Le ratio de faux positifs exprime la proportion d’alertes qualifiées comme non-issue par les développeurs. Au-delà de 30 %, l’équipe perd confiance dans l’outil et finit par ignorer toutes les alertes ; en deçà de 10 %, le tuning des règles est mature. Enfin, le build status sécurité compte la part des merges bloqués ces 30 derniers jours pour cause de finding nouveau ; c’est l’indicateur de friction le plus parlant pour ajuster la politique de seuil.

Adopter le pipeline progressivement sur 90 jours

Lancer les huit outils ensemble est la meilleure manière de saturer l’équipe et de provoquer un rejet. Trois sprints suffisent à poser des fondations solides sans paralyser les développeurs.

Sprint 1 (jours 1 à 30) — visibilité. Activer Semgrep en mode informatif sur tous les dépôts, sans bloquer les PR. Lancer Trivy en pipeline pour produire le SBOM et lister les CVE existantes. Stocker l’historique dans DefectDojo. L’objectif n’est pas de corriger encore, mais de cartographier la dette : combien de CVE critiques pré-existent, sur quels services, par quelles dépendances.

Sprint 2 (jours 31 à 60) — gouvernance. Définir un seuil contractuel avec l’engineering : « toute nouvelle CVE critique introduite par une PR la bloque ». Activer le mode fail-on-new-issue sur le SAST différentiel. Mettre en place le triage hebdomadaire DefectDojo avec un security champion par squad. Documenter les exceptions justifiées via le mécanisme nosemgrep: ou // trivy:ignore, avec date d’expiration obligatoire.

Sprint 3 (jours 61 à 90) — durcissement. Déployer ZAP en scan nocturne sur le pré-prod authentifié. Mettre Falco en production en mode alert-only pour tuner les règles avant de basculer en mode bloquant. Établir la cadence de revue mensuelle des indicateurs (MTTR, couverture, faux positifs) avec le RSSI. À ce stade, la chaîne est opérationnelle ; les itérations suivantes consistent à étendre le périmètre, raffiner les règles personnalisées et industrialiser la signature et la vérification d’images avec cosign et Sigstore.

Shift-left, shift-right : trouver le bon équilibre

Le mouvement shift-left a dominé le discours DevSecOps depuis 2019 : amener la sécurité au plus tôt dans le cycle, idéalement dans l’IDE du développeur. Le pari est juste mais incomplet. Un finding détecté dans l’IDE coûte effectivement 50 à 100 fois moins cher à corriger qu’en production, mais une part irréductible de problèmes ne se révèle qu’à l’exécution : configuration runtime, interaction entre micro-services, secrets injectés par l’orchestrateur, comportements émergents sous charge. Le shift-right assume cette réalité et investit symétriquement dans l’observabilité sécurité de la production : Falco pour le syscall, traces OpenTelemetry pour suivre une requête suspecte, eBPF pour cartographier les flux réseau réels entre pods.

Une équipe mature en 2026 ne choisit pas entre les deux mais répartit son budget sécurité applicative à peu près 60 % sur le pre-production (SAST, SCA, DAST sur preview, signature d’images) et 40 % sur le runtime (Falco, scan continu des images en exécution, audit Kubernetes). Cette répartition compte plus que le choix précis des outils ; elle traduit l’acceptation que la chaîne CI ne couvre pas tout et que la production doit rester instrumentée même si tout passe au vert avant le merge.

Au-delà des outils : la pratique security champion

Aucun pipeline n’absout l’équipe d’une responsabilité humaine. Les organisations qui réussissent leur programme DevSecOps en 2026 désignent dans chaque squad un security champion, développeur senior dont une fraction du temps (typiquement 10 à 20 %) est explicitement allouée à la sécurité applicative : triage des findings de la semaine, propagation des bonnes pratiques, point de contact avec l’équipe sécurité centrale. Ce rôle évite le pattern toxique où l’équipe sécurité publie des règles que les développeurs perçoivent comme une contrainte externe.

Le champion a besoin d’un outillage pédagogique, pas seulement répressif. Semgrep et SonarQube proposent des explications inline pour chaque règle déclenchée, avec des liens vers OWASP Top 10 et CWE. Les sessions capture the flag internes, organisées trimestriellement sur des plateformes comme HackTheBox ou Root-Me, restent l’investissement de formation au meilleur rapport coût-bénéfice. La promotion explicite des champions — visibilité dans la communication interne, certifications (CSSLP, OSWE), participation à des conférences — transforme un poste cosmétique en parcours de carrière reconnu.

Erreurs fréquentes à éviter

Tutoriels pas-à-pas associés

Cette page de référence pose les concepts. Les tutoriels suivants creusent chaque brique avec des commandes testées, des configurations YAML et des extraits de pipeline GitLab CI ou GitHub Actions prêts à coller. Pour ceux qui démarrent, l’ordre suggéré est SonarQube self-host, puis Semgrep, puis Trivy SBOM, puis l’intégration GitLab CI orchestrant le tout.

• Auto-héberger SonarQube Community Build 26.4 sur un VPS Linux pas-à-pas — installation Docker Compose, base PostgreSQL 17, reverse proxy Nginx avec TLS, premier scan d’un projet Java.
• Écrire ses règles Semgrep custom : syntaxe pattern, taint analysis, autofix — passer du quick-start au repo de règles d’équipe, intégration pre-commit, métriques de couverture.
• CodeQL sur GitHub Advanced Security : démarrer une analyse pas-à-pas — activer code scanning, base de données CodeQL en local, requêtes QL pour traquer une vulnérabilité custom.
• Intégrer SAST + SCA + DAST dans un pipeline GitLab CI 18 pas-à-pas — templates Auto DevOps, jobs parallèles, dépendances, artefacts SARIF, dashboard Vulnerability Report.
• Bloquer les PR sur les nouvelles vulnérabilités sans freiner l’équipe — différentiel new vs legacy, baseline, politiques par sévérité, dérogations tracées.
• Réduire les faux positifs SAST de manière disciplinée — triage DefectDojo, suppressions inline avec date d’expiration, métriques de qualité de règles.
• Générer un SBOM CycloneDX 1.7 conforme Cyber Resilience Act — Syft, Trivy, cdxgen 12, signature, attachement à l’image OCI, VEX pour les CVE non exploitables.
• Déployer Falco en complément du pipeline applicatif sans saturer le SOC — installation Helm, règles custom, exclusions, sortie vers Loki et alerting Slack.

FAQ

SAST, DAST et SCA suffisent-ils pour être conforme au Cyber Resilience Act ? Non. Le CRA exige aussi un processus documenté de gestion des vulnérabilités tout au long du cycle de vie produit, un canal de divulgation coordonnée (security.txt, contact dédié), un SBOM tenu à jour, et la notification des incidents exploitant des vulnérabilités au CSIRT national. Le pipeline SAST/DAST/SCA est une condition nécessaire, pas suffisante.

Faut-il préférer SonarQube ou Semgrep pour un nouveau projet ? Les deux ne se substituent pas. Sonar excelle dans le suivi historique de la dette et la mesure de qualité globale (couverture de tests, duplication, complexité cyclomatique). Semgrep est plus efficace pour des règles ciblées, du shift-left agressif et du contexte d’équipe. Une équipe mature utilise les deux : Semgrep en pre-commit et sur PR pour le retour rapide, SonarQube pour le tableau de bord historique et la décoration de PR.

CodeQL est-il vraiment gratuit pour des projets fermés ? Non. La CLI est téléchargeable gratuitement, mais le scan automatisé sur des dépôts privés via GitHub Actions n’est inclus que dans GitHub Advanced Security, désormais scindé depuis le 1er avril 2025 en GitHub Code Security (30 USD/mois/committer actif) et GitHub Secret Protection (19 USD/mois/committer actif). Pour les dépôts publics, le scan est gratuit.

Comment gérer la deuxième compromission de Trivy de mars 2026 ? Vérifier que la version installée est v0.70.0 ou ultérieure et que les images Docker aquasec/trivy utilisées dans le pipeline pointent sur un digest sha256 postérieur à l’incident. Auditer les exécutions de Trivy de la fenêtre concernée pour détecter d’éventuelles exfiltrations de tokens CI.

Le runtime Falco peut-il remplacer un WAF ? Non. Falco observe le comportement à l’intérieur des conteneurs et hôtes ; un WAF inspecte le trafic HTTP au périmètre. Les deux opèrent à des couches différentes et se complètent.

Quelle plateforme d’agrégation choisir entre DefectDojo, Faraday et SecObserve ? DefectDojo OSS reste l’option la plus mûre pour une équipe de 5 à 50 développeurs : ingestion native de plus de 160 formats, déduplication automatique, push Jira/GitHub. Faraday cible plutôt les équipes pentest. SecObserve est intéressant pour des équipes qui veulent une UI plus moderne et un périmètre limité au SAST/SCA, mais la communauté est plus restreinte.

Ressources et lectures associées

• Notes de version SonarQube Community Build — documentation officielle, calendrier mensuel des releases.
• Release notes Semgrep — historique des nouveautés CLI et registry.
• Documentation CodeQL — référence complète du langage de requêtes et des packs officiels.
• Trivy sur GitHub — README, releases, advisories.
• Releases ZAP — versions stables et weekly.
• Documentation Falco — architecture, drivers, règles et plugins.
• Spécification CycloneDX — version 1.7 publiée en février 2026.
• Projet OWASP DefectDojo — page officielle, installation, API.
• Dépôt GitHub DefectDojo — code source, releases, issues.
• NIST Secure Software Development Framework (SSDF) — SP 800-218 — référentiel utilisé pour structurer les contrôles SAST/DAST/SCA.
• Cyber Resilience Act — page ENISA — résumé officiel et calendrier d’application.