Sécurité dans GitLab : comprendre SAST et DAST

Objectif pédagogique

À la fin de ce cours, vous serez capable de :

Comprendre la différence entre SAST et DAST
Identifier ce que GitLab analyse dans chacun des cas
Savoir où les intégrer dans votre pipeline CI/CD
Réaliser un TP avec un projet simple

1. Pourquoi intégrer la sécurité dans la CI/CD ?

Mieux vaut réparer avant que ça casse, plutôt que de patcher après l’attaque !

En DevOps, on parle de DevSecOps :

c’est le DevOps avec la sécurité intégrée à chaque étape

L’objectif est de détecter les vulnérabilités le plus tôt possible dans le cycle de développement. Idéalement avant même que l’application soit déployée.

GitLab intègre nativement des outils de sécurité automatisés :

SAST : Analyse du code source.
DAST : Test du comportement de l’application en fonctionnement.

2. SAST (Static Application Security Testing)

Définition

SAST analyse le code source sans exécuter l’application.

Il s’agit d’une analyse statique, comme un correcteur orthographique pour le code.

Métaphore pour le rôle du SAST

Imaginons que vous écriviez une recette de cuisine (votre code) :

Le SAST relit votre recette avant la cuisson pour vous indiquer :

Que vous avez oublié un ingrédient indispensable.
Que vous avez oublié de mettre la bonne température.

Il ne goûte pas le plat, mais vérifie la logique et les ingrédients.

Concrètement dans GitLab

GitLab fournit un template prédéfini appelé SAST.gitlab-ci.yml :

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

Ainsi, lors de l’exécution de votre pipeline, GitLab exécute une série de scanners selon le langage utilisé :

Python : Bandit
Ruby : Brakeman
Java/Android : Find Security Bugs, Spotbugs pour Java
JavaScript : eslint, nodejsscan
PHP : phpcs-security-audit
…

Remarque : Il arrive qu’il mette des alertes pour des vulnérabilités théoriques inexploitables étant donné que l’analyse se fait sur du code statique. Il faut revoir et affiner les règles au fil du temps afin de réduire le bruit, de refléter les modifications de la base de code et de tenir compte de l’évolution des schémas d’attaque. SAST a une compréhension limitée du contexte de l’impact.

Exemples de failles détectées

Injection SQL : “SELECT * FROM users WHERE id=” + user_input
Utilisation d’API non sécurisée : http:// au lieu de https://
Secrets dans le code : mot de passe ou clé API en clair !
Absence de validation des entrées : données utilisateur non filtrées

Paramètres de Configuration SAST

Voici les principaux paramètres configurables pour les tests SAST avec GitLab.

Paramètres Généraux

Ces paramètres permettent de configurer le comportement général du scan SAST.

Paramètre	Description	Exemple de Valeur
`SAST_DEFAULT_ANALYZERS`	Liste des analyseurs SAST à utiliser par défaut.	`semgrep,flawfinder`
`SAST_EXCLUDED_PATHS`	Chemins à exclure de l’analyse SAST.	`spec/,test/`
`SAST_DEFAULT_BRANCH`	Branche par défaut pour l’analyse.	`main`
`SAST_DISABLED`	Désactive complètement l’analyse SAST.	`false`

Paramètres Avancés

Ces paramètres permettent d’affiner le comportement du scan SAST, notamment pour gérer les performances, les exclusions, ou les analyseurs spécifiques.

Paramètre	Description	Exemple de Valeur
`SAST_ANALYZER_IMAGE_TAG`	Tag de l’image Docker pour l’analyseur SAST.	`4`
`SAST_BANDIT_LEVEL`	Niveau de sévérité pour Bandit (Python).	`high`
`SAST_BANDIT_CONFIDENCE`	Niveau de confiance pour Bandit.	`medium`
`SAST_SEMGREP_RULES`	Fichier de règles personnalisées pour Semgrep.	`.semgrep/rules.yaml`
`SAST_FLAWFINDER_LEVEL`	Niveau de sévérité pour Flawfinder (C/C++).	`3`
`SAST_SOOS_SCAN_MODE`	Mode de scan pour SOOS (si utilisé).	`full`
`SAST_PHP_SECURITY_AUDIT_LEVEL`	Niveau d’audit pour PHP Security Audit.	`3`

Paramètres pour les Langages Spécifiques

Ces paramètres permettent de configurer des analyseurs pour des langages ou frameworks spécifiques.

Paramètre	Description	Exemple de Valeur
`SAST_GOSEC_LEVEL`	Niveau de sévérité pour Gosec (Go).	`high`
`SAST_ESLINT_LEVEL`	Niveau de sévérité pour ESLint (JavaScript).	`error`
`SAST_RUBOCOP_LEVEL`	Niveau de sévérité pour RuboCop (Ruby).	`warning`
`SAST_SPOTBUGS_LEVEL`	Niveau de sévérité pour SpotBugs (Java).	`medium`
`SAST_KUBESCAPE_SCAN`	Active l’analyse de sécurité pour Kubernetes.	`true`

Paramètres de Performance et Limites

Ces paramètres permettent de contrôler la charge et les limites du scan SAST.

Paramètre	Description	Exemple de Valeur
`SAST_MAX_FILE_SIZE`	Taille maximale des fichiers à analyser (en Mo).	`10`
`SAST_TIMEOUT`	Délai maximal pour l’analyse (en secondes).	`3600`
`SAST_MEMORY_LIMIT`	Limite de mémoire pour l’analyse (en Mo).	`4096`

Exemple de Configuration YAML

Voici un exemple de configuration YAML pour un scan SAST dans un pipeline GitLab :

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

variables:
  SAST_DEFAULT_ANALYZERS: "semgrep,bandit,flawfinder"
  SAST_EXCLUDED_PATHS: "spec/,test/,vendor/"
  SAST_BANDIT_LEVEL: "high"
  SAST_SEMGREP_RULES: ".semgrep/rules.yaml"
  SAST_MAX_FILE_SIZE: "10"
  SAST_TIMEOUT: "3600"

Analyseurs SAST Disponibles (certains sont déjà mentionnés plus haut dans le cours)

Voici une liste des analyseurs SAST couramment utilisés selon le langage :

Analyseur	Langage/Framework	Description
Bandit	Python	Détecte les vulnérabilités courantes en Python.
Semgrep	Multi-langage	Analyseur générique basé sur des règles.
Flawfinder	C/C++	Détecte les vulnérabilités dans le code C/C++.
Gosec	Go	Analyseur de sécurité pour Go.
ESLint	JavaScript/TypeScript	Détecte les problèmes de sécurité et de style.
RuboCop	Ruby	Analyseur de style et de sécurité pour Ruby.
SpotBugs	Java	Détecte les bugs et vulnérabilités en Java.
Kubeescape	Kubernetes	Analyse les fichiers YAML Kubernetes.

Remarques Importantes

Documentation Officielle : Pour une liste exhaustive et à jour, consultez la documentation officielle de GitLab SAST.
Personnalisation : Vous pouvez ajouter des règles personnalisées pour chaque analyseur (par exemple, .semgrep/rules.yaml pour Semgrep).
Sécurité : Évitez de commiter des fichiers de configuration contenant des informations sensibles.
Performance : Certains analyseurs peuvent être gourmands en ressources. Ajustez les limites (SAST_TIMEOUT, SAST_MEMORY_LIMIT) selon vos besoins.

Exemple de Job basique de type SAST

stages:
  - test
  - sast

sast:
  stage: sast
  include:
    - template: Security/SAST.gitlab-ci.yml
  tags:
    - docker

Donc ici, GitLab analyse le code et génère un rapport de sécurité qui est disponible dans l’onglet Security --> Vulnerabilities du projet.

3. DAST (Dynamic Application Security Testing)

Définition

DAST teste l’application en fonctionnement (comme un pirate bienveillant).

Il s’agit d’une analyse dynamique, réalisée après le déploiement. GitLab lance un scanner web automatisé qui explore le site et cherche des failles connues (voir le cours sur OWASP ZAP).

Métaphore pour le rôle du DAST

Avant le travail du DAST, le SAST a vérifié les plans de la maison (équivalent du code dans notre exemple métaphorique)

Le DAST, c’est le testeur de porte de votre appartement ou de votre maison :

Il teste si les portes et fenêtres sont bien verrouillées une fois la maison construite.
Il essaie d’entrer dans l’appartement comme le ferait un cambrioleur (c’est l’équivalent d’un attaquant pour notre application web)

Concrètement dans GitLab

Par chance, GitLab propose un template dédié !

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

dast:
  variables:
    DAST_WEBSITE: "https://waoufwaouf.fr"

En réalité, GitLab déploie un scanner basé sur OWASP ZAP (Zed Attack Proxy) qui va tester les formulaires, les cookies, les liens et les redirections.

Exemples de failles détectées

Injection SQL ou XSS : entrée utilisateur non filtrée dans un champ web
Session non sécurisée : cookies non chiffrés
Mauvaises redirections : URL manipulables
En-têtes HTTP manquant : Absence de X-Frame-Options, CSP,…

Paramètres de configuration

Voici les principaux paramètres configurables pour les tests DAST avec GitLab DAST.

Paramètres Généraux

Ces paramètres permettent de configurer le comportement général du scan DAST.

Paramètre	Description	Exemple de Valeur
`DAST_WEBSITE`	URL de l’application à scanner.	`http://localhost:8080`
`DAST_FULL_SCAN_ENABLED`	Active un scan complet (inclut plus de tests).	`true`
`DAST_API_SPECIFICATION`	Fichier OpenAPI/Swagger pour tester les APIs.	`openapi.json`
`DAST_AUTH_URL`	URL pour l’authentification.	`http://localhost:8080/login`
`DAST_USERNAME`	Nom d’utilisateur pour l’authentification.	`admin`
`DAST_PASSWORD`	Mot de passe pour l’authentification.	`s3cr3t`
`DAST_AUTH_EXCLUDE_URLS`	URLs à exclure des tests d’authentification.	`http://localhost:8080/logout`

Paramètres Avancés

Ces paramètres permettent d’affiner le comportement du scan, notamment pour gérer les performances, les exclusions, ou les tests spécifiques.

Paramètre	Description	Exemple de Valeur
`DAST_BROWSER_SCAN`	Active le scan via un navigateur.	`true`
`DAST_ZAP_CLI_OPTIONS`	Options supplémentaires pour OWASP ZAP.	`-a -j`
`DAST_TARGET_AUDIENCE`	Public cible pour le scan.	`internal`
`DAST_EXCLUDED_URLS`	URLs à exclure du scan.	`http://localhost:8080/admin`
`DAST_SCAN_PROFILE`	Profil de scan (rapide, complet, API).	`Quick Scan`
`DAST_ZAP_USE_AJAX_SPIDER`	Active l’araignée AJAX pour les applications dynamiques.	`true`
`DAST_ZAP_AUTH_HEADER`	En-tête HTTP pour l’authentification.	`Authorization: Bearer token`

Paramètres pour les Tests Spécifiques

Ces paramètres permettent de configurer des tests spécifiques, comme les injections SQL, les XSS, etc.

Paramètre	Description	Exemple de Valeur
`DAST_SQL_INJECTION`	Active les tests d’injection SQL.	`true`
`DAST_XSS`	Active les tests de Cross-Site Scripting (XSS).	`true`
`DAST_CSRF`	Active les tests de Cross-Site Request Forgery (CSRF).	`true`
`DAST_SECURITY_HEADERS`	Vérifie la présence des en-têtes de sécurité.	`true`

Paramètres de Performance et Limites

Ces paramètres permettent de contrôler la charge et les limites du scan.

Paramètre	Description	Exemple de Valeur
`DAST_ZAP_MAX_SCAN_DURATION`	Durée maximale du scan (en minutes).	`60`
`DAST_ZAP_THREADS_PER_HOST`	Nombre de threads par hôte.	`5`
`DAST_ZAP_SPIDER_MAX_DEPTH`	Profondeur maximale de l’araignée.	`10`

Exemple d’une configuration YAML

Voici un exemple de configuration YAML pour un scan DAST dans un pipeline GitLab :

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

variables:
  DAST_WEBSITE: "http://localhost:8080"
  DAST_FULL_SCAN_ENABLED: "true"
  DAST_API_SPECIFICATION: "openapi.json"
  DAST_AUTH_URL: "http://localhost:8080/login"
  DAST_USERNAME: "admin"
  DAST_PASSWORD: "s3cr3t"
  DAST_BROWSER_SCAN: "true"
  DAST_ZAP_CLI_OPTIONS: "-a -j"
  DAST_EXCLUDED_URLS: "http://localhost:8080/admin"
  DAST_SQL_INJECTION: "true"
  DAST_XSS: "true"
  DAST_ZAP_MAX_SCAN_DURATION: "60"

Remarques Importantes

Documentation Officielle : Pour une liste exhaustive et à jour, voir la documentation officielle de GitLab DAST.
Compatibilité : Certains paramètres dépendent de la version de GitLab ou de l’outil DAST utilisé (comme OWASP ZAP).
Sécurité : Ne commitez jamais de mots de passe ou de tokens en clair dans vos fichiers de configuration. Utilisez des variables d’environnement sécurisées !

Exemple de Job de type DAST simple

stages:
  - build
  - test
  - dast

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

variables:
  DAST_WEBSITE: "http://localhost:8080"
  DAST_FULL_SCAN_ENABLED: "true"

Donc, le scanner OWASP ZAP s’exécute et un rapport DAST s’affiche dans l’onglet Security > Vulnerabilities, comme pour le SAST.

Tableau de comparaison des 2 types de tests de sécurité

Critère	SAST	DAST
Type d’analyse	Statique	Dynamique
Moment d’exécution	Avant le déploiement	Après le déploiement
Cible	Code source	Application en ligne
Objectif	Trouver les erreurs logiques et vulnérabilités internes	Tester la résistance extérieure
Exemple d’outil	Bandit, SpotBugs, ESLint, Find Security Bugs	OWASP ZAP, Burp Suite
Analogie	Relecture des plans d’une maison	Test de résistance des serrures

4. Mise en pratique

Objectif : Configurer un pipeline CI/CD qui analyse la sécurité d’une petite application web basique.

Créez un projet GitLab securite-demo
Ajoutez un simple serveur Node.js

const express = require('express');
const app = express();
app.get('/', (req, res) => res.send('Bonjour depuis GitLab Security !'));
app.listen(8080, () => console.log('Serveur démarré sur le port 8080'));

Ajouter le fichier `.gitlab-ci.yml`

stages:
  - test
  - sast
  - dast

# SAST : analyse du code source
include:
  - template: Security/SAST.gitlab-ci.yml

# DAST : test de sécurité de l'application déployée
dast:
  stage: dast
  image: docker:stable
  variables:
    DAST_WEBSITE: "http://localhost:8080"
    DAST_FULL_SCAN_ENABLED: "true"
  script:
    - echo "Analyse dynamique en cours..."
  tags:
    - docker

Résultat attendu

Normalement, GitLab exécute automatiquement les 2 jobs :

SAST : Détecte des failles dans le code s’il y en a.
DAST : Scanne l’application comme un client (navigateur attaquant)
Les résultats doivent apparaitre dans Security ==> Vulnerabilities

Conclusion

On peut dire de SAST protège le code source et que DAST protège les internautes ou utilisateur.trices.

Tableau récapitulatif

Terme	Signification	Moment d’usage	Analogie
SAST	Static Application Security Testing	Avant exécution	Vérifie la recette de cuisine
DAST	Dynamic Application Security Testing	Après exécution	Goûte le plat et cherche les failles

Si vous voulez aller plus loin en ce qui concerne la sécurité, vous pouvez ajouter d’autres outils comme ceux-ci :

Dependency Scanning qui vérifie les bibliothèques tierces.
Secret Detection qui repère les clés API et mots de passe.
Activer Container Scanning qui vérifie vos images Docker.

Vous avez compris que GitLab ne se limite par à l’automatisation du code, c’est un écosystème de sécurité proactive.

Auteur : Philippe Bouget

Sécurité dans GitLab : comprendre SAST et DAST

Objectif pédagogique

1. Pourquoi intégrer la sécurité dans la CI/CD ?

2. SAST (Static Application Security Testing)

Définition

Métaphore pour le rôle du SAST

Concrètement dans GitLab

Exemples de failles détectées

Paramètres de Configuration SAST

Paramètres Généraux

Paramètres Avancés

Paramètres pour les Langages Spécifiques

Paramètres de Performance et Limites

Exemple de Configuration YAML

Analyseurs SAST Disponibles (certains sont déjà mentionnés plus haut dans le cours)

Remarques Importantes

Exemple de Job basique de type SAST

3. DAST (Dynamic Application Security Testing)

Définition

Métaphore pour le rôle du DAST

Concrètement dans GitLab

Exemples de failles détectées

Paramètres de configuration

Paramètres Généraux

Paramètres Avancés

Paramètres pour les Tests Spécifiques

Paramètres de Performance et Limites

Exemple d’une configuration YAML

Remarques Importantes

Exemple de Job de type DAST simple

Tableau de comparaison des 2 types de tests de sécurité

4. Mise en pratique

Ajouter le fichier .gitlab-ci.yml

Résultat attendu

Conclusion

Ajouter le fichier `.gitlab-ci.yml`