Détection de secrets avec Gitleaks¶

Objectifs pédagogiques¶

À la fin de ce TP, vous devez être capables de :

• distinguer un scan du contenu courant et un scan de l'historique Git
• comprendre l'intérêt d'un audit rétrospectif sur tout le dépôt
• configurer Gitleaks avec une règle personnalisée et une allowlist
• intégrer Gitleaks dans une pipeline CI/CD en mode audit
• bloquer localement l'introduction d'un secret avant le commit via un hook pre-commit

Consignes de sécurité¶

• Travaillez dans un dépôt dédié au TP
• N'utilisez jamais de vrais secrets
• Utilisez uniquement des valeurs factices mais réalistes dans leur forme
• Si vous poussez votre dépôt sur une forge Git, gardez-le privé si possible

Fil conducteur du TP¶

L'objectif est de mettre en place deux niveaux de défense complémentaires :

• Audit rétrospectif : analyser tout le dépôt et son historique pour retrouver des secrets déjà introduits
• Prévention : empêcher l'ajout d'un nouveau secret avant même qu'il ne parte dans l'historique Git

Atelier 1 : Audit local d'un dépôt Git¶

Contexte¶

Vous partez d'un dépôt de démonstration dans lequel des secrets ont été ajoutés par erreur. Même si un développeur supprime ensuite la ligne du fichier, le secret reste présent dans l'historique Git.

Travail demandé¶

1. Créez un dépôt local dédié au TP

Exemple de structure minimale :

mkdir gitleaks-lab
cd gitleaks-lab
git init
mkdir -p app samples reports

1. Introduisez volontairement trois cas différents :

2. un secret détectable par les règles par défaut de Gitleaks

3. un secret personnalisé que vous détecterez avec votre propre règle
4. un faux positif pédagogique que vous autoriserez ensuite

Exemple de jeu de données de départ :

cat > app/.env <<'EOF'
AWS_ACCESS_KEY_ID=AKIA1234567890ABCDEF
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
EOF

cat > app/config.txt <<'EOF'
MASTER_DEMO_TOKEN=master-demo-token-1234567890
EOF

cat > samples/example.env <<'EOF'
API_KEY=CHANGEME
EOF

1. Faites un premier commit avec au moins un secret dans l'historique

2. Supprimez ensuite une ou plusieurs valeurs sensibles du contenu courant puis faites un second commit

Le but est d'observer qu'un dépôt peut sembler propre dans l'arborescence actuelle tout en restant compromis dans son historique

1. Lancez un audit de l'historique Git complet

Commande attendue :

gitleaks git --report-format json --report-path reports/gitleaks-local.json .

Un code de retour non nul est attendu tant que des secrets sont détectés

1. Comparez avec un scan du contenu courant seulement

Commande possible :

gitleaks dir .

1. Ajoutez une configuration locale .gitleaks.toml qui :

2. étend la configuration par défaut

3. ajoute une règle personnalisée pour MASTER_DEMO_TOKEN
4. autorise le faux positif pédagogique placé dans samples/

Exemple minimal :

title = "TP Gitleaks"

[extend]
useDefault = true

[[rules]]
id = "master-demo-token"
description = "Token de démonstration du TP"
regex = '''MASTER_DEMO_TOKEN=[A-Za-z0-9_-]{20,}'''
tags = ["demo", "training", "token"]

[[allowlists]]
description = "Faux positifs pedagogiques du TP"
paths = ['''samples/.*''']

1. Relancez le scan complet avec votre configuration locale et vérifiez le résultat

Commande possible :

gitleaks git --config .gitleaks.toml --report-format json --report-path reports/gitleaks-configured.json .

Ce que vous devez observer¶

• gitleaks git retrouve les secrets présents dans l'historique
• gitleaks dir ne voit que l'état courant des fichiers
• le secret personnalisé n'est correctement détecté qu'après ajout de votre règle
• le faux positif pédagogique disparaît après ajout de l'allowlist

Questions de synthèse¶

• Pourquoi un dépôt peut-il être "propre" dans le working tree mais compromis dans Git
• Quelle différence faites-vous entre un faux positif, un vrai secret et un secret de test
• Dans quel cas utiliseriez-vous une allowlist plutôt qu'une suppression du secret ou une rotation d'identifiant

Critère de réussite de l'atelier 1¶

L'atelier est réussi si vous pouvez démontrer :

• un secret retrouvé dans l'historique
• un secret personnalisé détecté par votre règle
• un faux positif pédagogique ignoré proprement

Atelier 2 : Industrialisation en CI/CD et prévention avant commit¶

Contexte¶

Une détection locale ne suffit pas. En équipe, il faut :

• un contrôle centralisé dans la pipeline pour auditer tout le dépôt
• un contrôle local pour éviter qu'un nouveau secret soit commité

Partie A : Audit CI/CD sur tout le dépôt¶

Intégrez Gitleaks dans votre pipeline en mode audit.

Attendus :

• la pipeline doit analyser tout l'historique
• le job doit produire un rapport exploitable
• le job peut rester non bloquant pour un premier audit global

Point d'attention¶

Si vous utilisez GitLab CI/CD, pensez à forcer l'historique complet avec :

variables:
  GIT_DEPTH: "0"

Exemple minimal GitLab CI/CD¶

stages:
  - security

gitleaks_audit:
  stage: security
  image: ghcr.io/gitleaks/gitleaks:latest
  variables:
    GIT_DEPTH: "0"
  script:
    - gitleaks git --exit-code 0 --report-format sarif --report-path gitleaks-report.sarif .
  artifacts:
    when: always
    paths:
      - gitleaks-report.sarif

Travail demandé¶

1. Ajoutez un job d'audit Gitleaks dans votre pipeline
2. Générez un rapport json ou sarif
3. Conservez ce rapport comme artifact
4. Expliquez pourquoi vous démarrez ici en mode audit non bloquant avec --exit-code 0
5. Proposez le passage vers un mode bloquant lorsque le dépôt aura été assaini

Questions de synthèse¶

• Pourquoi GIT_DEPTH: "0" est-il indispensable pour ce type d'audit
• Pourquoi un audit global n'a pas le même objectif qu'un contrôle avant commit
• À partir de quel moment passeriez-vous le job en --exit-code 1

Partie B : Prévention locale via hook pre-commit¶

Ici, l'objectif est de bloquer un nouveau secret avant son entrée dans l'historique Git

Méthode recommandée : utiliser le framework pre-commit, qui installe le hook Git .git/hooks/pre-commit pour vous

Fichier .pre-commit-config.yaml¶

Exemple minimal :

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Mise en place¶

pre-commit autoupdate
pre-commit install

Option bonus si vous voulez aller plus bas niveau : écrire vous-mêmes un hook shell dans .git/hooks/pre-commit

Travail demandé¶

1. Installez le hook pre-commit
2. Créez un nouveau fichier contenant un secret factice
3. Ajoutez ce fichier à l'index Git
4. Tentez le commit et observez le blocage
5. Corrigez ou supprimez le secret puis relancez le commit

Questions de synthèse¶

• En quoi le hook local complète-t-il la pipeline CI/CD
• Quels sont les risques si l'équipe compte uniquement sur le hook local
• Pourquoi le mode prévention ne remplace-t-il pas l'audit rétrospectif

Critère de réussite de l'atelier 2¶

L'atelier est réussi si vous pouvez démontrer :

• une pipeline qui scanne l'historique complet du dépôt
• un rapport d'audit généré automatiquement
• un commit local refusé lorsqu'un secret factice est présent

Restitution attendue¶

Préparez une restitution courte avec :

• le dépôt utilisé pour le TP
• le fichier .gitleaks.toml
• le fichier de pipeline
• le fichier .pre-commit-config.yaml
• un exemple de rapport Gitleaks
• une démonstration ou une capture montrant le blocage du commit

Pour aller plus loin¶

• Ajouter une baseline si vous devez traiter un dépôt ancien déjà très exposé
• Tester un rapport sarif pour une intégration dans des outils de sécurité plus larges
• Comparer la détection sur un dépôt propre, un dépôt sale, puis un dépôt nettoyé