Secrets Scanning : détecter les secrets exposés dans le code

Un couple d’AK/SK committé par erreur. Une clé API dans un fichier .env.example. Un token GitLab dans les logs de CI. Ces scénarios ne sont pas hypothétiques : 85% des fuites de secrets passent par Git selon GitGuardian.

Le secrets scanning n’est pas une option. C’est une ligne de défense obligatoire dans toute usine logicielle.

Pourquoi le secrets scanning est non-négociable

Scénarios réalistes de fuite

Les secrets fuient par des chemins prévisibles :

Vecteur	Exemple	Détection possible
Commit direct	password = "admin123" dans le code	✅ Scanning repo
Fichier exemple	.env.example avec vraies valeurs	✅ Scanning repo
Historique Git	Secret supprimé mais présent dans l’historique	✅ Scan historique
Logs CI/CD	Token affiché dans les logs de build	⚠️ Masquage variables
Artefacts	Credentials dans un binaire ou config packagée	⚠️ Scan artefacts
MR/PR	Secret dans une diff avant merge	✅ Scan MR

Objectif : réduire le temps d’exposition

L’enjeu n’est pas d’atteindre le “zéro secret exposé” (utopique), mais de :

1. Détecter au plus tôt — Avant le merge, idéalement avant le push
2. Standardiser la réponse — Procédure claire de rotation/révocation
3. Tracer les incidents — Pour améliorer la prévention

Ce qu’on appelle “secret” (et ce qu’on n’appelle pas secret)

Typologie des secrets

Tokens API

GitHub PAT, GitLab tokens, tokens cloud (AWS, GCP, Azure)

Credentials

Mots de passe, strings de connexion DB, credentials SMTP

Clés cryptographiques

Clés privées SSH/TLS, clés de chiffrement, JWT secrets

Webhooks & URLs

URLs avec tokens intégrés, webhooks Slack/Discord

Cas limites : le “bruit”

Tous les patterns détectés ne sont pas des secrets :

• UUIDs — Identifiants, pas des secrets
• Hashes — SHA256 d’un fichier, pas un mot de passe
• Fixtures de test — Fausses clés pour les tests unitaires
• Documentation — Exemples avec xxx ou REPLACE_ME

Une stratégie efficace gère ce bruit au lieu de le subir.

Où placer les contrôles (défense en profondeur)

La détection des secrets doit intervenir à plusieurs niveaux :

1. Avant le push (client-side)

   Pre-commit hooks avec Gitleaks. Bloque le commit avant qu’il n’atteigne le serveur.

   ✅ Feedback immédiat pour le développeur ⚠️ Contournable (hooks désactivables)

2. Dans la Merge Request

   Scan automatique sur chaque MR. Feedback visible dans la diff.

   ✅ Point de contrôle centralisé ✅ Impossible à contourner ⚠️ Détection “tardive” (après commit)

3. Sur la branche par défaut

   Scan post-merge comme filet de sécurité.

   ✅ Couverture complète ⚠️ Réaction après le fait

Recommandation : combiner les trois niveaux. Le pre-commit accélère le feedback, la MR garantit le contrôle, le scan de branche assure la couverture.

Options d’implémentation

Comparatif des outils

Critère	GitLab Secret Detection	Gitleaks	TruffleHog
Intégration	Native GitLab	CI générique	CI générique
Méthode	Règles regex	Règles regex	Entropie + regex + validation
Historique	⚠️ Limité	✅ Complet	✅ Complet
Validation	❌	❌	✅ (certains providers)
Coût	Inclus Ultimate	Gratuit	Gratuit / Enterprise
Bruit	Moyen	Configurable	Faible (validation)

GitLab Secret Detection

Solution intégrée pour les utilisateurs GitLab Ultimate :

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

• Génère un rapport SAST consultable dans la MR
• Règles maintenues par GitLab
• Limité à la branche courante (pas l’historique complet)

→ Documentation GitLab Secret Detection ↗

Gitleaks

Outil open source, rapide, configurable :

secrets-scan:
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --verbose --redact
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Forces :

• Configuration fine via .gitleaks.toml
• Scan de l’historique complet (--log-opts="--all")
• Exit codes exploitables pour le gating

→ Guide Gitleaks

TruffleHog

Détection avancée avec validation des secrets :

secrets-scan:
  image: trufflesecurity/trufflehog:latest
  script:
    - trufflehog git file://. --only-verified --fail

Forces :

• Vérifie si le secret est encore valide (certains providers)
• Réduit drastiquement les faux positifs
• Scan multi-sources (Git, S3, Slack, etc.)

→ TruffleHog GitHub ↗

Critères de choix

Situation	Recommandation
GitLab Ultimate, équipe petite	GitLab Secret Detection
CI générique, besoin de contrôle	Gitleaks
Volume important, faux positifs problématiques	TruffleHog
Défense en profondeur	Gitleaks (pre-commit) + TruffleHog (CI)

Décisions de gouvernance

Avant d’implémenter, l’équipe doit trancher :

Règles de blocage

Question	Options
Quand bloquer la pipeline ?	Toujours / Seulement sur branches protégées / Jamais (warning)
Quels types de secrets bloquent ?	Tous / Seulement haute sévérité / Liste explicite
Quid des faux positifs ?	Baseline + allowlist / Review manuelle

Ownership et escalade

• Qui traite une alerte ? — L’auteur du commit ? L’équipe sécurité ?
• Quel délai de traitement ? — Immédiat pour les vrais secrets ?
• Quelle escalade ? — Notification Slack ? Incident automatique ?

Gestion des exceptions

Les exceptions sont inévitables. Les documenter :

.gitleaks.toml

[[rules.allowlist]]
description = "Fake key for tests"
regexes = ['''FAKE_.*_KEY''']
paths = ["tests/", "fixtures/"]

Règles :

• Toute exception a une date d’expiration
• Toute exception est justifiée (commentaire)
• Revue trimestrielle des exceptions

Processus de triage et remédiation

Qualifier l’alerte

1. Vrai secret ?

   Faux positif (hash, fixture, exemple) → Ajouter à l’allowlist

2. Exposé publiquement ?

   Repo public, MR publique, historique accessible → Rotation urgente

3. Quel scope ?

   Accès limité (dev) vs accès large (prod, admin)

4. Rotation possible ?

   Token révocable → Révoquer immédiatement Credential hardcodé → Rotation + audit d’utilisation

Actions minimales

Situation	Action
Secret valide détecté	1. Révoquer/rotater 2. Vérifier les logs d’accès 3. Supprimer du code
Secret dans l’historique	Rotation obligatoire (même si supprimé du code actuel)
Secret exposé publiquement	Rotation + audit + évaluer la purge d’historique

Traçabilité

Chaque incident de secret exposé devrait générer :

• Une issue de suivi (rotation effectuée ?)
• Un post-mortem léger (comment c’est arrivé ?)
• Une amélioration (règle ajoutée, process modifié)

Erreurs fréquentes

❌ On a masqué la variable, donc c'est bon

Masquer une variable CI empêche son affichage dans les logs. Ça n’empêche pas de la committer dans le code.

❌ On a supprimé le fichier du repo

L’historique Git conserve tout. Un git log -p ou un clone suffisent à retrouver le secret. Seule la rotation protège.

❌ On scanne la branche default, ça suffit

Le secret est déjà exposé quand il atteint main. Scanner les MR permet de bloquer avant le merge.

❌ Trop de faux positifs → on désactive

La bonne réponse : configurer les règles, maintenir une allowlist, assigner un owner. Pas désactiver.

❌ On bloque tout dès J1

Sans process de gestion des exceptions et de rotation, vous créez du contournement. Commencer en mode warning, puis durcir.

❌ Confondre scanning et management

Le secrets scanning détecte les fuites. La gestion des secrets (Vault, KMS) stocke et distribue les secrets proprement. Ce sont deux sujets complémentaires.

Checklist

Design (décisions)

• Niveaux de scan définis (pre-commit / MR / branche)
• Outil(s) choisi(s) avec justification
• Règles de blocage documentées
• Ownership des alertes assigné
• Process d’exception défini

Implémentation (contrôles)

• Pre-commit hooks configurés (optionnel mais recommandé)
• Job CI de scan sur les MR
• Scan de la branche default comme filet
• Allowlist initiale pour les faux positifs connus
• Notifications configurées (Slack, email)

Run (remédiation)

• Procédure de rotation documentée par type de secret
• Contacts d’escalade identifiés
• Template d’issue pour les incidents secrets
• Revue trimestrielle des exceptions planifiée

Pour aller plus loin

• Guide Gitleaks — Configuration avancée, pre-commit, CI
• Gestion des secrets — Vault, KMS, bonnes pratiques de stockage

×

📖 Voir la documentation →