Pipeline DevSecOps

Fiche à compléter. La structure et les commandes sont en place ; remplacez les passages entre crochets par les éléments propres à votre implémentation.

Contexte et objectif#

L'objectif est de déplacer les contrôles de sécurité au plus tôt dans le cycle de développement (shift-left), plutôt que de les subir en fin de chaîne. Concrètement : aucun artefact ne doit pouvoir atteindre la production sans avoir traversé une analyse statique de code et un scan de vulnérabilités.

Le principe directeur retenu est simple : le pipeline échoue par défaut. Une étape de sécurité qui ne peut pas s'exécuter bloque le déploiement au lieu de le laisser passer.

Architecture de la chaîne#

  commit
    │
    ▼
┌───────────┐   ┌──────────────┐   ┌──────────────┐   ┌─────────────┐
│  Build    │──▶│ Analyse code │──▶│ Scan vulnér. │──▶│  Déploiement│
│  Jenkins  │   │  SonarQube   │   │    Trivy     │   │  K8s / Helm │
└───────────┘   └──────────────┘   └──────────────┘   └─────────────┘
                       │                   │
                   quality gate      seuil CRITICAL
                       │                   │
                       ▼                   ▼
                    échec du pipeline → pas de mise en production

Étapes du pipeline#

1. Build et tests unitaires#

Compilation de l'application et exécution de la suite de tests. L'image de conteneur est construite à partir d'une image de base minimale, puis étiquetée avec le SHA du commit pour garantir la traçabilité de l'artefact.

stage('Build') {
  steps {
    sh 'docker build -t ${REGISTRY}/${APP}:${GIT_COMMIT} .'
  }
}

2. Analyse statique — SonarQube#

SonarQube analyse le code source et évalue un quality gate : couverture de tests, duplication, vulnérabilités connues, points chauds de sécurité.

stage('SonarQube') {
  steps {
    withSonarQubeEnv('sonar') {
      sh 'sonar-scanner -Dsonar.projectKey=${APP}'
    }
  }
}
stage('Quality Gate') {
  steps {
    timeout(time: 10, unit: 'MINUTES') {
      waitForQualityGate abortPipeline: true
    }
  }
}

L'option abortPipeline: true est la clé : sans elle, le portail qualité devient une simple notification que tout le monde finit par ignorer.

3. Analyse des dépendances — OWASP Dependency-Check#

Recherche de CVE connues dans les bibliothèques tierces embarquées par l'application, en s'appuyant sur la base National Vulnerability Database.

dependency-check.sh \
  --project "${APP}" \
  --scan ./ \
  --format JSON \
  --failOnCVSS 7

4. Scan de l'image de conteneur — Trivy#

Trivy inspecte les couches de l'image : paquets système, dépendances applicatives, secrets accidentellement embarqués et mauvaises configurations.

trivy image \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  --ignore-unfixed \
  ${REGISTRY}/${APP}:${GIT_COMMIT}

--ignore-unfixed évite de bloquer sur des vulnérabilités sans correctif disponible, qui ne feraient qu'entraîner une désensibilisation aux alertes.

5. Déploiement#

Le déploiement n'est atteint que si toutes les étapes précédentes sont passées. L'infrastructure cible est décrite en Terraform et les charges de travail sont déployées sur Kubernetes.

Seuils de blocage retenus#

Difficultés rencontrées#

• [À compléter] — par exemple : gestion des faux positifs, temps d'exécution du

  pipeline, arbitrage entre exhaustivité du scan et fluidité pour les développeurs.

Résultats#

• [À compléter] — durée du pipeline avant / après, nombre de vulnérabilités

  interceptées avant production, taux de faux positifs après ajustement des règles.

Pour aller plus loin#

• Signature des images avec Cosign et vérification par un contrôleur d'admission.
• Génération d'un SBOM à chaque build pour répondre plus vite à une CVE émergente.
• Tests d'intrusion automatisés sur l'environnement de pré-production.