La majorité des organisations n'ont pas encore réellement intégré la sécurité dans chaque étape de leur pipeline CI/CD. Le reste bricole : un scan ici, un audit ponctuel là, et une prière silencieuse avant chaque mise en production. Le DevSecOps promet de changer cette réalité en injectant la sécurité dans chaque phase du cycle de développement. Voici comment passer de la théorie à la pratique.
Pourquoi le DevSecOps, et pourquoi maintenant
Le modèle traditionnel, où la sécurité intervient en fin de chaîne, ne tient plus. Les cycles de release se comptent en jours, parfois en heures. Attendre un audit de sécurité post-déploiement revient à vérifier les freins d'une voiture après l'avoir lancée sur l'autoroute.
L'enquête révèle que le coût de correction d'une vulnérabilité explose à mesure qu'elle progresse dans le pipeline : corriger en phase de développement coûte en moyenne 10 fois moins qu'en production. C'est un argument économique avant d'être un argument technique.
Le DevSecOps repose sur trois principes fondamentaux :
- Shift-left : détecter les failles le plus tôt possible dans le cycle
- Automatisation : zéro intervention manuelle pour les contrôles de sécurité récurrents
- Feedback rapide : informer les développeurs en temps réel, pas trois semaines après le commit
Ce que le DevSecOps n'est pas
Avant d'aller plus loin, clarifions un malentendu fréquent. Le DevSecOps n'est pas :
- Un rôle : ce n'est pas « un ingénieur DevSecOps ». C'est une responsabilité partagée entre développeurs, ops et sécurité.
- Un outil magique : installer SonarQube ne rend pas votre pipeline DevSecOps. C'est l'intégration systématique et les quality gates qui font la différence.
- Un frein à la vélocité : bien implémenté, le DevSecOps accélère les releases en éliminant les allers-retours tardifs avec l'équipe sécurité.
Les rapports DORA (DevOps Research and Assessment) montrent que les équipes elite, qui intègrent la sécurité tôt dans le cycle, déploient significativement plus fréquemment que celles qui la traitent en fin de chaîne. La sécurité n''est plus un goulot d''étranglement ; c''est un accélérateur.
Les quatre piliers d'un pipeline sécurisé
Un pipeline DevSecOps complet s''articule autour de quatre types d''analyses complémentaires. Chacun couvre un angle mort que les autres ne voient pas.
SAST : analyser le code source avant l'exécution
Le Static Application Security Testing (SAST) examine le code source ligne par ligne, sans exécuter l'application. C'est l'équivalent d'une relecture par un expert sécurité, mais à la vitesse d'un compilateur.
SonarQube reste la référence open source pour le SAST. Il détecte les injections SQL, les failles XSS, les dépendances non sécurisées et les mauvaises pratiques de codage. Son intégration dans GitLab CI est directe :
sonarqube-check:
stage: test
image: sonarsource/sonar-scanner-cli:latest
variables:
SONAR_USER_HOME: '${CI_PROJECT_DIR}/.sonar'
GIT_DEPTH: '0'
script:
- sonar-scanner
-Dsonar.projectKey=$CI_PROJECT_NAME
-Dsonar.sources=.
-Dsonar.host.url=$SONAR_HOST_URL
-Dsonar.token=$SONAR_TOKEN
-Dsonar.qualitygate.wait=true
allow_failure: false
Le paramètre qualitygate.wait=true est crucial : il bloque le pipeline tant que les critères de qualité ne sont pas satisfaits. Pas de passe-droit, pas de "on verra plus tard".
Pour aller plus loin dans la sécurisation de votre chaîne CI/CD, consultez notre guide sur le déploiement GitLab CI avec Kubernetes.
DAST : tester l'application en conditions réelles
Le Dynamic Application Security Testing (DAST) adopte la perspective de l'attaquant. Il bombarde l'application en cours d'exécution avec des requêtes malveillantes pour identifier les vulnérabilités runtime.
ZAP (Zed Attack Proxy, anciennement OWASP ZAP) est l''outil de référence. Gratuit, open source, désormais maintenu par Checkmarx sous le giron de la Linux Foundation. Il simule des attaques XSS, des injections SQL, des tests de configuration et bien plus.
dast-scan:
stage: security
image: ghcr.io/zaproxy/zaproxy:stable
script:
- zap-baseline.py
-t $APP_URL
-r zap-report.html
-l WARN
-d
artifacts:
paths:
- zap-report.html
when: always
Ce que les chiffres ne disent pas : le DAST seul ne suffit jamais. Il ne voit que ce qu'un attaquant externe verrait. Les failles logiques, les escalades de privilèges subtiles, les erreurs de configuration internes lui échappent. C'est pourquoi il faut le coupler au SAST.
Pour comprendre les enjeux de sécurité applicative en profondeur, notre article sur la sécurité des API détaille les vecteurs d''attaque les plus courants.
SCA : traquer les vulnérabilités dans les dépendances
Le Software Composition Analysis (SCA) scanne les bibliothèques tierces utilisées par votre application. Selon les données du Synopsys Open Source Security and Risk Analysis Report, près de 77 % du code d''une application moderne provient de dépendances open source. C''est autant de surface d''attaque que vous ne contrôlez pas directement.
Snyk excelle dans ce domaine. Il analyse le package.json, le requirements.txt, le go.mod ou tout autre fichier de dépendances, et compare chaque version contre les bases de vulnérabilités connues (CVE).
snyk-test:
stage: security
image: snyk/snyk:node
script:
- snyk auth $SNYK_TOKEN
- snyk test --severity-threshold=high --fail-on=all
- snyk monitor
allow_failure: false
L'option --severity-threshold=high évite l'alert fatigue en ne bloquant le pipeline que pour les vulnérabilités critiques ou élevées. Les vulnérabilités mineures sont tout de même remontées via snyk monitor pour un traitement ultérieur.
Alternative open source : si vous préférez une solution entièrement open source, trivy fs . offre une fonctionnalité SCA comparable. Trivy analyse les fichiers de dépendances (package-lock.json, go.sum, requirements.txt) et les compare contre la base de vulnérabilités NVD. Moins de fonctionnalités de remédiation automatique que Snyk, mais zéro dépendance à un service tiers.
sca-trivy:
stage: security
image: aquasec/trivy:latest
script:
- trivy fs
--severity HIGH,CRITICAL
--exit-code 1
--scanners vuln
.
allow_failure: false
Scanning IaC et images conteneurs : la dernière ligne de défense
L'Infrastructure as Code (IaC) et les images conteneurs représentent une surface d'attaque souvent négligée. Un Dockerfile mal configuré, un manifeste Kubernetes trop permissif, un Terraform avec des ports ouverts au monde entier : autant de bombes à retardement.
Trivy d''Aqua Security couvre les deux : scanning d''images conteneurs et audit de fichiers IaC. C''est l''outil que nous utilisons chez SHPV pour sécuriser les déploiements de nos clients.
trivy-scan:
stage: security
image: aquasec/trivy:latest
script:
- trivy image
--severity HIGH,CRITICAL
--exit-code 1
--no-progress
$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- trivy config
--severity HIGH,CRITICAL
--exit-code 1
./deploy/
La première commande scanne l'image Docker. La seconde audite les fichiers de configuration (Terraform, Kubernetes, Dockerfile). Notre guide complet sur Trivy pour le scanning de conteneurs détaille l'installation et la configuration avancée.
Orchestrer les scans dans le pipeline
L''erreur classique consiste à exécuter tous les scans en séquence. Résultat : un pipeline qui dure 45 minutes et des développeurs qui contournent les contrôles. La bonne approche est la parallélisation.
stages:
- build
- test
- security
- deploy
# Les scans de sécurité tournent en parallèle
sast-scan:
stage: security
# SonarQube config...
dast-scan:
stage: security
# OWASP ZAP config...
sca-scan:
stage: security
# Snyk config...
container-scan:
stage: security
# Trivy config...
SAST et SCA peuvent tourner dès la phase de build (ils n''ont besoin que du code source). DAST nécessite un environnement de staging déployé. Trivy intervient après le build de l''image Docker. En parallélisant intelligemment, le overhead sécurité passe de 30 minutes à 5 ou 8 minutes.
Exemple de pipeline complet
Voici un pipeline GitLab CI complet qui orchestre les quatre types de scans avec des dépendances correctes :
stages:
- build
- test
- security-static # SAST + SCA (pas besoin d'artefact)
- security-container # Scanning image (après build)
- security-dynamic # DAST (après déploiement staging)
- deploy-staging
- deploy-production
build-image:
stage: build
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
sonarqube-sast:
stage: security-static
# Tourne en parallèle avec sca-scan
sca-scan:
stage: security-static
# Tourne en parallèle avec sonarqube-sast
trivy-container:
stage: security-container
needs: [build-image] # Attend le build de l'image
deploy-staging:
stage: deploy-staging
needs: [trivy-container, sonarqube-sast, sca-scan]
owasp-zap-dast:
stage: security-dynamic
needs: [deploy-staging] # Attend le déploiement staging
deploy-production:
stage: deploy-production
needs: [owasp-zap-dast]
when: manual # Gate manuelle finale
Le mot-clé needs de GitLab CI permet de créer un graphe de dépendances précis. Les scans statiques tournent en parallèle dès que le code est disponible. Le scan conteneur attend le build. Le DAST attend le déploiement staging. Et le déploiement production nécessite une validation manuelle après tous les scans.
Gérer les secrets dans le pipeline
Un pipeline DevSecOps qui stocke ses secrets en clair dans les variables CI est une contradiction vivante. L'utilisation d'un gestionnaire de secrets chiffré est indispensable.
Pour les secrets dans un dépôt Git, SOPS (Secrets OPerationS) de Mozilla chiffre les fichiers de configuration avec des clés GPG ou des KMS cloud. Notre article sur SOPS pour le chiffrement des secrets explique la mise en place pas à pas.
Pour les registres d''images, un registry privé comme Harbor ajoute une couche de scanning intégrée et de signature d''images. Consultez notre guide sur Harbor comme registry sécurisé pour les détails de déploiement.
Les quality gates : pas de compromis
Un pipeline DevSecOps sans quality gate est un pipeline de décoration. Les quality gates définissent les critères objectifs qui autorisent ou bloquent le passage à l'étape suivante.
Trois éléments sont à retenir pour des quality gates efficaces :
- Seuil de sévérité : bloquer sur les vulnérabilités HIGH et CRITICAL, monitorer les MEDIUM
- Couverture de scan : exiger que 100 % des composants soient analysés (pas de skip partiel)
- Délai de remédiation : définir un SLA de correction (24h pour CRITICAL, 7 jours pour HIGH)
Le piège à éviter : rendre les quality gates contournables avec un allow_failure: true. Si les développeurs peuvent bypasser le contrôle, ils le feront. C'est la nature humaine, pas un défaut de caractère.
Tableaux de bord et reporting
Les quality gates ne servent pas uniquement à bloquer. Elles produisent des données exploitables. Configurez un tableau de bord qui agrège :
- Le nombre de vulnérabilités détectées par sprint (tendance à la baisse = pipeline efficace)
- Le temps moyen de remédiation (MTTR) par sévérité
- Le taux de faux positifs par outil (pour ajuster les règles)
- La couverture de scan : pourcentage de composants analysés
SonarQube fournit ce reporting nativement. Pour les autres outils, l'export des rapports au format JSON ou SARIF permet l'agrégation dans un outil centralisé comme DefectDojo ou GitLab Security Dashboard.
Compliance as Code
L''enquête révèle que la conformité (ISO 27001, SOC 2, PCI DSS) est l''un des moteurs principaux de l''adoption du DevSecOps. Plutôt que de préparer un audit annuel dans la douleur, le pipeline DevSecOps génère des preuves de conformité en continu.
Chaque exécution du pipeline produit :
- Des rapports de scan horodatés et versionnés
- Des preuves que les quality gates ont été respectées
- Un historique complet des vulnérabilités détectées et corrigées
- Des traces d''audit pour chaque déploiement
Cette approche « compliance as code » transforme l'audit de sécurité d'un événement stressant en un processus automatisé. Les auditeurs accèdent aux rapports en libre-service, et l'équipe peut se concentrer sur l'amélioration continue plutôt que sur la collecte de preuves.
GitOps et sécurité continue
Le DevSecOps ne s''arrête pas au déploiement. Les approches GitOps, avec des outils comme Argo CD ou Flux CD, permettent de maintenir la sécurité en continu :
- Tout changement d''infrastructure passe par un commit Git (auditable)
- Les scans IaC s''exécutent automatiquement sur chaque pull request
- Le drift detection identifie les modifications non autorisées en production
C'est le prolongement naturel du DevSecOps : la sécurité n'est plus un événement ponctuel, c'est un processus continu.
Drift detection et remédiation automatique
Le drift detection mérite une attention particulière. En production, il arrive que des modifications soient apportées manuellement (un kubectl edit en urgence, une règle firewall ajoutée à la volée). Ces changements non versionnés créent un écart entre l'état déclaré dans Git et l'état réel de l'infrastructure.
Les outils GitOps détectent ce drift et peuvent soit alerter, soit restaurer automatiquement l''état souhaité. C''est un filet de sécurité indispensable pour garantir que les contrôles de sécurité ne sont pas contournés après le déploiement.
Profils de sécurité pour les conteneurs
Au-delà du scanning, les profils de sécurité Docker (seccomp, AppArmor) limitent les syscalls qu''un conteneur peut exécuter. C''est une couche de défense en profondeur qui complète le scanning de vulnérabilités. Notre article sur les profils de sécurité Docker détaille la configuration.
Par où commencer
Si vous partez de zéro, voici l''ordre de priorité recommandé :
- SCA (Snyk ou
trivy fs) : impact immédiat, détecte les dépendances vulnérables connues - Scanning d''images (Trivy) : sécurise les artefacts de déploiement
- SAST (SonarQube) : améliore la qualité du code et détecte les failles statiques
- IaC scanning (Trivy config, tfsec) : audite l''infrastructure déclarée
- DAST (OWASP ZAP) : teste l''application en conditions réelles (nécessite un environnement de staging)
Chez SHPV, nous accompagnons nos clients dans la mise en place de pipelines DevSecOps adaptés à leur stack technique, que ce soit sur des infrastructures hébergées ou dans le cloud. La sécurité n''est pas une option, c''est un prérequis.
