Lab : Détection et Prévention des Fuites de Secrets dans les Pipelines CI/CD

Vue d’ensemble

Les fuites de secrets dans les pipelines CI/CD sont la cause numéro un de compromission des pipelines. Les identifiants exposés — clés API, mots de passe de bases de données, jetons d’accès cloud — offrent aux attaquants un accès direct aux systèmes de production. Selon le rapport 2025 State of Secrets Sprawl de GitGuardian, plus de 12 millions de nouveaux secrets ont été détectés dans les commits publics GitHub en une seule année.

Le problème n’est pas que les développeurs sont négligents. C’est que la livraison logicielle moderne implique des dizaines de fichiers de configuration, de variables d’environnement et de points d’intégration où les secrets peuvent accidentellement se retrouver dans le contrôle de version. Une seule clé AWS divulguée peut coûter à une organisation des dizaines de milliers de dollars en quelques minutes.

Ce lab pratique vous guide dans la mise en place d’une stratégie de détection de secrets multi-couches couvrant trois points de contrôle critiques :

• Analyse pre-commit — Intercepter les secrets avant qu’ils n’atteignent le dépôt.
• Analyse dans le pipeline — Bloquer les pull requests et les push contenant des secrets.
• Analyse post-commit et à l’exécution — Détecter les secrets qui passent entre les mailles du filet et déclencher la remédiation.

À la fin de ce lab, vous disposerez d’une configuration de défense en profondeur fonctionnelle utilisant gitleaks, truffleHog, GitHub secret scanning et des règles de détection personnalisées.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Git 2.30+ installé et configuré.
• Python 3.8+ avec pip disponible.
• Docker (optionnel, mais recommandé pour l’analyse conteneurisée).
• Un compte GitHub avec accès pour créer des dépôts (requis pour l’exercice GitHub secret scanning).
• Un terminal (macOS, Linux ou WSL sous Windows).

Aucun vrai secret ni compte cloud n’est nécessaire. Nous utiliserons des secrets de test intentionnellement plantés tout au long de ce lab.

Mise en Place de l’Environnement

Étape 1 : Créer un Dépôt de Test

Commencez par créer un dépôt Git vierge que nous utiliserons pour tous les exercices :

mkdir secret-leak-lab && cd secret-leak-lab
git init
echo "# Secret Leak Detection Lab" > README.md
git add README.md
git commit -m "Initial commit"

Étape 2 : Planter des Secrets de Test Intentionnels

Nous avons besoin de secrets réalistes (mais faux) à différents emplacements pour simuler un scénario réel. Créez les fichiers suivants :

Un fichier .env avec des identifiants de base de données :

cat > .env <<'EOF'
DB_HOST=localhost
DB_PORT=5432
DB_USER=admin
DB_PASSWORD=SuperSecret123!
DB_NAME=production_db
SECRET_KEY=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
EOF

Un script Python avec une clé AWS codée en dur :

cat > deploy.py <<'EOF'
import boto3

# WARNING: These are intentionally fake credentials for testing
AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

def deploy_to_s3(bucket, file_path):
    s3 = boto3.client(
        's3',
        aws_access_key_id=AWS_ACCESS_KEY_ID,
        aws_secret_access_key=AWS_SECRET_ACCESS_KEY
    )
    s3.upload_file(file_path, bucket, file_path)
    print(f"Deployed {file_path} to s3://{bucket}")

if __name__ == "__main__":
    deploy_to_s3("my-app-bucket", "dist/app.zip")
EOF

Un fichier YAML de configuration avec une chaîne de connexion à la base de données :

cat > config.yml <<'EOF'
app:
  name: my-application
  environment: production

database:
  url: "postgresql://admin:SuperSecret123!@db.example.com:5432/prod"
  pool_size: 10

redis:
  url: "redis://:MyRedisPassword@cache.example.com:6379/0"
EOF

Un Dockerfile avec une clé API dans une instruction ENV :

cat > Dockerfile <<'EOF'
FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt

# WARNING: Never do this in production
ENV API_KEY=sk-proj-abc123def456ghi789jkl012mno345pqr678stu901vwx234
ENV STRIPE_SECRET_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc

COPY . .
CMD ["python", "app.py"]
EOF

Étape 3 : Vérifier l’État Initial

À ce stade, rien n’empêche ces secrets d’être commités :

git add -A
git status

Git met en staging tout sans problème, secrets inclus. Il n’y a pas de hooks, pas d’analyse, pas de garde-fous. C’est l’état dans lequel se trouvent la plupart des dépôts au départ. Notre objectif est de changer cela.

# Reset staging so we can test scanning before committing
git reset HEAD

Exercice 1 : Analyse Pre-commit avec gitleaks

Gitleaks est un outil open-source conçu pour détecter les secrets codés en dur dans les dépôts Git. Il prend en charge l’analyse du répertoire de travail, de l’historique des commits et peut s’exécuter comme hook pre-commit pour bloquer les secrets avant qu’ils ne soient commités.

Installer gitleaks

Choisissez votre méthode d’installation préférée :

# macOS (Homebrew)
brew install gitleaks

# Docker
docker pull zricethezav/gitleaks:latest

# Go (from source)
go install github.com/gitleaks/gitleaks/v8@latest

Vérifiez l’installation :

gitleaks version

Exécuter gitleaks Manuellement

Analysez le répertoire de travail à la recherche de secrets :

gitleaks detect --source . -v

Vous devriez voir une sortie similaire à la suivante :

Finding:     AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
Secret:      AKIAIOSFODNN7EXAMPLE
RuleID:      aws-access-key-id
Entropy:     3.52
File:        deploy.py
Line:        4

Finding:     AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
Secret:      wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
RuleID:      aws-secret-access-key
Entropy:     4.71
File:        deploy.py
Line:        5

Finding:     DB_PASSWORD=SuperSecret123!
Secret:      SuperSecret123!
RuleID:      generic-credential
Entropy:     3.40
File:        .env
Line:        4

Finding:     STRIPE_SECRET_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc
Secret:      sk_live_4eC39HqLyjWDarjtT1zdp7dc
RuleID:      stripe-secret-key
Entropy:     4.20
File:        Dockerfile
Line:        9

12:14PM INF 6 commits scanned.
12:14PM WRN leaks found: 6

Gitleaks identifie correctement les clés AWS, les identifiants génériques, les clés Stripe, et plus encore. Chaque résultat inclut le fichier, le numéro de ligne et la règle de détection qui s’est déclenchée.

Configurer gitleaks comme Hook Pre-commit

Le framework pre-commit facilite l’exécution automatique de gitleaks avant chaque commit. Installez d’abord pre-commit :

pip install pre-commit

Créez un fichier .pre-commit-config.yaml à la racine de votre dépôt :

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

Installez le hook :

pre-commit install

Tester le Hook : Commiter un Secret (Bloqué)

git add deploy.py
git commit -m "Add deployment script"

Le commit est bloqué :

Detect hardcoded secrets.................................................Failed
- hook id: gitleaks
- exit code: 1

12:15PM WRN leaks found: 2

Le hook pre-commit arrête complètement le commit. Le secret n’entre jamais dans l’historique Git.

Tester le Hook : Commiter du Code Propre (Réussi)

Créez un fichier sans secrets :

cat > utils.py <<'EOF'
def format_date(date_obj):
    return date_obj.strftime("%Y-%m-%d")

def sanitize_input(user_input):
    return user_input.strip().replace("<", "&lt;").replace(">", "&gt;")
EOF

git add utils.py
git commit -m "Add utility functions"

Sortie :

Detect hardcoded secrets.................................................Passed
[main abc1234] Add utility functions
 1 file changed, 5 insertions(+)

Le code propre passe sans problème.

Exercice 2 : Analyse dans le Pipeline avec gitleaks dans GitHub Actions

Les hooks pre-commit sont une première couche solide, mais ils s’exécutent localement et peuvent être contournés. L’analyse dans le pipeline ajoute une couche d’application côté serveur qui ne peut pas être ignorée.

Créer le Workflow GitHub Actions

Créez le fichier .github/workflows/secret-scan.yml avec le contenu suivant :

name: Secret Scanning

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  gitleaks:
    name: Detect Secrets with gitleaks
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}

Le paramètre fetch-depth: 0 est critique — il garantit que l’historique Git complet est disponible afin que gitleaks puisse analyser tous les commits, et pas seulement le dernier.

Comment Cela Fonctionne en Pratique

Scénario A : Une PR avec un secret divulgué. Un développeur ajoute accidentellement une clé API dans un fichier de configuration et ouvre une pull request. L’action gitleaks analyse le diff, détecte le secret et marque la vérification comme échouée. La PR ne peut pas être fusionnée tant que le secret n’est pas supprimé.

Scénario B : Une PR propre. Un développeur ouvre une PR avec de la logique applicative et aucun secret. L’action gitleaks analyse le diff, ne trouve rien et marque la vérification comme réussie. La PR peut passer à la revue de code et être fusionnée.

Pour appliquer cette règle, accédez à Settings → Branches → Branch protection rules de votre dépôt et ajoutez gitleaks comme vérification de statut requise pour la branche main. Cela empêche quiconque de fusionner une PR qui échoue à l’analyse de secrets.

Exercice 3 : Analyse dans le Pipeline avec truffleHog

TruffleHog adopte une approche différente de la détection de secrets. En plus de la correspondance de motifs, il peut vérifier si les secrets détectés sont réellement actifs en les testant contre l’API du service correspondant.

Installer truffleHog

# pip
pip install trufflehog

# Docker
docker pull trufflesecurity/trufflehog:latest

# Homebrew
brew install trufflehog

Exécuter truffleHog sur le Dépôt de Test

# Scan the local repo
trufflehog git file://. --only-verified

Le flag --only-verified indique à truffleHog de ne signaler que les secrets qu’il a confirmés comme actifs. Cela réduit considérablement les faux positifs. Si vous souhaitez voir tous les résultats, y compris les non vérifiés, omettez le flag :

# Show all findings (verified and unverified)
trufflehog git file://.

Vérifié vs. Non vérifié : Un secret vérifié est un secret que truffleHog a testé contre l’API du fournisseur et confirmé comme actif. Par exemple, il tentera de s’authentifier avec une clé AWS pour voir si elle fonctionne. Un secret non vérifié correspond à un motif connu mais n’a pas été confirmé comme actif — il peut s’agir d’une clé révoquée, d’un placeholder ou d’un faux positif.

Créer un Job de Pipeline GitLab CI

TruffleHog s’intègre bien dans GitLab CI. Ajoutez ce qui suit à votre .gitlab-ci.yml :

stages:
  - security

secret-scan:
  stage: security
  image:
    name: trufflesecurity/trufflehog:latest
    entrypoint: [""]
  script:
    - trufflehog git file://. --fail --json > trufflehog-results.json
  artifacts:
    when: always
    paths:
      - trufflehog-results.json
    expire_in: 30 days
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == "main"'

Le flag --fail fait en sorte que truffleHog termine avec un code de sortie non nul si des secrets sont trouvés, ce qui fait échouer le pipeline. Le flag --json produit des résultats structurés qui peuvent être analysés par d’autres outils ou tableaux de bord.

gitleaks vs. truffleHog : Quand Utiliser Lequel

Fonctionnalité	gitleaks	truffleHog
Méthode de détection	Regex + entropie	Regex + entropie + vérification
Vérification des secrets	Non	Oui (teste si le secret est actif)
Rapidité	Très rapide	Plus lent (en raison de la vérification)
Taux de faux positifs	Modéré	Faible (avec –only-verified)
Règles personnalisées	Oui (.gitleaks.toml)	Oui (détecteurs personnalisés)
Support pre-commit	Natif	Via script wrapper
Idéal pour	Vérifications rapides pre-commit et PR	Analyses approfondies et vérification

Recommandation : Utilisez gitleaks pour les hooks pre-commit rapides et les vérifications de PR. Utilisez truffleHog pour les analyses approfondies périodiques et lorsque vous avez besoin de résultats vérifiés pour prioriser la remédiation.

Exercice 4 : GitHub Secret Scanning et Push Protection

GitHub propose une analyse de secrets intégrée qui fonctionne au niveau de la plateforme. Contrairement à gitleaks et truffleHog, que vous installez et configurez vous-même, GitHub secret scanning est intégré directement dans les paramètres du dépôt.

Activer Secret Scanning

1. Accédez à votre dépôt sur GitHub.
2. Naviguez vers Settings → Code security and analysis.
3. Activez Secret scanning.
4. Activez Push protection.

Push protection est la fonctionnalité clé ici. Lorsqu’elle est activée, GitHub bloque tout push contenant un motif de secret reconnu avant qu’il n’atteigne le dépôt.

Tester Push Protection

Tentez de pousser un commit contenant un motif de secret connu, tel qu’une clé d’accès AWS ou un jeton d’accès personnel GitHub :

# Stage and commit a file with a test secret
git add deploy.py
git commit -m "Add deploy script"
git push origin main

GitHub bloque le push avec un message comme :

remote: error: GH013: Repository rule violations found for refs/heads/main.
remote:
 remote: - GITHUB PUSH PROTECTION
remote:   ——————————————————————————————————————————
remote:     Resolve the following violations before pushing again
remote:
remote:     — Push cannot contain secrets —
remote:
remote:
remote:      (?) To push, remove secret from commit(s) or follow this URL to allow the secret.
remote:
remote:      — Amazon AWS Access Key ID —
remote:        locations:
 remote:          - commit: abc1234def5678
 remote:            path: deploy.py:4
remote:
! [remote rejected] main -> main (push rule violations)
error: failed to push some refs

Gérer les Faux Positifs

Si GitHub signale une valeur qui n’est pas un vrai secret (par exemple, un fixture de test ou un exemple de documentation), vous pouvez contourner push protection avec une raison. GitHub fournit une URL dans le message de rejet où vous pouvez :

• Sélectionner une raison de contournement : « It’s used in tests », « It’s a false positive » ou « I’ll fix it later ».
• Soumettre le contournement, ce qui autorise le push mais enregistre l’événement pour l’audit.

Les administrateurs de l’organisation peuvent voir tous les contournements dans le tableau de bord Security → Secret scanning.

Le Programme Partenaire

GitHub collabore avec plus de 200 fournisseurs de services (AWS, Stripe, Twilio, SendGrid et autres) via son programme partenaire de secret scanning. Lorsqu’un secret d’un partenaire est détecté :

1. GitHub notifie automatiquement le fournisseur de services.
2. Le fournisseur révoque l’identifiant compromis.
3. Le propriétaire du dépôt est notifié par e-mail et via l’onglet Security.

Cela signifie que même si un secret passe à travers toutes les autres défenses et atteint un dépôt public, la fenêtre de dommages peut être réduite à quelques minutes grâce à la révocation automatique.

Exercice 5 : Motifs de Secrets Personnalisés

Les règles de détection par défaut couvrent les fournisseurs courants (AWS, Stripe, GitHub, Google Cloud, etc.), mais la plupart des organisations ont également des secrets internes avec des formats personnalisés que les outils standards ne détecteront pas. Gitleaks prend en charge les règles personnalisées via un fichier de configuration .gitleaks.toml.

Créer une Configuration gitleaks Personnalisée

Créez un fichier .gitleaks.toml à la racine du dépôt :

[extend]
# Extend the default gitleaks configuration
# useDefault = true

[[rules]]
id = "mycompany-api-key"
description = "MyCompany Internal API Key"
regex = '''MYCOMPANY-KEY-[A-Za-z0-9]{32}'''
tags = ["internal", "api-key"]
keywords = ["mycompany-key"]

[[rules]]
id = "internal-database-url"
description = "Internal Database Connection String"
regex = '''postgresql://[^:]+:[^@]+@internal-db\.[a-z0-9-]+\.corp\.[a-z]+\.com'''
tags = ["internal", "database"]
keywords = ["internal-db"]

[[rules]]
id = "internal-jwt-signing-key"
description = "Internal JWT Signing Key"
regex = '''JWT_SIGNING_KEY=[A-Za-z0-9+/=]{64,}'''
tags = ["internal", "jwt"]
keywords = ["jwt_signing_key"]

[allowlist]
description = "Global allowlist"
paths = [
  '''(.*?)test(.*?)\.py''',
  '''(.*?)_test\.go''',
  '''(.*?)spec(.*?)\.js''',
  '''(.*?)fixtures(.*?)''',
  '''README\.md'''
]

[[rules.allowlist]]
id = "mycompany-api-key"
regexes = [
  '''MYCOMPANY-KEY-EXAMPLE[A-Za-z0-9]{24}''',
  '''MYCOMPANY-KEY-TEST[A-Za-z0-9]{28}'''
]

Comprendre la Configuration

• Règles personnalisées : Les sections [[rules]] définissent des motifs spécifiques à votre organisation. Le champ regex utilise des expressions régulières compatibles Go. Le champ keywords aide gitleaks à filtrer rapidement les fichiers — seuls les fichiers contenant le mot-clé sont analysés avec la regex complète, ce qui améliore les performances.
• Liste d’autorisation globale : La section [allowlist] définit les chemins qui doivent être exclus de toute analyse. Les fichiers de test, les fixtures et la documentation sont des exclusions courantes.
• Liste d’autorisation par règle : La section [[rules.allowlist]] définit des exceptions pour des règles spécifiques. Ici, nous excluons les clés d’exemple connues qui apparaissent dans la documentation ou les helpers de test.

Tester la Configuration Personnalisée

Créez un fichier avec un secret personnalisé pour tester :

cat > internal-config.py <<'EOF'
MYCOMPANY_API_KEY = "MYCOMPANY-KEY-a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"
EOF

Exécutez gitleaks avec la configuration personnalisée :

gitleaks detect --source . --config .gitleaks.toml -v

La règle personnalisée détecte la clé API interne qui aurait été manquée par les règles par défaut.

Construire une Stratégie de Défense en Profondeur

Aucune couche unique de détection de secrets n’est suffisante. Les développeurs peuvent ignorer les hooks pre-commit. Les analyses de pipeline ne détectent les secrets qu’au moment de la PR. GitHub push protection ne couvre que les motifs des fournisseurs connus. Une stratégie robuste superpose toutes ces couches.

Les Cinq Couches de Défense des Secrets

┌─────────────────────────────────────────────────────┐
│  Couche 1 : Hook Pre-commit (gitleaks)              │
│  → Intercepte les secrets avant l'historique local   │
├─────────────────────────────────────────────────────┤
│  Couche 2 : Analyse PR / Merge Request (gitleaks)   │
│  → Bloque les PR contenant des secrets               │
├─────────────────────────────────────────────────────┤
│  Couche 3 : Push Protection (GitHub / GitLab)       │
│  → Blocage au niveau plateforme des motifs connus    │
├─────────────────────────────────────────────────────┤
│  Couche 4 : Analyse Post-merge (truffleHog planifié)│
│  → Analyse approfondie hebdomadaire avec vérification│
├─────────────────────────────────────────────────────┤
│  Couche 5 : Surveillance Runtime (logs d'audit vault)│
│  → Détection d'anomalies d'utilisation des secrets   │
└─────────────────────────────────────────────────────┘

Pourquoi Aucune Couche Unique ne Suffit

• Les hooks pre-commit peuvent être contournés avec git commit --no-verify ou en utilisant un client Git qui ne prend pas en charge les hooks.
• Les analyses de pipeline ne s’exécutent que sur les branches qui déclenchent la CI — les push directs vers des branches non protégées ou les force push peuvent les ignorer.
• Push protection ne détecte que les motifs des fournisseurs connus — les secrets internes personnalisés ne sont pas couverts.
• Les analyses post-merge sont réactives — elles trouvent les secrets après qu’ils sont déjà dans le dépôt.

Chaque couche compense les faiblesses des autres. Ensemble, elles créent un système où un secret devrait contourner les cinq couches pour passer inaperçu.

Workflow Combiné : Analyse de PR et Analyse Complète Hebdomadaire

Voici un workflow GitHub Actions combiné qui exécute gitleaks sur chaque PR et effectue une analyse complète du dépôt chaque semaine :

name: Secret Scanning (Multi-Layer)

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
  schedule:
    # Full repository scan every Monday at 6:00 AM UTC
    - cron: '0 6 * * 1'

jobs:
  # Layer 2: PR and push scanning
  gitleaks-pr-scan:
    name: gitleaks PR Scan
    runs-on: ubuntu-latest
    if: github.event_name == 'push' || github.event_name == 'pull_request'
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run gitleaks (diff scan)
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  # Layer 4: Weekly deep scan with truffleHog
  trufflehog-full-scan:
    name: truffleHog Full Repository Scan
    runs-on: ubuntu-latest
    if: github.event_name == 'schedule'
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install truffleHog
        run: pip install trufflehog

      - name: Run truffleHog (full scan with verification)
        run: |
          trufflehog git file://. --fail --json > trufflehog-results.json || true
          if [ -s trufflehog-results.json ]; then
            echo "::error::Secrets detected in repository. See trufflehog-results.json."
            cat trufflehog-results.json | python -m json.tool
            exit 1
          fi

      - name: Upload scan results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: trufflehog-results
          path: trufflehog-results.json
          retention-days: 90

Ce workflow garantit que chaque modification de code est analysée en temps réel, et que l’ensemble de l’historique du dépôt est audité chaque semaine pour détecter les secrets qui auraient pu passer inaperçus.

Nettoyage

Après avoir terminé le lab, supprimez les secrets de test et réinitialisez le dépôt :

# Remove test files with secrets
rm -f .env deploy.py config.yml Dockerfile internal-config.py

# Remove test configurations (optional — keep if you want to reuse them)
# rm -f .gitleaks.toml .pre-commit-config.yaml

# Commit the cleanup
git add -A
git commit -m "Remove test secrets from lab exercises"

# If you want to completely remove secrets from Git history,
# use git-filter-repo (more thorough than git filter-branch):
pip install git-filter-repo
git filter-repo --invert-paths --path deploy.py --path .env --path config.yml --path Dockerfile

Important : La simple suppression de fichiers ne les retire pas de l’historique Git. Toute personne ayant accès au dépôt peut encore trouver les secrets dans les commits passés. Utilisez git-filter-repo pour réécrire l’historique et supprimer définitivement les fichiers sensibles. Après la réécriture de l’historique, faites un force-push vers le remote et demandez à tous les collaborateurs de re-cloner le dépôt.

Points Clés à Retenir

• Les secrets dans les pipelines CI/CD sont le vecteur d’attaque le plus courant pour la compromission des pipelines. Un seul identifiant divulgué peut donner à un attaquant un accès complet à l’infrastructure de production.
• Les hooks pre-commit avec gitleaks offrent la boucle de rétroaction la plus rapide. Les développeurs sont alertés immédiatement, avant que le secret n’entre dans l’historique Git.
• L’analyse dans le pipeline est une couche d’application obligatoire. Elle ne peut pas être contournée par les développeurs et garantit qu’aucune PR contenant des secrets n’est fusionnée.
• La capacité de vérification de truffleHog réduit considérablement les faux positifs. Utilisez-le pour les analyses approfondies planifiées où la précision compte plus que la vitesse.
• GitHub push protection et le programme partenaire ajoutent une défense au niveau de la plateforme qui fonctionne sans aucune configuration dans vos pipelines CI/CD.
• Les règles de détection personnalisées sont essentielles pour intercepter les secrets spécifiques à l’organisation que les outils standards manqueront. Investissez du temps dans l’écriture de règles pour vos formats de clés internes.
• La défense en profondeur est la seule stratégie fiable. Aucun outil ou couche unique ne détecte tout. Combinez pre-commit, analyse dans le pipeline, push protection, analyses planifiées et surveillance runtime pour une couverture complète.

Prochaines Étapes

Maintenant que vous savez détecter et prévenir les fuites de secrets, l’étape suivante est d’éliminer complètement les secrets codés en dur en adoptant une gestion appropriée des secrets :

• Gestion des Secrets dans les Pipelines CI/CD — Apprenez à utiliser HashiCorp Vault, AWS Secrets Manager et les magasins de secrets natifs CI/CD pour injecter des secrets à l’exécution sans jamais les stocker dans le code.
• Identifiants Éphémères et Workload Identity Federation — Éliminez complètement les secrets à longue durée de vie en utilisant la fédération d’identité de charge de travail basée sur OIDC pour authentifier les pipelines auprès des fournisseurs cloud sans aucun identifiant stocké.