Scanners de sécurité GitLab CI : SAST, DAST, secrets et dépendances

Votre pipeline build, teste et déploie — mais une dépendance npm contient une CVE critique, un développeur a committé un token AWS, et votre image Docker embarque OpenSSL vulnérable. Vous ne le saurez qu’après l’incident. GitLab intègre cinq scanners de sécurité directement dans la CI/CD : ils analysent votre code, vos dépendances, vos images et vos secrets à chaque pipeline, avec un rapport de vulnérabilités exploitable par les développeurs.

Pipelines de branche vs pipelines de merge request

Par défaut, les scanners s’exécutent sur les pipelines de branche (à chaque push). Pour les exécuter spécifiquement sur les pipelines de merge request et afficher le diff de vulnérabilités, ajoutez la variable SAST_ENABLE_MR_PIPELINES: "true" (et son équivalent pour chaque scanner) ou utilisez les templates latest (Jobs/SAST.latest.gitlab-ci.yml).

En 30 secondes

• SAST = analyse statique du code source (bugs, failles, injections)
• Secret Detection = détecte les tokens, clés API et mots de passe committés
• Dependency Scanning = vulnérabilités connues (CVE) dans vos dépendances
• Container Scanning = vulnérabilités dans les images Docker que vous construisez
• DAST = teste votre application déployée comme un attaquant externe

Ce que vous allez apprendre

• Activer chaque scanner dans un pipeline GitLab CI avec les templates officiels
• Lire un rapport de vulnérabilités dans une merge request et prioriser les corrections
• Configurer Secret Detection pour détecter les tokens committés avant le merge
• Scanner vos images Docker construites dans le même pipeline
• Configurer les mécanismes de gouvernance pour réagir aux vulnérabilités détectées
• Choisir entre Auto DevOps et configuration manuelle

Dans quel contexte ?

Les scanners de sécurité GitLab répondent à un besoin précis : détecter les vulnérabilités au plus tôt dans le cycle de développement, idéalement dès la merge request, avant que le code n’atteigne la branche principale.

Sans ces scanners, les équipes découvrent les problèmes de sécurité :

• En production, quand un scanner externe (Trivy, Snyk) détecte une CVE critique sur une image déployée
• Lors d’un audit, quand on découvre que des secrets traînent dans l’historique Git depuis des mois
• Après un incident, quand un attaquant exploite une dépendance vulnérable connue depuis longtemps

En pratique quotidienne, les scanners servent à :

• Attraper les secrets (tokens AWS, clés SSH, mots de passe) dans les commits avant qu’ils ne soient mergés dans la branche principale
• Vérifier les dépendances à chaque mise à jour de package-lock.json, go.sum ou requirements.txt
• Valider les images Docker avant de les pousser dans le Container Registry
• Tester la surface d’attaque d’une application déployée en review app
• Produire des rapports pour les audits de conformité (lien avec Audit & conformité)

Prérequis

• Un projet GitLab avec un pipeline fonctionnel (voir Premier pipeline)
• Comprendre les templates et includes (les scanners utilisent include: template:)
• Pour le Container Scanning : un job qui construit une image Docker (voir Registries)
• Pour le DAST : une application déployée accessible (review app ou environnement de staging)

Disponibilité par tier GitLab

Exécution du scan (rapport JSON téléchargeable) :

Scanner	Free	Premium	Ultimate
SAST	✅	✅	✅
Secret Detection	✅	✅	✅
Container Scanning	✅	✅	✅
Dependency Scanning	❌	❌	✅
DAST	❌	❌	✅

Glissez pour voir

Fonctionnalités avancées (Ultimate uniquement) :

• Widget de sécurité dans la merge request (nouvelles vulnérabilités détectées)
• Vulnerability Report centralisé et gestion des vulnérabilités
• Merge request approval policies (blocage sur findings)
• Security Dashboard

Sur GitLab.com Free, vous pouvez exécuter SAST, Secret Detection et Container Scanning et télécharger les rapports JSON. La visualisation dans les MR et la gestion des vulnérabilités nécessitent Ultimate.

Les 5 scanners expliqués

Vue d’ensemble

Code source ──► SAST ──────────► Vulnérabilités dans le code
     │
     ├──► Secret Detection ──► Tokens/clés détectés
     │
     ├──► Dependency Scanning ► CVE dans les dépendances
     │
     └──► Container Scanning ─► CVE dans l'image Docker
                                       │
Application déployée ──► DAST ─────────► Vulnérabilités web (XSS, injection, etc.)

SAST — Static Application Security Testing

Le SAST analyse votre code source sans l’exécuter. Il détecte les failles de programmation : injections SQL, XSS, utilisation de fonctions dangereuses, mauvaise gestion des entrées utilisateur.

GitLab détecte automatiquement les langages et active les analyseurs correspondants. Selon le projet, plusieurs analyseurs peuvent s’exécuter en parallèle : Semgrep (Python, JS, Go, Java…), SpotBugs (Java, Kotlin), Sobelow (Elixir), PMD (Apex), Kubesec (manifests Kubernetes) et GitLab Advanced SAST (Ultimate — analyse inter-procédurale).

include:
  - template: Jobs/SAST.gitlab-ci.yml

C’est tout. GitLab crée automatiquement un ou plusieurs jobs (ex : semgrep-sast, spotbugs-sast) dans le stage test qui :

1. Détectent les langages du projet
2. Exécutent les analyseurs appropriés
3. Produisent un rapport gl-sast-report.json (format GitLab Security Report, pas SARIF)
4. Affichent les résultats dans la merge request (Ultimate)

Personnalisation courante :

include:
  - template: Jobs/SAST.gitlab-ci.yml

variables:
  SAST_EXCLUDED_PATHS: "spec,test,tests,tmp,vendor,node_modules"
  SEARCH_MAX_DEPTH: 4

Secret Detection

Le scanner de Secret Detection parcourt les commits pour trouver des secrets (tokens, clés API, mots de passe, certificats) qui n’auraient pas dû être committés.

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

Il détecte entre autres :

Type de secret	Exemple de pattern
Clés AWS	AKIA[0-9A-Z]{16}
Tokens GitLab	glpat-[0-9a-zA-Z_-]{20}
Clés privées SSH/RSA	-----BEGIN RSA PRIVATE KEY-----
Tokens GitHub	ghp_[0-9a-zA-Z]{36}
Mots de passe en clair	Variables contenant password, secret, token

Glissez pour voir

Un secret committé ne peut pas être « décommitté »

Même si vous supprimez le fichier contenant le secret, il reste dans l’historique Git. La seule solution fiable est de révoquer le secret et d’en générer un nouveau. Le Secret Detection pipeline vous alerte après le push, avant le merge pour limiter l’exposition. Pour bloquer le push avant qu’il n’atteigne le serveur, GitLab propose Secret Push Protection (feature séparée, à activer dans Settings > Security).

Scan initial de l’historique (à exécuter une seule fois) :

Après avoir activé Secret Detection, lancez un pipeline manuellement avec la variable SECRET_DETECTION_HISTORIC_SCAN: "true" pour scanner tout l’historique Git. C’est un scan one-shot — ne le laissez pas dans votre configuration permanente, car il rallonge considérablement chaque pipeline.

# Pipeline manuel unique pour le scan historique
# Build > Pipelines > New pipeline > Add variable:
#   SECRET_DETECTION_HISTORIC_SCAN = true

Configuration standard (quotidienne) :

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

variables:
  SECRET_DETECTION_EXCLUDED_PATHS: "tests/"

Dependency Scanning

Le Dependency Scanning analyse vos fichiers de verrouillage (package-lock.json, go.sum, Gemfile.lock, requirements.txt) pour identifier les dépendances avec des CVE connues (base NVD et GitLab Advisory Database).

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

Il produit un rapport listant chaque dépendance vulnérable avec :

• L’identifiant CVE
• La sévérité (Critical, High, Medium, Low)
• La version corrigée (quand elle existe)
• Le lien vers l’advisory

Personnalisation :

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

variables:
  DS_EXCLUDED_PATHS: "vendor/"

Container Scanning

Le Container Scanning analyse l’image Docker que votre pipeline vient de construire pour trouver les vulnérabilités dans les packages système (apt, apk, rpm) et les bibliothèques embarquées.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

Lien avec le guide Registries

Le Container Scanning s’intègre naturellement avec le Container Registry : vous construisez l’image dans un job build, vous la poussez dans le registre, puis le scanner l’analyse dans un job suivant en utilisant la même référence $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA.

DAST — Dynamic Application Security Testing

Le DAST teste une application déployée et accessible en simulant des attaques réelles : injections SQL, XSS, CSRF, headers de sécurité manquants, etc.

include:
  - template: Security/DAST.gitlab-ci.yml

variables:
  DAST_TARGET_URL: "https://staging.mon-app.com"

Stage dast obligatoire

Le template DAST place le job dans le stage dast. Vous devez ajouter ce stage à votre liste stages:, sinon le job ne s’exécutera pas.

Le DAST est le scanner le plus lourd : il lance un navigateur headless et explore l’application. Il est généralement exécuté sur un environnement de staging ou une review app, pas en production.

Personnalisation :

include:
  - template: Security/DAST.gitlab-ci.yml

variables:
  DAST_TARGET_URL: "https://$CI_ENVIRONMENT_SLUG.review.mon-app.com"
  DAST_FULL_SCAN_ENABLED: "false"  # Scan rapide par défaut
  DAST_BROWSER_SCAN: "true"        # Scan basé navigateur (recommandé)

Pipeline de sécurité complet

Voici un pipeline qui combine les 5 scanners avec les étapes de build et test :

stages:
  - build
  - test
  - deploy
  - dast  # Stage requis par le template DAST

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/Container-Scanning.gitlab-ci.yml
  - template: Security/DAST.gitlab-ci.yml

variables:
  CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  DAST_TARGET_URL: "https://$CI_ENVIRONMENT_SLUG.staging.mon-app.com"

build-image:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"

test:
  stage: test
  image: node:22-alpine
  script:
    - npm ci
    - npm test

deploy-staging:
  stage: deploy
  script:
    - deploy-to-staging.sh
  environment:
    name: staging/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.staging.mon-app.com
  rules:
    - if: $CI_MERGE_REQUEST_IID

Ordre d'exécution

Les templates GitLab placent automatiquement les scanners dans le stage test. Si vous avez besoin que le Container Scanning s’exécute après le build, soit vous le mettez dans un stage séparé, soit vous utilisez needs: pour définir l’ordre.

Lire les rapports de vulnérabilités

Dans la merge request

Quand les scanners s’exécutent sur une MR, GitLab affiche un widget de sécurité résumant :

• Le nombre de nouvelles vulnérabilités introduites par la MR
• Le nombre de vulnérabilités corrigées
• La répartition par sévérité (Critical, High, Medium, Low)

Chaque vulnérabilité est cliquable et affiche :

• La description de la faille
• Le fichier et la ligne concernés (SAST) ou la dépendance (Dependency Scanning)
• La sévérité et le score CVSS
• La solution recommandée (mise à jour, contournement)
• L’identifiant CVE / CWE

Dans le Security Dashboard

Le Security Dashboard (Security & Compliance > Vulnerability Report) centralise toutes les vulnérabilités détectées sur la branche par défaut. Il permet de :

• Filtrer par scanner, sévérité, statut
• Marquer une vulnérabilité comme “confirmed”, “dismissed” ou “resolved”
• Créer un issue GitLab directement depuis une vulnérabilité
• Suivre l’évolution dans le temps

Premiers mécanismes de gouvernance

Deux mécanismes complémentaires permettent de réagir aux résultats des scanners :

1. allow_failure: false — détecter les pannes de scanner

Par défaut, les scanners utilisent allow_failure: true : si le scanner plante (timeout, erreur réseau, image indisponible), le pipeline continue. En passant à false, un échec du scanner lui-même bloque le pipeline — mais les vulnérabilités détectées, elles, ne bloquent rien :

semgrep-sast:
  allow_failure: false  # Bloque si le scanner plante, PAS si des findings existent

allow_failure ne bloque pas sur les findings

allow_failure: false garantit que le scanner s’exécute correctement, pas qu’il ne trouve rien. Un scan qui détecte 50 vulnérabilités critiques reste un scan réussi (exit code 0). Pour bloquer sur les résultats, utilisez les merge request approval policies ci-dessous.

2. Merge request approval policies — bloquer sur les findings (Ultimate)

Pour empêcher le merge quand des vulnérabilités critiques sont détectées, configurez une merge request approval policy dans un projet de politique de sécurité :

1. Créez un Security Policy Project (Security & Compliance > Policies > New policy project)

2. Créez une Merge request approval policy avec une règle scan_finding :

   • Sévérité minimale : critical ou high
   • Scanners concernés : SAST, Dependency Scanning, Container Scanning, Secret Detection
   • Approbateurs requis : membres de l’équipe sécurité

3. Liez le projet de politique à vos projets (Settings > Security & Compliance > Security policy project)

Ultimate requis

Les merge request approval policies nécessitent GitLab Ultimate. Sur les tiers Free et Premium, vous pouvez utiliser allow_failure: false et des approval rules classiques manuelles, mais sans blocage automatique sur les findings.

Auto DevOps vs configuration manuelle

GitLab propose Auto DevOps, qui active automatiquement tous les scanners sans configuration. C’est tentant, mais voici quand choisir chaque approche :

Critère	Auto DevOps	Configuration manuelle
Temps de mise en place	Instantané	15 min
Contrôle	Limité	Total
Scanners activés	Tous	Au choix
Personnalisation	Via variables	Via YAML complet
Recommandé pour	Prototypage, petits projets	Production, conformité

Glissez pour voir

Pour activer Auto DevOps : Settings > CI/CD > Auto DevOps > Enable.

Pour la plupart des équipes en production, la configuration manuelle via include: template: est préférable car elle donne un contrôle explicite sur ce qui s’exécute.

Dépannage

Symptôme	Cause probable	Solution
Scanner non exécuté	Template pas inclus ou stage manquant	Vérifiez include: et que le stage existe
SAST: 0 findings sur un projet avec du code	Langage non détecté	Ajoutez SAST_DEFAULT_ANALYZERS explicitement
Container Scanning échoue	Image non trouvée	Vérifiez CS_IMAGE et que le job build a réussi
Secret Detection : faux positifs	Pattern trop large	Ajoutez un fichier .gitlab-secret-detection.toml pour exclure
DAST timeout	Application non accessible depuis le runner	Vérifiez l’URL et le réseau du runner
Widget sécurité absent dans la MR	Licence insuffisante ou rapports manquants	Vérifiez le tier GitLab et les artifacts des jobs
Dependency Scanning: 0 findings	Fichier de verrouillage absent	Générez package-lock.json ou go.sum avant

Glissez pour voir

À retenir

• GitLab intègre 5 scanners de sécurité activables via include: template: — pas besoin d’outils externes
• SAST, Secret Detection et Container Scanning sont disponibles sur tous les tiers (y compris Free) — Dependency Scanning et DAST nécessitent Ultimate
• Les résultats apparaissent directement dans la merge request (widget Ultimate) — sur Free, les rapports JSON sont téléchargeables
• Le Container Scanning analyse les images Docker construites dans le même pipeline
• Le DAST teste l’application déployée — il nécessite un environnement accessible et le stage dast
• allow_failure: false détecte les pannes de scanner — pour bloquer sur les findings, configurez des merge request approval policies (Ultimate)
• Auto DevOps active tout automatiquement, mais la configuration manuelle offre plus de contrôle
• Ces scanners complètent notre Volet 3 — Sécurité qui couvre la protection des pipelines eux-mêmes

Prochaines étapes

Registries GitLab Construisez et stockez vos images Docker dans le Container Registry

Attaques sur les pipelines Les 7 vecteurs d'attaque CI/CD que vos scanners ne détectent pas

Supply chain CI SBOM, cosign et attestations SLSA pour prouver l'intégrité de vos builds

Audit & conformité Traçabilité et compliance pipelines pour exploiter les rapports des scanners

Industrialisation Templates réutilisables pour mutualiser la configuration des scanners

×

📖 Voir la documentation →