Les fuites de secrets dans les pipelines CI\/CD sont la cause num\u00e9ro un de compromission des pipelines. Les identifiants expos\u00e9s \u2014 cl\u00e9s API, mots de passe de bases de donn\u00e9es, jetons d’acc\u00e8s cloud \u2014 offrent aux attaquants un acc\u00e8s direct aux syst\u00e8mes de production. Selon le rapport 2025 State of Secrets Sprawl de GitGuardian, plus de 12 millions de nouveaux secrets ont \u00e9t\u00e9 d\u00e9tect\u00e9s dans les commits publics GitHub en une seule ann\u00e9e.<\/p>\n
Le probl\u00e8me n’est pas que les d\u00e9veloppeurs sont n\u00e9gligents. C’est que la livraison logicielle moderne implique des dizaines de fichiers de configuration, de variables d’environnement et de points d’int\u00e9gration o\u00f9 les secrets peuvent accidentellement se retrouver dans le contr\u00f4le de version. Une seule cl\u00e9 AWS divulgu\u00e9e peut co\u00fbter \u00e0 une organisation des dizaines de milliers de dollars en quelques minutes.<\/p>\n
Ce lab pratique vous guide dans la mise en place d’une strat\u00e9gie de d\u00e9tection de secrets multi-couches couvrant trois points de contr\u00f4le critiques :<\/p>\n
\u00c0 la fin de ce lab, vous disposerez d’une configuration de d\u00e9fense en profondeur fonctionnelle utilisant gitleaks, truffleHog, GitHub secret scanning et des r\u00e8gles de d\u00e9tection personnalis\u00e9es.<\/p>\n
Avant de commencer, assurez-vous de disposer des \u00e9l\u00e9ments suivants :<\/p>\n
pip<\/code> disponible.<\/li>\n- Docker<\/strong> (optionnel, mais recommand\u00e9 pour l’analyse conteneuris\u00e9e).<\/li>\n
- Un compte GitHub<\/strong> avec acc\u00e8s pour cr\u00e9er des d\u00e9p\u00f4ts (requis pour l’exercice GitHub secret scanning).<\/li>\n
- Un terminal<\/strong> (macOS, Linux ou WSL sous Windows).<\/li>\n<\/ul>\n
Aucun vrai secret ni compte cloud n’est n\u00e9cessaire. Nous utiliserons des secrets de test intentionnellement plant\u00e9s tout au long de ce lab.<\/p>\n
Mise en Place de l’Environnement<\/h2>\n\u00c9tape 1 : Cr\u00e9er un D\u00e9p\u00f4t de Test<\/h3>\n
Commencez par cr\u00e9er un d\u00e9p\u00f4t Git vierge que nous utiliserons pour tous les exercices :<\/p>\n
mkdir secret-leak-lab && cd secret-leak-lab\ngit init\necho \"# Secret Leak Detection Lab\" > README.md\ngit add README.md\ngit commit -m \"Initial commit\"<\/code><\/pre>\n\u00c9tape 2 : Planter des Secrets de Test Intentionnels<\/h3>\n
Nous avons besoin de secrets r\u00e9alistes (mais faux) \u00e0 diff\u00e9rents emplacements pour simuler un sc\u00e9nario r\u00e9el. Cr\u00e9ez les fichiers suivants :<\/p>\n
Un fichier .env<\/code> avec des identifiants de base de donn\u00e9es :<\/strong><\/p>\ncat > .env <<'EOF'\nDB_HOST=localhost\nDB_PORT=5432\nDB_USER=admin\nDB_PASSWORD=SuperSecret123!\nDB_NAME=production_db\nSECRET_KEY=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6\nEOF<\/code><\/pre>\nUn script Python avec une cl\u00e9 AWS cod\u00e9e en dur :<\/strong><\/p>\ncat > deploy.py <<'EOF'\nimport boto3\n\n# WARNING: These are intentionally fake credentials for testing\nAWS_ACCESS_KEY_ID = \"AKIAIOSFODNN7EXAMPLE\"\nAWS_SECRET_ACCESS_KEY = \"wJalrXUtnFEMI\/K7MDENG\/bPxRfiCYEXAMPLEKEY\"\n\ndef deploy_to_s3(bucket, file_path):\n s3 = boto3.client(\n 's3',\n aws_access_key_id=AWS_ACCESS_KEY_ID,\n aws_secret_access_key=AWS_SECRET_ACCESS_KEY\n )\n s3.upload_file(file_path, bucket, file_path)\n print(f\"Deployed {file_path} to s3:\/\/{bucket}\")\n\nif __name__ == \"__main__\":\n deploy_to_s3(\"my-app-bucket\", \"dist\/app.zip\")\nEOF<\/code><\/pre>\nUn fichier YAML de configuration avec une cha\u00eene de connexion \u00e0 la base de donn\u00e9es :<\/strong><\/p>\ncat > config.yml <<'EOF'\napp:\n name: my-application\n environment: production\n\ndatabase:\n url: \"postgresql:\/\/admin:SuperSecret123!@db.example.com:5432\/prod\"\n pool_size: 10\n\nredis:\n url: \"redis:\/\/:MyRedisPassword@cache.example.com:6379\/0\"\nEOF<\/code><\/pre>\nUn Dockerfile avec une cl\u00e9 API dans une instruction ENV :<\/strong><\/p>\ncat > Dockerfile <<'EOF'\nFROM python:3.11-slim\n\nWORKDIR \/app\nCOPY requirements.txt .\nRUN pip install -r requirements.txt\n\n# WARNING: Never do this in production\nENV API_KEY=sk-proj-abc123def456ghi789jkl012mno345pqr678stu901vwx234\nENV STRIPE_SECRET_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc\n\nCOPY . .\nCMD [\"python\", \"app.py\"]\nEOF<\/code><\/pre>\n\u00c9tape 3 : V\u00e9rifier l’\u00c9tat Initial<\/h3>\n
\u00c0 ce stade, rien n’emp\u00eache ces secrets d’\u00eatre commit\u00e9s :<\/p>\n
git add -A\ngit status<\/code><\/pre>\nGit met en staging tout sans probl\u00e8me, secrets inclus. Il n’y a pas de hooks, pas d’analyse, pas de garde-fous. C’est l’\u00e9tat dans lequel se trouvent la plupart des d\u00e9p\u00f4ts au d\u00e9part. Notre objectif est de changer cela.<\/p>\n
# Reset staging so we can test scanning before committing\ngit reset HEAD<\/code><\/pre>\nExercice 1 : Analyse Pre-commit avec gitleaks<\/h2>\n
Gitleaks<\/a> est un outil open-source con\u00e7u pour d\u00e9tecter les secrets cod\u00e9s en dur dans les d\u00e9p\u00f4ts Git. Il prend en charge l’analyse du r\u00e9pertoire de travail, de l’historique des commits et peut s’ex\u00e9cuter comme hook pre-commit pour bloquer les secrets avant qu’ils ne soient commit\u00e9s.<\/p>\nInstaller gitleaks<\/h3>\n
Choisissez votre m\u00e9thode d’installation pr\u00e9f\u00e9r\u00e9e :<\/p>\n
# macOS (Homebrew)\nbrew install gitleaks\n\n# Docker\ndocker pull zricethezav\/gitleaks:latest\n\n# Go (from source)\ngo install github.com\/gitleaks\/gitleaks\/v8@latest<\/code><\/pre>\nV\u00e9rifiez l’installation :<\/p>\n
gitleaks version<\/code><\/pre>\nEx\u00e9cuter gitleaks Manuellement<\/h3>\n
Analysez le r\u00e9pertoire de travail \u00e0 la recherche de secrets :<\/p>\n
gitleaks detect --source . -v<\/code><\/pre>\nVous devriez voir une sortie similaire \u00e0 la suivante :<\/p>\n
Finding: AWS_ACCESS_KEY_ID = \"AKIAIOSFODNN7EXAMPLE\"\nSecret: AKIAIOSFODNN7EXAMPLE\nRuleID: aws-access-key-id\nEntropy: 3.52\nFile: deploy.py\nLine: 4\n\nFinding: AWS_SECRET_ACCESS_KEY = \"wJalrXUtnFEMI\/K7MDENG\/bPxRfiCYEXAMPLEKEY\"\nSecret: wJalrXUtnFEMI\/K7MDENG\/bPxRfiCYEXAMPLEKEY\nRuleID: aws-secret-access-key\nEntropy: 4.71\nFile: deploy.py\nLine: 5\n\nFinding: DB_PASSWORD=SuperSecret123!\nSecret: SuperSecret123!\nRuleID: generic-credential\nEntropy: 3.40\nFile: .env\nLine: 4\n\nFinding: STRIPE_SECRET_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc\nSecret: sk_live_4eC39HqLyjWDarjtT1zdp7dc\nRuleID: stripe-secret-key\nEntropy: 4.20\nFile: Dockerfile\nLine: 9\n\n12:14PM INF 6 commits scanned.\n12:14PM WRN leaks found: 6<\/code><\/pre>\nGitleaks identifie correctement les cl\u00e9s AWS, les identifiants g\u00e9n\u00e9riques, les cl\u00e9s Stripe, et plus encore. Chaque r\u00e9sultat inclut le fichier, le num\u00e9ro de ligne et la r\u00e8gle de d\u00e9tection qui s’est d\u00e9clench\u00e9e.<\/p>\n
Configurer gitleaks comme Hook Pre-commit<\/h3>\n
Le framework pre-commit<\/a> facilite l’ex\u00e9cution automatique de gitleaks avant chaque commit. Installez d’abord pre-commit :<\/p>\npip install pre-commit<\/code><\/pre>\nCr\u00e9ez un fichier .pre-commit-config.yaml<\/code> \u00e0 la racine de votre d\u00e9p\u00f4t :<\/p>\nrepos:\n - repo: https:\/\/github.com\/gitleaks\/gitleaks\n rev: v8.21.2\n hooks:\n - id: gitleaks<\/code><\/pre>\nInstallez le hook :<\/p>\n
pre-commit install<\/code><\/pre>\nTester le Hook : Commiter un Secret (Bloqu\u00e9)<\/h3>\ngit add deploy.py\ngit commit -m \"Add deployment script\"<\/code><\/pre>\nLe commit est bloqu\u00e9 :<\/p>\n
Detect hardcoded secrets.................................................Failed\n- hook id: gitleaks\n- exit code: 1\n\n12:15PM WRN leaks found: 2\n<\/code><\/pre>\nLe hook pre-commit arr\u00eate compl\u00e8tement le commit. Le secret n’entre jamais dans l’historique Git.<\/p>\n
Tester le Hook : Commiter du Code Propre (R\u00e9ussi)<\/h3>\n
Cr\u00e9ez un fichier sans secrets :<\/p>\n
cat > utils.py <<'EOF'\ndef format_date(date_obj):\n return date_obj.strftime(\"%Y-%m-%d\")\n\ndef sanitize_input(user_input):\n return user_input.strip().replace(\"<\", \"<\").replace(\">\", \">\")\nEOF\n\ngit add utils.py\ngit commit -m \"Add utility functions\"<\/code><\/pre>\nSortie :<\/p>\n
Detect hardcoded secrets.................................................Passed\n[main abc1234] Add utility functions\n 1 file changed, 5 insertions(+)\n<\/code><\/pre>\nLe code propre passe sans probl\u00e8me.<\/p>\n
Exercice 2 : Analyse dans le Pipeline avec gitleaks dans GitHub Actions<\/h2>\n
Les hooks pre-commit sont une premi\u00e8re couche solide, mais ils s’ex\u00e9cutent localement et peuvent \u00eatre contourn\u00e9s. L’analyse dans le pipeline ajoute une couche d’application c\u00f4t\u00e9 serveur qui ne peut pas \u00eatre ignor\u00e9e.<\/p>\n
Cr\u00e9er le Workflow GitHub Actions<\/h3>\n
Cr\u00e9ez le fichier .github\/workflows\/secret-scan.yml<\/code> avec le contenu suivant :<\/p>\nname: Secret Scanning\n\non:\n push:\n branches: [main, develop]\n pull_request:\n branches: [main]\n\njobs:\n gitleaks:\n name: Detect Secrets with gitleaks\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Run gitleaks\n uses: gitleaks\/gitleaks-action@v2\n env:\n GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}\n<\/code><\/pre>\nLe param\u00e8tre fetch-depth: 0<\/code> est critique \u2014 il garantit que l’historique Git complet est disponible afin que gitleaks puisse analyser tous les commits, et pas seulement le dernier.<\/p>\nComment Cela Fonctionne en Pratique<\/h3>\n
Sc\u00e9nario A : Une PR avec un secret divulgu\u00e9.<\/strong> Un d\u00e9veloppeur ajoute accidentellement une cl\u00e9 API dans un fichier de configuration et ouvre une pull request. L’action gitleaks analyse le diff, d\u00e9tecte le secret et marque la v\u00e9rification comme \u00e9chou\u00e9e. La PR ne peut pas \u00eatre fusionn\u00e9e tant que le secret n’est pas supprim\u00e9.<\/p>\nSc\u00e9nario B : Une PR propre.<\/strong> Un d\u00e9veloppeur ouvre une PR avec de la logique applicative et aucun secret. L’action gitleaks analyse le diff, ne trouve rien et marque la v\u00e9rification comme r\u00e9ussie. La PR peut passer \u00e0 la revue de code et \u00eatre fusionn\u00e9e.<\/p>\nPour appliquer cette r\u00e8gle, acc\u00e9dez \u00e0 Settings \u2192 Branches \u2192 Branch protection rules<\/strong> de votre d\u00e9p\u00f4t et ajoutez gitleaks<\/code> comme v\u00e9rification de statut requise pour la branche main<\/code>. Cela emp\u00eache quiconque de fusionner une PR qui \u00e9choue \u00e0 l’analyse de secrets.<\/p>\nExercice 3 : Analyse dans le Pipeline avec truffleHog<\/h2>\n
TruffleHog<\/a> adopte une approche diff\u00e9rente de la d\u00e9tection de secrets. En plus de la correspondance de motifs, il peut v\u00e9rifier<\/strong> si les secrets d\u00e9tect\u00e9s sont r\u00e9ellement actifs en les testant contre l’API du service correspondant.<\/p>\nInstaller truffleHog<\/h3>\n# pip\npip install trufflehog\n\n# Docker\ndocker pull trufflesecurity\/trufflehog:latest\n\n# Homebrew\nbrew install trufflehog<\/code><\/pre>\nEx\u00e9cuter truffleHog sur le D\u00e9p\u00f4t de Test<\/h3>\n# Scan the local repo\ntrufflehog git file:\/\/. --only-verified<\/code><\/pre>\nLe flag --only-verified<\/code> indique \u00e0 truffleHog de ne signaler que les secrets qu’il a confirm\u00e9s comme actifs. Cela r\u00e9duit consid\u00e9rablement les faux positifs. Si vous souhaitez voir tous les r\u00e9sultats, y compris les non v\u00e9rifi\u00e9s, omettez le flag :<\/p>\n# Show all findings (verified and unverified)\ntrufflehog git file:\/\/.<\/code><\/pre>\nV\u00e9rifi\u00e9 vs. Non v\u00e9rifi\u00e9 :<\/strong> Un secret v\u00e9rifi\u00e9<\/em> est un secret que truffleHog a test\u00e9 contre l’API du fournisseur et confirm\u00e9 comme actif. Par exemple, il tentera de s’authentifier avec une cl\u00e9 AWS pour voir si elle fonctionne. Un secret non v\u00e9rifi\u00e9<\/em> correspond \u00e0 un motif connu mais n’a pas \u00e9t\u00e9 confirm\u00e9 comme actif \u2014 il peut s’agir d’une cl\u00e9 r\u00e9voqu\u00e9e, d’un placeholder ou d’un faux positif.<\/p>\nCr\u00e9er un Job de Pipeline GitLab CI<\/h3>\n
TruffleHog s’int\u00e8gre bien dans GitLab CI. Ajoutez ce qui suit \u00e0 votre .gitlab-ci.yml<\/code> :<\/p>\nstages:\n - security\n\nsecret-scan:\n stage: security\n image:\n name: trufflesecurity\/trufflehog:latest\n entrypoint: [\"\"]\n script:\n - trufflehog git file:\/\/. --fail --json > trufflehog-results.json\n artifacts:\n when: always\n paths:\n - trufflehog-results.json\n expire_in: 30 days\n rules:\n - if: '$CI_PIPELINE_SOURCE == \"merge_request_event\"'\n - if: '$CI_COMMIT_BRANCH == \"main\"'\n<\/code><\/pre>\nLe flag --fail<\/code> fait en sorte que truffleHog termine avec un code de sortie non nul si des secrets sont trouv\u00e9s, ce qui fait \u00e9chouer le pipeline. Le flag --json<\/code> produit des r\u00e9sultats structur\u00e9s qui peuvent \u00eatre analys\u00e9s par d’autres outils ou tableaux de bord.<\/p>\ngitleaks vs. truffleHog : Quand Utiliser Lequel<\/h3>\n
\n\n\nFonctionnalit\u00e9<\/th>\n gitleaks<\/th>\n truffleHog<\/th>\n<\/tr>\n<\/thead>\n \n\nM\u00e9thode de d\u00e9tection<\/td>\n Regex + entropie<\/td>\n Regex + entropie + v\u00e9rification<\/td>\n<\/tr>\n \nV\u00e9rification des secrets<\/td>\n Non<\/td>\n Oui (teste si le secret est actif)<\/td>\n<\/tr>\n \nRapidit\u00e9<\/td>\n Tr\u00e8s rapide<\/td>\n Plus lent (en raison de la v\u00e9rification)<\/td>\n<\/tr>\n \nTaux de faux positifs<\/td>\n Mod\u00e9r\u00e9<\/td>\n Faible (avec –only-verified)<\/td>\n<\/tr>\n \nR\u00e8gles personnalis\u00e9es<\/td>\n Oui (.gitleaks.toml)<\/td>\n Oui (d\u00e9tecteurs personnalis\u00e9s)<\/td>\n<\/tr>\n \nSupport pre-commit<\/td>\n Natif<\/td>\n Via script wrapper<\/td>\n<\/tr>\n \nId\u00e9al pour<\/td>\n V\u00e9rifications rapides pre-commit et PR<\/td>\n Analyses approfondies et v\u00e9rification<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nRecommandation :<\/strong> Utilisez gitleaks pour les hooks pre-commit rapides et les v\u00e9rifications de PR. Utilisez truffleHog pour les analyses approfondies p\u00e9riodiques et lorsque vous avez besoin de r\u00e9sultats v\u00e9rifi\u00e9s pour prioriser la rem\u00e9diation.<\/p>\nExercice 4 : GitHub Secret Scanning et Push Protection<\/h2>\n
GitHub propose une analyse de secrets int\u00e9gr\u00e9e qui fonctionne au niveau de la plateforme. Contrairement \u00e0 gitleaks et truffleHog, que vous installez et configurez vous-m\u00eame, GitHub secret scanning est int\u00e9gr\u00e9 directement dans les param\u00e8tres du d\u00e9p\u00f4t.<\/p>\n
Activer Secret Scanning<\/h3>\n\n- Acc\u00e9dez \u00e0 votre d\u00e9p\u00f4t sur GitHub.<\/li>\n
- Naviguez vers Settings \u2192 Code security and analysis<\/strong>.<\/li>\n
- Activez Secret scanning<\/strong>.<\/li>\n
- Activez Push protection<\/strong>.<\/li>\n<\/ol>\n
Push protection est la fonctionnalit\u00e9 cl\u00e9 ici. Lorsqu’elle est activ\u00e9e, GitHub bloque tout push contenant un motif de secret reconnu avant qu’il n’atteigne le d\u00e9p\u00f4t.<\/p>\n
Tester Push Protection<\/h3>\n
Tentez de pousser un commit contenant un motif de secret connu, tel qu’une cl\u00e9 d’acc\u00e8s AWS ou un jeton d’acc\u00e8s personnel GitHub :<\/p>\n
# Stage and commit a file with a test secret\ngit add deploy.py\ngit commit -m \"Add deploy script\"\ngit push origin main<\/code><\/pre>\nGitHub bloque le push avec un message comme :<\/p>\n
remote: error: GH013: Repository rule violations found for refs\/heads\/main.\nremote:\n remote: - GITHUB PUSH PROTECTION\nremote: \u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\nremote: Resolve the following violations before pushing again\nremote:\nremote: \u2014 Push cannot contain secrets \u2014\nremote:\nremote:\nremote: (?) To push, remove secret from commit(s) or follow this URL to allow the secret.\nremote:\nremote: \u2014 Amazon AWS Access Key ID \u2014\nremote: locations:\n remote: - commit: abc1234def5678\n remote: path: deploy.py:4\nremote:\n! [remote rejected] main -> main (push rule violations)\nerror: failed to push some refs<\/code><\/pre>\nG\u00e9rer les Faux Positifs<\/h3>\n
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\u00f9 vous pouvez :<\/p>\n
\n- S\u00e9lectionner une raison de contournement : \u00ab\u00a0It’s used in tests\u00a0\u00bb<\/strong>, \u00ab\u00a0It’s a false positive\u00a0\u00bb<\/strong> ou \u00ab\u00a0I’ll fix it later\u00a0\u00bb<\/strong>.<\/li>\n
- Soumettre le contournement, ce qui autorise le push mais enregistre l’\u00e9v\u00e9nement pour l’audit.<\/li>\n<\/ul>\n
Les administrateurs de l’organisation peuvent voir tous les contournements dans le tableau de bord Security \u2192 Secret scanning<\/strong>.<\/p>\nLe Programme Partenaire<\/h3>\n
GitHub collabore avec plus de 200 fournisseurs de services (AWS, Stripe, Twilio, SendGrid et autres) via son programme partenaire de secret scanning<\/strong>. Lorsqu’un secret d’un partenaire est d\u00e9tect\u00e9 :<\/p>\n\n- GitHub notifie automatiquement le fournisseur de services.<\/li>\n
- Le fournisseur r\u00e9voque l’identifiant compromis.<\/li>\n
- Le propri\u00e9taire du d\u00e9p\u00f4t est notifi\u00e9 par e-mail et via l’onglet Security.<\/li>\n<\/ol>\n
Cela signifie que m\u00eame si un secret passe \u00e0 travers toutes les autres d\u00e9fenses et atteint un d\u00e9p\u00f4t public, la fen\u00eatre de dommages peut \u00eatre r\u00e9duite \u00e0 quelques minutes gr\u00e2ce \u00e0 la r\u00e9vocation automatique.<\/p>\n
Exercice 5 : Motifs de Secrets Personnalis\u00e9s<\/h2>\n
Les r\u00e8gles de d\u00e9tection par d\u00e9faut couvrent les fournisseurs courants (AWS, Stripe, GitHub, Google Cloud, etc.), mais la plupart des organisations ont \u00e9galement des secrets internes avec des formats personnalis\u00e9s que les outils standards ne d\u00e9tecteront pas. Gitleaks prend en charge les r\u00e8gles personnalis\u00e9es via un fichier de configuration .gitleaks.toml<\/code>.<\/p>\nCr\u00e9er une Configuration gitleaks Personnalis\u00e9e<\/h3>\n
Cr\u00e9ez un fichier .gitleaks.toml<\/code> \u00e0 la racine du d\u00e9p\u00f4t :<\/p>\n[extend]\n# Extend the default gitleaks configuration\n# useDefault = true\n\n[[rules]]\nid = \"mycompany-api-key\"\ndescription = \"MyCompany Internal API Key\"\nregex = '''MYCOMPANY-KEY-[A-Za-z0-9]{32}'''\ntags = [\"internal\", \"api-key\"]\nkeywords = [\"mycompany-key\"]\n\n[[rules]]\nid = \"internal-database-url\"\ndescription = \"Internal Database Connection String\"\nregex = '''postgresql:\/\/[^:]+:[^@]+@internal-db\\.[a-z0-9-]+\\.corp\\.[a-z]+\\.com'''\ntags = [\"internal\", \"database\"]\nkeywords = [\"internal-db\"]\n\n[[rules]]\nid = \"internal-jwt-signing-key\"\ndescription = \"Internal JWT Signing Key\"\nregex = '''JWT_SIGNING_KEY=[A-Za-z0-9+\/=]{64,}'''\ntags = [\"internal\", \"jwt\"]\nkeywords = [\"jwt_signing_key\"]\n\n[allowlist]\ndescription = \"Global allowlist\"\npaths = [\n '''(.*?)test(.*?)\\.py''',\n '''(.*?)_test\\.go''',\n '''(.*?)spec(.*?)\\.js''',\n '''(.*?)fixtures(.*?)''',\n '''README\\.md'''\n]\n\n[[rules.allowlist]]\nid = \"mycompany-api-key\"\nregexes = [\n '''MYCOMPANY-KEY-EXAMPLE[A-Za-z0-9]{24}''',\n '''MYCOMPANY-KEY-TEST[A-Za-z0-9]{28}'''\n]\n<\/code><\/pre>\nComprendre la Configuration<\/h3>\n\n- R\u00e8gles personnalis\u00e9es :<\/strong> Les sections
[[rules]]<\/code> d\u00e9finissent des motifs sp\u00e9cifiques \u00e0 votre organisation. Le champ regex<\/code> utilise des expressions r\u00e9guli\u00e8res compatibles Go. Le champ keywords<\/code> aide gitleaks \u00e0 filtrer rapidement les fichiers \u2014 seuls les fichiers contenant le mot-cl\u00e9 sont analys\u00e9s avec la regex compl\u00e8te, ce qui am\u00e9liore les performances.<\/li>\n- Liste d’autorisation globale :<\/strong> La section
[allowlist]<\/code> d\u00e9finit les chemins qui doivent \u00eatre exclus de toute analyse. Les fichiers de test, les fixtures et la documentation sont des exclusions courantes.<\/li>\n- Liste d’autorisation par r\u00e8gle :<\/strong> La section
[[rules.allowlist]]<\/code> d\u00e9finit des exceptions pour des r\u00e8gles sp\u00e9cifiques. Ici, nous excluons les cl\u00e9s d’exemple connues qui apparaissent dans la documentation ou les helpers de test.<\/li>\n<\/ul>\nTester la Configuration Personnalis\u00e9e<\/h3>\n
Cr\u00e9ez un fichier avec un secret personnalis\u00e9 pour tester :<\/p>\n
cat > internal-config.py <<'EOF'\nMYCOMPANY_API_KEY = \"MYCOMPANY-KEY-a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6\"\nEOF<\/code><\/pre>\nEx\u00e9cutez gitleaks avec la configuration personnalis\u00e9e :<\/p>\n
gitleaks detect --source . --config .gitleaks.toml -v<\/code><\/pre>\nLa r\u00e8gle personnalis\u00e9e d\u00e9tecte la cl\u00e9 API interne qui aurait \u00e9t\u00e9 manqu\u00e9e par les r\u00e8gles par d\u00e9faut.<\/p>\n
Construire une Strat\u00e9gie de D\u00e9fense en Profondeur<\/h2>\n
Aucune couche unique de d\u00e9tection de secrets n’est suffisante. Les d\u00e9veloppeurs peuvent ignorer les hooks pre-commit. Les analyses de pipeline ne d\u00e9tectent les secrets qu’au moment de la PR. GitHub push protection ne couvre que les motifs des fournisseurs connus. Une strat\u00e9gie robuste superpose toutes ces couches.<\/p>\n
Les Cinq Couches de D\u00e9fense des Secrets<\/h3>\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Couche 1 : Hook Pre-commit (gitleaks) \u2502\n\u2502 \u2192 Intercepte les secrets avant l'historique local \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Couche 2 : Analyse PR \/ Merge Request (gitleaks) \u2502\n\u2502 \u2192 Bloque les PR contenant des secrets \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Couche 3 : Push Protection (GitHub \/ GitLab) \u2502\n\u2502 \u2192 Blocage au niveau plateforme des motifs connus \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Couche 4 : Analyse Post-merge (truffleHog planifi\u00e9)\u2502\n\u2502 \u2192 Analyse approfondie hebdomadaire avec v\u00e9rification\u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Couche 5 : Surveillance Runtime (logs d'audit vault)\u2502\n\u2502 \u2192 D\u00e9tection d'anomalies d'utilisation des secrets \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n<\/code><\/pre>\nPourquoi Aucune Couche Unique ne Suffit<\/h3>\n\n- Les hooks pre-commit<\/strong> peuvent \u00eatre contourn\u00e9s avec
git commit --no-verify<\/code> ou en utilisant un client Git qui ne prend pas en charge les hooks.<\/li>\n- Les analyses de pipeline<\/strong> ne s’ex\u00e9cutent que sur les branches qui d\u00e9clenchent la CI \u2014 les push directs vers des branches non prot\u00e9g\u00e9es ou les force push peuvent les ignorer.<\/li>\n
- Push protection<\/strong> ne d\u00e9tecte que les motifs des fournisseurs connus \u2014 les secrets internes personnalis\u00e9s ne sont pas couverts.<\/li>\n
- Les analyses post-merge<\/strong> sont r\u00e9actives \u2014 elles trouvent les secrets apr\u00e8s qu’ils sont d\u00e9j\u00e0 dans le d\u00e9p\u00f4t.<\/li>\n<\/ul>\n
Chaque couche compense les faiblesses des autres. Ensemble, elles cr\u00e9ent un syst\u00e8me o\u00f9 un secret devrait contourner les cinq couches pour passer inaper\u00e7u.<\/p>\n
Workflow Combin\u00e9 : Analyse de PR et Analyse Compl\u00e8te Hebdomadaire<\/h3>\n
Voici un workflow GitHub Actions combin\u00e9 qui ex\u00e9cute gitleaks sur chaque PR et effectue une analyse compl\u00e8te du d\u00e9p\u00f4t chaque semaine :<\/p>\n
name: Secret Scanning (Multi-Layer)\n\non:\n push:\n branches: [main, develop]\n pull_request:\n branches: [main]\n schedule:\n # Full repository scan every Monday at 6:00 AM UTC\n - cron: '0 6 * * 1'\n\njobs:\n # Layer 2: PR and push scanning\n gitleaks-pr-scan:\n name: gitleaks PR Scan\n runs-on: ubuntu-latest\n if: github.event_name == 'push' || github.event_name == 'pull_request'\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Run gitleaks (diff scan)\n uses: gitleaks\/gitleaks-action@v2\n env:\n GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n\n # Layer 4: Weekly deep scan with truffleHog\n trufflehog-full-scan:\n name: truffleHog Full Repository Scan\n runs-on: ubuntu-latest\n if: github.event_name == 'schedule'\n steps:\n - name: Checkout code\n uses: actions\/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Install truffleHog\n run: pip install trufflehog\n\n - name: Run truffleHog (full scan with verification)\n run: |\n trufflehog git file:\/\/. --fail --json > trufflehog-results.json || true\n if [ -s trufflehog-results.json ]; then\n echo \"::error::Secrets detected in repository. See trufflehog-results.json.\"\n cat trufflehog-results.json | python -m json.tool\n exit 1\n fi\n\n - name: Upload scan results\n if: always()\n uses: actions\/upload-artifact@v4\n with:\n name: trufflehog-results\n path: trufflehog-results.json\n retention-days: 90\n<\/code><\/pre>\nCe workflow garantit que chaque modification de code est analys\u00e9e en temps r\u00e9el, et que l’ensemble de l’historique du d\u00e9p\u00f4t est audit\u00e9 chaque semaine pour d\u00e9tecter les secrets qui auraient pu passer inaper\u00e7us.<\/p>\n
Nettoyage<\/h2>\n
Apr\u00e8s avoir termin\u00e9 le lab, supprimez les secrets de test et r\u00e9initialisez le d\u00e9p\u00f4t :<\/p>\n
# Remove test files with secrets\nrm -f .env deploy.py config.yml Dockerfile internal-config.py\n\n# Remove test configurations (optional \u2014 keep if you want to reuse them)\n# rm -f .gitleaks.toml .pre-commit-config.yaml\n\n# Commit the cleanup\ngit add -A\ngit commit -m \"Remove test secrets from lab exercises\"\n\n# If you want to completely remove secrets from Git history,\n# use git-filter-repo (more thorough than git filter-branch):\npip install git-filter-repo\ngit filter-repo --invert-paths --path deploy.py --path .env --path config.yml --path Dockerfile\n<\/code><\/pre>\nImportant :<\/strong> La simple suppression de fichiers ne les retire pas de l’historique Git. Toute personne ayant acc\u00e8s au d\u00e9p\u00f4t peut encore trouver les secrets dans les commits pass\u00e9s. Utilisez git-filter-repo<\/code> pour r\u00e9\u00e9crire l’historique et supprimer d\u00e9finitivement les fichiers sensibles. Apr\u00e8s la r\u00e9\u00e9criture de l’historique, faites un force-push vers le remote et demandez \u00e0 tous les collaborateurs de re-cloner le d\u00e9p\u00f4t.<\/p>\nPoints Cl\u00e9s \u00e0 Retenir<\/h2>\n\n- Les secrets dans les pipelines CI\/CD sont le vecteur d’attaque le plus courant pour la compromission des pipelines.<\/strong> Un seul identifiant divulgu\u00e9 peut donner \u00e0 un attaquant un acc\u00e8s complet \u00e0 l’infrastructure de production.<\/li>\n
- Les hooks pre-commit avec gitleaks offrent la boucle de r\u00e9troaction la plus rapide.<\/strong> Les d\u00e9veloppeurs sont alert\u00e9s imm\u00e9diatement, avant que le secret n’entre dans l’historique Git.<\/li>\n
- L’analyse dans le pipeline est une couche d’application obligatoire.<\/strong> Elle ne peut pas \u00eatre contourn\u00e9e par les d\u00e9veloppeurs et garantit qu’aucune PR contenant des secrets n’est fusionn\u00e9e.<\/li>\n
- La capacit\u00e9 de v\u00e9rification de truffleHog r\u00e9duit consid\u00e9rablement les faux positifs.<\/strong> Utilisez-le pour les analyses approfondies planifi\u00e9es o\u00f9 la pr\u00e9cision compte plus que la vitesse.<\/li>\n
- GitHub push protection et le programme partenaire ajoutent une d\u00e9fense au niveau de la plateforme<\/strong> qui fonctionne sans aucune configuration dans vos pipelines CI\/CD.<\/li>\n
- Les r\u00e8gles de d\u00e9tection personnalis\u00e9es sont essentielles<\/strong> pour intercepter les secrets sp\u00e9cifiques \u00e0 l’organisation que les outils standards manqueront. Investissez du temps dans l’\u00e9criture de r\u00e8gles pour vos formats de cl\u00e9s internes.<\/li>\n
- La d\u00e9fense en profondeur est la seule strat\u00e9gie fiable.<\/strong> Aucun outil ou couche unique ne d\u00e9tecte tout. Combinez pre-commit, analyse dans le pipeline, push protection, analyses planifi\u00e9es et surveillance runtime pour une couverture compl\u00e8te.<\/li>\n<\/ul>\n
Prochaines \u00c9tapes<\/h2>\n
Maintenant que vous savez d\u00e9tecter et pr\u00e9venir les fuites de secrets, l’\u00e9tape suivante est d’\u00e9liminer compl\u00e8tement les secrets cod\u00e9s en dur en adoptant une gestion appropri\u00e9e des secrets :<\/p>\n
\n- Gestion des Secrets dans les Pipelines CI\/CD<\/a> \u2014 Apprenez \u00e0 utiliser HashiCorp Vault, AWS Secrets Manager et les magasins de secrets natifs CI\/CD pour injecter des secrets \u00e0 l’ex\u00e9cution sans jamais les stocker dans le code.<\/li>\n
- Identifiants \u00c9ph\u00e9m\u00e8res et Workload Identity Federation<\/a> \u2014 \u00c9liminez compl\u00e8tement les secrets \u00e0 longue dur\u00e9e de vie en utilisant la f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail bas\u00e9e sur OIDC pour authentifier les pipelines aupr\u00e8s des fournisseurs cloud sans aucun identifiant stock\u00e9.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Vue d’ensemble Les fuites de secrets dans les pipelines CI\/CD sont la cause num\u00e9ro un de compromission des pipelines. Les identifiants expos\u00e9s \u2014 cl\u00e9s API, mots de passe de bases de donn\u00e9es, jetons d’acc\u00e8s cloud \u2014 offrent aux attaquants un acc\u00e8s direct aux syst\u00e8mes de production. Selon le rapport 2025 State of Secrets Sprawl de … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,51],"tags":[],"post_folder":[],"class_list":["post-520","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-pipeline-hardening"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/520","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/comments?post=520"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/520\/revisions"}],"predecessor-version":[{"id":576,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/520\/revisions\/576"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=520"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}