La sécurité vivait autrefois en bout de pipeline. Une revue dédiée, planifiée chaque trimestre, assurée par une équipe de deux personnes. Le résultat était prévisible : des montagnes de findings reportés, des développeurs qui avaient changé de contexte depuis trois sprints, et des correctifs introduisant des régressions parce que personne ne se souvenait pourquoi le code original avait été écrit ainsi.
Nous avons changé cela. Sur six mois, nous avons intégré les analyses SAST, DAST et SCA directement dans chaque merge request. Voici ce que nous avons appris.
Pourquoi le “Shift Left” va au-delà du slogan
Plus une vulnérabilité est détectée tôt, moins elle coûte à corriger. L’Institut System Sciences d’IBM estime le multiplicateur de coût à 100× entre le développement et la post-production. Ce chiffre semble abstrait jusqu’au jour où vous passez deux semaines à backporter un correctif sur trois environnements de production pendant que le SOC d’un client surveille vos logs.
Faire du shift-left signifie que les développeurs prennent en charge les findings de sécurité dans le même workflow où ils gèrent les échecs de tests. Pas de file de tickets séparée. Pas d’attente d’un goulot d’étranglement côté sécurité. Juste un pipeline rouge qui indique ce qui est cassé et pourquoi.
Les Trois Couches de Sécurité Pipeline
1. SAST - Analyse statique à chaque MR
Le SAST (Static Application Security Testing) analyse votre code source sans l’exécuter. Il détecte les injections SQL, les XSS, les références de chemins non sécurisées, les secrets codés en dur et d’autres classes de vulnérabilités connues.
Ce que nous utilisons :
- GitLab SAST (intégré) pour Python, JavaScript, Go et Java
- Semgrep pour les règles personnalisées spécifiques à notre domaine
- Gitleaks pour la détection de secrets dans les commits
La configuration de base dans .gitlab-ci.yml :
include: - template: Security/SAST.gitlab-ci.yml - template: Security/Secret-Detection.gitlab-ci.yml
sast: variables: SAST_EXCLUDED_PATHS: "tests/, vendor/" SAST_SEMGREP_METRICS: "false"Ce qui fonctionne vraiment : bloquer les MR sur les findings Critical et High uniquement. Permettre aux findings Medium et inférieurs de créer des issues sans bloquer. Commencer par bloquer tout et vous découragerez vos développeurs en une semaine.
2. DAST - Tests dynamiques sur staging
Le DAST (Dynamic Application Security Testing) s’exécute contre une application en fonctionnement. Il détecte les problèmes que l’analyse statique ne peut pas voir : en-têtes HTTP incorrects, comportements d’authentification, problèmes de gestion de session.
Notre configuration déploie automatiquement un environnement de review, exécute un scan DAST de base, puis publie les résultats dans la MR :
dast: stage: dast needs: ["deploy:review"] variables: DAST_WEBSITE: $REVIEW_APP_URL DAST_FULL_SCAN_ENABLED: "false" DAST_BROWSER_SCAN: "true" rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event"3. SCA - Gestion des dépendances
Le SCA (Software Composition Analysis) scanne vos dépendances tierces à la recherche de CVE connus. C’est souvent là que se cachent les vulnérabilités les plus exploitables - non pas dans votre code, mais dans les bibliothèques que vous utilisez.
Nos outils :
- GitLab Dependency Scanning pour la détection de CVE
- Trivy pour les images de conteneurs
- SBOM generation via CycloneDX pour la traçabilité des licences
dependency_scanning: variables: DS_EXCLUDED_PATHS: "tests/"
container_scanning: variables: CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA TRIVY_SEVERITY: "CRITICAL,HIGH"Résultats après 6 mois
- Réduction de 70 % des vulnérabilités critiques en production
- Temps de remédiation moyen passé de 3 semaines à 4 jours
- Temps de build augmenté de 8 minutes en moyenne (acceptable)
- Adoption par les développeurs : la résistance initiale s’est transformée en adhésion une fois que l’équipe a réalisé que les findings bloquants étaient actionnables et non du bruit
Ce que nous ferions différemment
Commencer plus tôt par la formation. Les premiers sprints ont vu beaucoup de “pourquoi mon MR est bloqué ?” Les développeurs ont besoin de comprendre ce que chaque outil détecte et pourquoi c’est important avant de voir apparaître leur premier finding critique.
Différencier les règles par équipe. Notre équipe mobile avait des faux positifs différents de l’équipe backend. Les règles globales créent du bruit. Les règles par composant créent de la confiance.
Investir dans un tableau de bord. Les résultats dans la MR sont bien pour le développeur, mais le RSSI a besoin d’une vue d’ensemble. Nous avons exporté les findings vers notre instance Grafana via l’API GitLab.
La sécurité dans le pipeline n’est pas un outil, c’est une culture. Les outils sont faciles. Convaincre une équipe qu’un pipeline rouge est un feedback, pas un obstacle - c’est le vrai travail.
