DevSecOps : intégrer la sécurité dans les pipelines CI/CD

DevSecOps n’est pas “ajouter des scans de sécurité à la fin du pipeline”. C’est intégrer la sécurité à chaque étape, de manière à ce qu’elle ne soit pas un goulot d’étranglement mais un filet de sécurité automatique.

Shift left : détecter les problèmes tôt

Le principe fondateur du DevSecOps est que corriger une vulnérabilité coûte 100x moins cher en phase de développement qu’en production. “Shift left” signifie déplacer les contrôles de sécurité le plus tôt possible dans le cycle.

Dev → Commit → CI → CD → Production
 ↑        ↑      ↑    ↑       ↑
Lint   Secrets SAST  DAST  Runtime
check  scan   scan   scan  protection

SAST : analyse statique du code source

SAST (Static Application Security Testing) analyse le code sans l’exécuter — détecte les injections SQL, XSS, credentials hardcodés, dépendances vulnérables.

# GitLab CI — pipeline de sécurité
sast-sonarqube:
  stage: test
  image: sonarsource/sonar-scanner-cli
  script:
    - sonar-scanner
        -Dsonar.projectKey=myapp
        -Dsonar.host.url=$SONARQUBE_URL
        -Dsonar.token=$SONARQUBE_TOKEN
        -Dsonar.qualitygate.wait=true  # échouer si quality gate non passée
  allow_failure: false   # bloquer le pipeline sur vulnérabilité critique

secrets-detection:
  stage: test
  script:
    - gitleaks detect --source=. --report-format=json --report-path=secrets.json
  artifacts:
    reports:
      secret_detection: secrets.json

Scanning des dépendances

dependency-check:
  stage: test
  image: owasp/dependency-check
  script:
    - /usr/share/dependency-check/bin/dependency-check.sh
        --scan .
        --format JSON
        --out reports/
        --failOnCVSS 7   # échouer si CVSS >= 7 (High)
  artifacts:
    paths: [reports/]

# Python — safety pour les dépendances
pip install safety
safety check -r requirements.txt --json > safety-report.json

# Node.js — npm audit
npm audit --audit-level=high --json > audit-report.json

Scanning des images Docker

container-scanning:
  stage: security
  image: aquasec/trivy:latest
  script:
    # Scanner l'image buildée
    - trivy image
        --severity HIGH,CRITICAL
        --exit-code 1              # exit 1 si vulnérabilité trouvée
        --format json
        --output trivy-report.json
        $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    reports:
      container_scanning: trivy-report.json
  allow_failure: true   # warning mais ne bloque pas (à ajuster selon la maturité)

Gestion des secrets dans les pipelines

# ❌ Ne jamais faire ça
env:
  AWS_SECRET: "AKIAIOSFODNN7EXAMPLE"

# ✅ Variables CI/CD protégées et masquées
# GitLab : Settings → CI/CD → Variables → Add variable (Protected + Masked)
# GitHub : Settings → Secrets and variables → Actions
env:
  AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID       # variable CI/CD
  AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY

La règle des 3 niveaux de tolérance

Pour ne pas bloquer les équipes sur chaque finding :

1. CRITICAL — bloquer le pipeline, corriger avant de merger
2. HIGH — créer un ticket automatiquement, merge autorisé avec accord du security lead
3. MEDIUM/LOW — logger pour suivi, ne pas bloquer

Commencer trop strict génère du contournement. Commencer permissif et durcir progressivement génère de l’adhésion.

Notre formation Cybersécurité couvre DevSecOps avec des ateliers pratiques sur des pipelines réels.