# Sécurité des Pipelines DevOps en 2026 : SAST, DAST, Supply Chain et Questions d'Entretien > Guide complet pour sécuriser les pipelines CI/CD en 2026. Couvre SAST, DAST, SCA, génération SBOM, provenance SLSA et questions pratiques d'entretien DevSecOps. - Published: 2026-09-15 - Updated: 2026-09-15 - Author: Anthony Fillion-Maillet - Tags: devops, security, cicd, devsecops, sast, dast - Reading time: 12 min --- La sécurité des pipelines DevOps exige l'intégration de contrôles de sécurité à chaque étape du workflow CI/CD, des hooks pre-commit jusqu'à la surveillance en production. Le [rapport Datadog State of DevSecOps 2026](https://www.datadoghq.com/state-of-devsecops/) révèle que 87% des organisations exploitent des services avec au moins une vulnérabilité connue exploitable, tandis que les attaques sur la chaîne d'approvisionnement logicielle coûtent désormais plus de 80 milliards de dollars par an à l'économie mondiale. > **L'Ordre de Priorité des Outils de Sécurité** > > Commencer par la détection des secrets (impact le plus élevé, taux de faux positifs le plus bas), puis ajouter SCA pour les CVE connues, SAST avec ajustement, analyse IaC, et enfin DAST. Chaque outil doit démontrer sa valeur avant d'ajouter le suivant. ## SAST : L'Analyse Statique qui Détecte les Vulnérabilités Avant le Merge Le Static Application Security Testing (SAST) analyse le code source sans l'exécuter. L'outil parse la base de code, construit un arbre syntaxique abstrait et compare les patterns avec des signatures de vulnérabilités connues. Exécuter SAST sur chaque pull request permet de détecter les injections SQL, XSS et identifiants codés en dur avant que le code n'atteigne la branche principale. Semgrep est devenu l'outil SAST open-source de référence en 2026. Contrairement aux scanners basés sur regex, Semgrep comprend la structure du code et supporte des règles personnalisées en YAML. ```yaml # .github/workflows/sast.yml name: SAST Scan on: pull_request: branches: [main, develop] jobs: semgrep: runs-on: ubuntu-latest container: image: semgrep/semgrep:latest steps: - uses: actions/checkout@v4 - name: Run Semgrep run: semgrep scan --config=auto --sarif --output=semgrep.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: semgrep.sarif ``` Le flag `--config=auto` charge les règles communautaires correspondant aux langages détectés. La sortie SARIF s'intègre à l'onglet Security de GitHub pour suivre les découvertes dans le temps. ## DAST : Les Tests Runtime qui Trouvent ce que l'Analyse Statique Manque Le Dynamic Application Security Testing (DAST) attaque une application en cours d'exécution pour trouver des vulnérabilités qui ne se manifestent qu'au runtime. Les failles d'authentification, les défauts d'autorisation et les bugs de logique métier nécessitent de vraies requêtes HTTP pour être détectés. SAST ne peut pas détecter qu'un endpoint admin manque de contrôle d'accès approprié, mais DAST essaiera d'y accéder sans identifiants et signalera l'exposition. [OWASP ZAP](https://www.zaproxy.org/) reste l'outil DAST open-source le plus déployé. ZAP 3.0, sorti début 2026, a ajouté le support natif pour le scanning GraphQL et gRPC. ```yaml # .github/workflows/dast.yml name: DAST Scan on: deployment: types: [created] jobs: zap-scan: runs-on: ubuntu-latest steps: - name: ZAP Full Scan uses: zaproxy/action-full-scan@v0.12.0 with: target: ${{ secrets.STAGING_URL }} rules_file_name: '.zap/rules.tsv' cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"' - name: Upload Report uses: actions/upload-artifact@v4 with: name: zap-report path: report_html.html ``` DAST s'exécute après le déploiement car il nécessite une cible active. L'environnement de staging sert de surface de test, gardant la production isolée du trafic de scanning. > **DAST en Production** > > Exécuter des scans DAST actifs contre la production risque de déclencher des limites de débit, corrompre des données ou alerter la surveillance de sécurité. Utiliser un environnement de staging qui reproduit la configuration de production. ## SCA : Analyse des Dépendances pour les Vulnérabilités Connues Le Software Composition Analysis (SCA) scanne les dépendances contre les bases de données de vulnérabilités comme la [National Vulnerability Database](https://nvd.nist.gov/) et la GitHub Advisory Database. Une seule dépendance transitive vulnérable peut exposer toute l'application. Le rapport Datadog 2026 a révélé que 42% des services dépendent de bibliothèques qui ne sont plus activement maintenues. Trivy scanne les conteneurs, systèmes de fichiers et dépôts git pour les vulnérabilités en un seul binaire. Il génère des SBOM aux formats CycloneDX et SPDX. ```yaml # .github/workflows/sca.yml name: Dependency Scan on: push: branches: [main] schedule: - cron: '0 6 * * *' # Quotidien à 6h jobs: trivy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@0.28.0 with: scan-type: 'fs' scan-ref: '.' format: 'sarif' output: 'trivy-results.sarif' severity: 'CRITICAL,HIGH' - name: Upload Trivy scan results uses: github/codeql-action/upload-sarif@v3 with: sarif_file: 'trivy-results.sarif' ``` Le scan quotidien planifié détecte les CVE nouvellement divulguées même sans changement de code. Filtrer sur les sévérités CRITICAL et HIGH évite la fatigue d'alertes des découvertes à faible risque. ## Sécurité de la Supply Chain : SBOM et Provenance SLSA Le [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), dont les obligations de reporting entrent en vigueur en septembre 2026, impose la génération de Software Bill of Materials (SBOM) pour les produits vendus dans l'UE. Un SBOM liste chaque composant du logiciel, incluant les dépendances directes, transitives et leurs versions. [SLSA](https://slsa.dev/) (Supply-chain Levels for Software Artifacts) complète le SBOM en vérifiant comment le logiciel a été construit. Le SBOM répond à « quels composants sont dans ce logiciel ? » tandis que SLSA répond à « peut-on faire confiance au processus de build ? » ```yaml # .github/workflows/supply-chain.yml name: Supply Chain Security on: push: tags: - 'v*' jobs: build-with-provenance: runs-on: ubuntu-latest permissions: contents: read id-token: write attestations: write steps: - uses: actions/checkout@v4 - name: Build container image run: docker build -t myapp:${{ github.ref_name }} . - name: Generate SBOM uses: anchore/sbom-action@v0.17.0 with: image: myapp:${{ github.ref_name }} format: cyclonedx-json output-file: sbom.json - name: Sign with Cosign uses: sigstore/cosign-installer@v3.7.0 - name: Sign image and attach SBOM run: | cosign sign --yes myapp:${{ github.ref_name }} cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }} cosign sign --yes --attachment sbom myapp:${{ github.ref_name }} ``` Cosign de Sigstore signe les artefacts en utilisant la signature sans clé adossée à l'autorité de certification Fulcio. La signature lie l'artefact au workflow CI qui l'a produit, permettant de vérifier que l'image provient d'un pipeline de confiance. ## Détection des Secrets : La Première Ligne de Défense Les secrets codés en dur restent la découverte de sécurité la plus courante dans les bases de code. Les clés d'accès AWS, mots de passe de base de données et tokens API commités dans le contrôle de version ont causé des brèches à toutes les échelles. La détection des secrets s'exécute en pre-commit pour bloquer les identifiants avant qu'ils n'entrent dans le dépôt. [Gitleaks](https://github.com/gitleaks/gitleaks) détecte les secrets en utilisant des patterns regex et l'analyse d'entropie. Un hook pre-commit empêche les secrets d'être jamais commités. ```yaml # .pre-commit-config.yaml repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.21.2 hooks: - id: gitleaks args: ['--verbose'] ``` ```yaml # .github/workflows/secrets.yml name: Secrets Detection on: pull_request: jobs: gitleaks: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Gitleaks scan uses: gitleaks/gitleaks-action@v2 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` L'option `fetch-depth: 0` clone l'historique complet, permettant à Gitleaks de scanner tous les commits de la PR, pas seulement le dernier. ## Questions d'Entretien DevSecOps : Ce que les Recruteurs Demandent Les entretiens DevSecOps évaluent à la fois les connaissances en sécurité et l'expérience pratique CI/CD. Les questions ci-dessous apparaissent fréquemment dans les entretiens 2026 pour les postes senior DevOps et ingénierie de plateforme. Consulter plus de questions sur la sécurité des pipelines dans le [module d'entretien CI/CD Pipeline Security](/technologies/devops/interview-questions/cicd-pipeline-security). ### « Comment implémenteriez-vous la sécurité shift-left dans un pipeline existant ? » La sécurité shift-left déplace les tests plus tôt dans le cycle de développement. L'implémentation pratique implique d'ajouter des hooks pre-commit pour la détection des secrets, des scans SAST sur les pull requests et des vérifications SCA dans la phase de build. La clé est l'adoption incrémentale : commencer par la détection des secrets car elle a le taux de faux positifs le plus bas et le signal le plus élevé, puis ajouter SCA pour les CVE connues, puis ajuster les règles SAST pour réduire le bruit avant de l'activer comme contrôle bloquant. ### « Expliquez la différence entre SAST et DAST. Quand utiliseriez-vous chacun ? » SAST analyse le code source sans exécution. Il trouve les injections SQL, XSS et la cryptographie non sécurisée par correspondance de patterns contre la structure du code. SAST s'exécute tôt, sur chaque PR, car il n'a besoin que du code. DAST attaque une application en cours d'exécution. Il trouve les contournements d'authentification, les contrôles d'accès défaillants et les vulnérabilités d'injection qui ne se manifestent qu'au runtime. DAST s'exécute après déploiement contre un environnement de staging. Les deux se complètent. SAST détecte les erreurs de codage avant le merge ; DAST vérifie que l'application déployée se comporte de manière sécurisée. Un pipeline mature exécute les deux. ### « Qu'est-ce qu'un SBOM et pourquoi est-il requis ? » Un Software Bill of Materials liste chaque composant du logiciel, incluant les dépendances directes et transitives avec les versions exactes. Les exigences réglementaires comme l'EU Cyber Resilience Act imposent la génération de SBOM pour les produits entrant sur le marché européen à partir de septembre 2026. Concrètement, le SBOM permet une réponse rapide aux incidents. Quand une nouvelle CVE est publiée, l'équipe de sécurité peut interroger la base de données SBOM pour identifier chaque service exécutant le composant vulnérable au lieu de scanner manuellement tous les dépôts. ### « Comment prévenir la fatigue d'alertes dans l'outillage de sécurité ? » La fatigue d'alertes survient quand les développeurs ignorent les découvertes de sécurité parce que le ratio signal/bruit est trop faible. La prévention nécessite d'ajuster chaque outil avant d'activer les contrôles bloquants. Pour SAST, désactiver les règles qui produisent des faux positifs dans la base de code et les activer progressivement après nettoyage. Pour SCA, se concentrer sur les découvertes de sévérité CRITICAL et HIGH avec des exploits connus. Pour DAST, configurer des scans de référence pour exclure les faux positifs des exécutions futures. La métrique à suivre est le temps de correction pour les vraies vulnérabilités. Si ce nombre augmente, les développeurs ignorent les alertes. > **Préparation aux Entretiens** > > Ces questions testent l'expérience pratique. Préparer des exemples de pipelines réels, incluant les outils spécifiques, les décisions de configuration et les métriques avant et après implémentation. ## Sécurité des Conteneurs et Runtime Le scan d'images de conteneurs détecte les vulnérabilités avant le déploiement. La sécurité runtime surveille les conteneurs en production pour les comportements anormaux. La combinaison traite à la fois les vulnérabilités connues (CVE dans les images de base) et les menaces inconnues (conteneurs compromis, cryptomineurs). Trivy scanne les images dans le cadre du pipeline de build. [Falco](https://falco.org/) surveille le comportement runtime en utilisant eBPF. ```yaml # .github/workflows/container-security.yml name: Container Security on: push: branches: [main] jobs: scan-image: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build image run: docker build -t myapp:${{ github.sha }} . - name: Scan image uses: aquasecurity/trivy-action@0.28.0 with: image-ref: myapp:${{ github.sha }} format: 'table' exit-code: '1' severity: 'CRITICAL' ignore-unfixed: true ``` Le flag `ignore-unfixed: true` ignore les vulnérabilités sans correctifs disponibles. Cela évite de bloquer les déploiements pour des CVE qui ne peuvent actuellement pas être corrigées. Pour la sécurité runtime, les règles Falco détectent les activités suspectes dans les conteneurs en cours d'exécution. Le [module sur la sécurité de la supply chain des conteneurs](/technologies/devops/interview-questions/container-supply-chain) couvre la signature d'images et le contrôle d'admission en profondeur. ## Sécurité IaC : Scanner Terraform et les Manifests Kubernetes L'Infrastructure as Code introduit des risques de sécurité au niveau de la configuration. Les politiques IAM trop permissives, les buckets S3 accessibles publiquement et les bases de données non chiffrées résultent de valeurs par défaut non sécurisées dans les templates IaC. [Checkov](https://www.checkov.io/) scanne Terraform, CloudFormation, Kubernetes, Helm et Dockerfiles pour les mauvaises configurations. ```yaml # .github/workflows/iac-scan.yml name: IaC Security Scan on: pull_request: paths: - 'terraform/**' - 'k8s/**' - 'helm/**' jobs: checkov: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Checkov uses: bridgecrewio/checkov-action@v12 with: directory: . framework: terraform,kubernetes,helm output_format: sarif output_file_path: checkov.sarif soft_fail: false - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: checkov.sarif ``` Le filtre de chemin garantit que les scans IaC ne s'exécutent que lorsque les fichiers d'infrastructure changent, réduisant le temps CI pour les changements uniquement applicatifs. ## Le Pipeline DevSecOps Complet pour 2026 Un pipeline DevSecOps prêt pour la production en 2026 intègre ces outils à chaque étape : - **Pre-commit** : Gitleaks (secrets), SAST local optionnel - **Pull request** : Semgrep (SAST), Trivy (SCA), Checkov (IaC) - **Build** : Scan d'images de conteneurs, génération SBOM - **Pre-deploy** : Signature d'images avec Cosign, contrôle d'admission avec Kyverno - **Post-deploy** : DAST avec ZAP contre le staging - **Runtime** : Falco pour la surveillance des conteneurs, gestion de la posture de sécurité cloud La stack gratuite (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) couvre chaque catégorie. Les outils commerciaux ajoutent des tableaux de bord centralisés, la gestion des politiques et un effort d'ajustement réduit, mais la couverture de sécurité est atteignable sans coûts de licence. Les organisations qui se préparent aux rôles DevSecOps devraient pratiquer la construction de ces pipelines dans des projets personnels. Le [module sur la gestion des identités cloud et des secrets](/technologies/devops/interview-questions/cloud-identity-secrets) couvre le côté gestion des secrets de l'équation. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/fr/blog/devops/devops-pipeline-security-sast-dast-2026