Sécurité des Pipelines DevOps en 2026 : SAST, DAST, Supply Chain et Questions d'Entretien

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 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.

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.

# .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 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.

# .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.

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 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.

# .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, 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 (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 ? »

# .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 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.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
        args: ['--verbose']

# .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.

« 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.

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 surveille le comportement runtime en utilisant eBPF.

# .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 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 scanne Terraform, CloudFormation, Kubernetes, Helm et Dockerfiles pour les mauvaises configurations.

# .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 couvre le côté gestion des secrets de l'équation.