🔒 DevSecOps : Intégrer la Sécurité dans votre Pipeline CI/CD

🟡 Niveau : Intermédiaire à Avancé | ⏱️ Lecture : 14 min | 🛠️ Mise en œuvre : 4-8 heures

📚 Prérequis

Expérience avec un outil CI/CD (GitLab CI, GitHub Actions, Jenkins)
Familiarité avec Docker et le build d’images
Compréhension basique des concepts de sécurité applicative

La sécurité n’est plus l’affaire d’une équipe isolée qui intervient en fin de projet. Dans un monde DevSecOps, la sécurité est intégrée dès le début et automatisée dans le pipeline CI/CD. Découvrez comment construire une chaîne de déploiement sécurisée de bout en bout.

🔄 Le Principe du Shift-Left

Traditionnellement, la sécurité intervient tard dans le cycle de développement :

Dev → Test → QA → Sécurité → Production
↑ Découverte tardive = coût élevé

Le Shift-Left déplace la sécurité vers la gauche (plus tôt) :

Dev+Sécurité → Test+Sécurité → QA+Sécurité → Production
↑ Détection précoce = correction facile

Avantage : Une vulnérabilité détectée en phase de développement coûte 6x moins à corriger qu’en production.

🧰 Les Outils de la Chaîne DevSecOps

1. SAST – Static Application Security Testing

Analyse le code source sans l’exécuter. Détecte :

Injections SQL hardcodées
Secrets dans le code
Failles XSS potentielles
Mauvaises pratiques crypto

Outils : Semgrep, SonarQube, Bandit (Python), ESLint security plugins

2. SCA – Software Composition Analysis

Analyse les dépendances (npm, pip, composer, go modules) pour détecter les CVE connues.

Outils : Trivy, Dependabot, Snyk, OWASP Dependency-Check

3. Container Scanning

Analyse les images Docker pour détecter :

Vulnérabilités dans l’OS de base
Packages obsolètes
Mauvaises configurations

Outils : Trivy, Grype, Harbor (intégré)

4. IaC Scanning

Analyse les fichiers Infrastructure as Code (Terraform, Kubernetes, Ansible) :

Outils : Trivy, Checkov, tfsec, KICS

5. Secrets Detection

Détecte les secrets (API keys, passwords) commités dans le code.

Outils : Gitleaks, TruffleHog, git-secrets

6. DAST – Dynamic Application Security Testing

Teste l’application en cours d’exécution en simulant des attaques.

Outils : OWASP ZAP, Nikto, Nuclei

🔗 Pipeline CI/CD Sécurisé Complet

Pipeline DevSecOps : de la sécurité à chaque étape

Voici un exemple de pipeline GitLab CI intégrant toutes les étapes de sécurité :

stages:
  - lint
  - security-code
  - build
  - security-image
  - push
  - deploy-staging
  - security-dast
  - deploy-prod

variables:
  IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

# ============================================================================
# ÉTAPE 1 : LINT ET QUALITÉ
# ============================================================================
lint:
  stage: lint
  script:
    - npm run lint
    - npm run format:check

# ============================================================================
# ÉTAPE 2 : SÉCURITÉ DU CODE (SAST + SECRETS + DÉPENDANCES)
# ============================================================================
sast:
  stage: security-code
  image: returntocorp/semgrep
  script:
    - semgrep --config=p/security-audit --config=p/owasp-top-ten src/
  allow_failure: false

secrets-detection:
  stage: security-code
  image: zricethezav/gitleaks
  script:
    - gitleaks detect --source . --verbose --exit-code 1
  allow_failure: false

dependency-check:
  stage: security-code
  image: aquasec/trivy:latest
  script:
    - trivy fs --exit-code 1 --severity CRITICAL,HIGH .
  allow_failure: false

# ============================================================================
# ÉTAPE 3 : BUILD DE L'IMAGE
# ============================================================================
build:
  stage: build
  script:
    - docker build -t $IMAGE .
  needs:
    - sast
    - secrets-detection
    - dependency-check

# ============================================================================
# ÉTAPE 4 : SCAN DE L'IMAGE DOCKER
# ============================================================================
container-scan:
  stage: security-image
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity CRITICAL,HIGH $IMAGE
  needs:
    - build
  allow_failure: false

# ============================================================================
# ÉTAPE 5 : PUSH VERS LE REGISTRY SÉCURISÉ
# ============================================================================
push:
  stage: push
  script:
    - docker push $IMAGE
  needs:
    - container-scan
  only:
    - main

# ============================================================================
# ÉTAPE 6 : DÉPLOIEMENT STAGING
# ============================================================================
deploy-staging:
  stage: deploy-staging
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  needs:
    - push

# ============================================================================
# ÉTAPE 7 : TESTS DE SÉCURITÉ DYNAMIQUES (DAST)
# ============================================================================
dast:
  stage: security-dast
  image: owasp/zap2docker-stable
  script:
    - zap-baseline.py -t https://staging.example.com -r report.html
  artifacts:
    paths:
      - report.html
    when: always
  needs:
    - deploy-staging
  allow_failure: true  # Les DAST peuvent avoir des faux positifs

# ============================================================================
# ÉTAPE 8 : DÉPLOIEMENT PRODUCTION
# ============================================================================
deploy-prod:
  stage: deploy-prod
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://example.com
  needs:
    - dast
  when: manual  # Validation humaine requise
  only:
    - main

🛑 Blocage Automatique des Vulnérabilités

La clé d’un pipeline sécurisé est le blocage automatique. Si une vulnérabilité critique est détectée, le déploiement doit être impossible.

Trivy avec Exit Code

# Retourne 1 (erreur) si des vulnérabilités CRITICAL ou HIGH sont trouvées
trivy image --exit-code 1 --severity CRITICAL,HIGH myimage:latest

Harbor avec Policies

Harbor peut bloquer le pull d’images vulnérables via des policies :

Allez dans Project → Configuration
Activez « Prevent vulnerable images from running »
Définissez le seuil (Critical, High, Medium)

Résultat : impossible de docker pull une image qui n’a pas passé le scan.

🛡️ WAF : La Dernière Ligne de Défense

Même avec un pipeline parfait, des vulnérabilités peuvent passer. Le WAF (Web Application Firewall) protège en production :

Internet → WAF (ModSecurity) → Application

Le WAF détecte et bloque :

Injections SQL
XSS (Cross-Site Scripting)
Path Traversal
Remote Code Execution
Et bien plus (OWASP CRS)

Important : Le WAF n’est pas une excuse pour négliger la sécurité applicative. C’est une couche supplémentaire, pas un remplacement.

📊 Métriques de Sécurité à Suivre

Ce qui ne se mesure pas ne s’améliore pas. Suivez ces KPIs :

Métrique	Objectif
MTTR (Mean Time To Remediate)	< 7 jours pour les critiques
% builds bloqués par sécurité	Tendance décroissante
Couverture SAST	100% du code
Images avec vulnérabilités critiques	0 en production
Secrets détectés dans le code	0 (zéro tolérance)

🚀 Notre Approche DevSecOps

Nos rôles Ansible intègrent la sécurité by design :

harbor_trivy : Registry privé avec scan automatique des images. Bloquez les images vulnérables avant qu’elles n’atteignent la production.
nginx_modsecurity : WAF avec OWASP CRS pour protéger vos applications en production. Mode observation puis blocage.

Prêt à sécuriser votre supply chain ? Découvrez nos rôles Ansible pour le DevSecOps.

Voir nos rôles DevSecOps

📖 Glossaire

SAST (Static Application Security Testing) : Analyse du code source sans l’exécuter pour détecter des vulnérabilités
DAST (Dynamic Application Security Testing) : Test de sécurité sur une application en cours d’exécution
SCA (Software Composition Analysis) : Analyse des dépendances tierces pour détecter les CVE
Shift-Left : Principe consistant à déplacer les tests de sécurité plus tôt dans le cycle de développement
MTTR (Mean Time To Remediate) : Temps moyen pour corriger une vulnérabilité après sa découverte
Pipeline CI/CD : Chaîne automatisée d’intégration continue et de déploiement continu
Exit Code : Code de retour d’une commande (0 = succès, autre = erreur)

Notre dernier article de la série explorera pourquoi Ansible reste pertinent en 2025 pour l’Infrastructure as Code. À bientôt !