Prévenir les secrets codés en dur dans Git

Prévenir les secrets codés en dur dans Git

Une clé d’accès codée en dur n’est pas une erreur de débutant, c’est une erreur de délai. Le développeur doit débloquer un test, colle une valeur dans un fichier, valide le changement, puis le dépôt conserve cette décision provisoire avec la ténacité administrative d’une moisissure.

Explication de la marmotte

Un secret dans un projet ressemble à un double de clé laissé sous le paillasson pour rentrer vite un soir. Il rend service quelques minutes, puis devient une invitation permanente pour toute personne qui sait où regarder. Le but est de permettre le travail sans transformer chaque fichier partagé en trousseau abandonné.

→ Lire l’explication complète de la marmotte

Secrets codés en dur : le compromis à assumer

Un secret est une donnée dont la possession donne un pouvoir : mot de passe, jeton d’accès, clé privée, chaîne de connexion contenant un mot de passe, clé d’Interface de programmation applicative (API), certificat client ou graine cryptographique. Le secret codé en dur place cette donnée dans le code, un fichier de configuration versionné ou une variable définie dans un pipeline.

Le compromis est net : on gagne quelques secondes lors du test local, on paie une exposition potentiellement illimitée. Cette dette ne se rembourse pas en supprimant une ligne après le commit. Git conserve les objets historiques, les forks, les clones locaux, les archives de pipeline et parfois les journaux de débogage. Un dépôt privé limite l’audience, il ne transforme pas une fuite en non-événement.

La position à tenir est donc stricte : aucun secret de production ni secret réutilisable ne doit être présent dans l’arbre versionné, même chiffré avec une clé disponible dans le même dépôt. Chiffrer une clé dans un coffre posé juste à côté de la combinaison est un concept qui survit surtout dans les slides de vendeurs.

Les valeurs de démonstration sont acceptables seulement si elles ne donnent accès à rien : identifiants factices, certificats auto-signés dédiés aux tests, clés générées à la volée par la suite de tests. Une valeur commençant par example_ mais active chez un fournisseur n’est pas un exemple. C’est un incident qui a choisi une police de caractères rassurante.

La prévention commence par une alternative praticable. Si récupérer un secret exige cinq tickets, trois portails et une incantation devant un comité de gouvernance, le secret finira dans config.ts. L’environnement de développement doit fournir un mécanisme local documenté, rapide et distinct des secrets de production.

Environnement de développement et source de vérité des secrets

Le dépôt doit contenir un fichier modèle, par exemple .env.example, avec les noms de variables mais jamais leurs valeurs. Le fichier .env réel doit être ignoré par Git et créé localement à partir de ce modèle. Cela ne protège pas contre un git add -f, mais réduit le chemin menant à l’erreur. La prévention sans ergonomie est une règle affichée au mur.

Pour les développeurs, la source de vérité doit être un gestionnaire de secrets central, un coffre d’équipe ou un outil local qui injecte les valeurs au lancement. Un service de gestion de clés (KMS, Key Management Service) peut protéger des clés maîtresses, mais il ne remplace pas un mécanisme de distribution des secrets applicatifs : il faut aussi une identité, des droits, une journalisation et une politique de durée de vie.

Les prérequis minimaux sont les suivants :

• Git doit être installé sur les postes et les agents d’intégration continue.
• Le langage ou l’outil de lancement doit charger des variables d’environnement sans les afficher dans les journaux.
• Les fichiers locaux contenant des secrets doivent être exclus par .gitignore et protégés par les permissions du système.
• Le gestionnaire de secrets doit proposer des identités distinctes pour le développement, les tests, l’intégration continue et la production.
• Les valeurs de production ne doivent jamais être distribuées aux environnements de développement par commodité.

Les permissions sur un fichier .env ne compensent pas une machine compromise. Elles empêchent surtout les lectures accidentelles par d’autres comptes locaux. La frontière de sécurité reste l’identité qui autorise la lecture du secret auprès du coffre, ainsi que la durée de validité de l’autorisation.

Les secrets longs, tels que les clés privées, ne doivent pas être copiés dans les variables d’environnement si un montage de fichier à durée limitée ou une référence de coffre est disponible. Une variable d’environnement peut être lue par des processus enfants, des outils de diagnostic et certains dumps mémoire. Elle est pratique, pas magique. Les fondations de la gestion de clés restent valables avant même que le premier fichier source existe.

Hook de pré-commit et détection avant le dépôt

Un hook de pré-commit est un script exécuté localement avant la création d’un commit. Son rôle est de bloquer le changement tant qu’un détecteur identifie un motif de secret. Il doit scanner le contenu indexé, pas seulement les fichiers présents sur le disque : ce qui entre dans le commit est le sujet, pas le désordre du répertoire de travail.

Gitleaks est un détecteur de motifs et d’entropie couramment utilisé. Les règles détectent notamment les préfixes connus de fournisseurs, les paires clé=valeur, les clés privées au format Privacy-Enhanced Mail (PEM) et des chaînes à entropie élevée. Il faut épingler sa version, vérifier son empreinte de distribution et versionner la configuration. Installer un binaire flottant depuis Internet à chaque commit ajoute une loterie à la chaîne de confiance.

Exemple : hook Git avec Gitleaks

Le dépôt peut distribuer le hook et imposer un répertoire partagé via la configuration Git. La commande suivante suppose que le binaire gitleaks est installé sur le poste, avec une version approuvée par l’équipe.

# Activer les hooks versionnés du dépôt.
git config core.hooksPath .githooks

# Créer .githooks/pre-commit puis le rendre exécutable.
#!/bin/sh
set -eu

# Scanner uniquement l'index Git avant de créer le commit.
# --redact évite d'afficher la valeur détectée dans le terminal.
gitleaks protect --staged --redact --config .gitleaks.toml

La configuration .gitleaks.toml doit contenir des règles locales pour les formats internes, ainsi que des exceptions justifiées. Une exception doit viser une empreinte précise, un fichier précis ou une règle précise. Exclure .* ou désactiver la règle d’entropie pour faire passer une chaîne est une capitulation avec syntaxe TOML.

Le hook local n’est pas une frontière de sécurité. Il peut être ignoré avec git commit --no-verify, il n’existe pas forcément sur une machine fraîche et il ne couvre pas les interfaces graphiques mal configurées. Son intérêt est de détecter l’erreur au moment où son coût est faible. La même analyse doit être exécutée dans l’intégration continue et le déploiement continu (CI/CD, Continuous Integration/Continuous Delivery), où son échec bloque la fusion ou le pipeline.

Le scan de CI/CD doit masquer les valeurs dans les sorties, conserver le nom de la règle déclenchée et le chemin concerné, mais ne jamais réimprimer le secret trouvé. Un outil de détection qui copie le secret dans un journal centralisé a trouvé une manière créative d’étendre la fuite.

Scan de l’historique Git et dette de secrets

Supprimer un secret du fichier courant ne le retire pas de l’historique. Un scan récurrent doit parcourir toutes les références accessibles, y compris les branches anciennes et les tags. Cela détecte les fuites antérieures, les secrets ajoutés avant l’installation du hook et les contournements volontaires ou accidentels.

Une exécution planifiée peut utiliser une commande de ce type :

# Scanner tout l'historique accessible du dépôt.
# Le rapport ne doit pas être publié s'il contient des extraits non masqués.
gitleaks detect --source . --log-opts="--all" --redact --report-format json \
  --report-path gitleaks-history.json

Le rapport doit alimenter un traitement d’incident, pas une boîte aux lettres oubliée. Les faux positifs se traitent par une règle étroite et révisée. Les ignorer dans un fichier de base de référence sans date d’expiration transforme le scanner en décoration de conformité.

Le scan historique paie un coût de calcul et génère des alertes sur des valeurs anciennes, parfois déjà révoquées. Ce coût est justifié : l’historique est un canal de distribution. Toute personne ayant cloné le dépôt avant le nettoyage conserve les objets concernés. Les pratiques de développement sécurisé doivent donc traiter le dépôt comme une zone de diffusion, pas comme un disque local avec synchronisation améliorée.

Fuite avérée : révocation, confinement et réécriture

Dès qu’un secret actif apparaît dans un dépôt, y compris privé, la première action est sa révocation ou sa rotation auprès de son émetteur. Une clé d’API doit être désactivée puis remplacée. Un mot de passe doit être changé. Un certificat client doit être révoqué si l’autorité de certification le permet, puis remplacé. Une clé privée de signature exige la génération d’une nouvelle paire de clés et la mise à jour des vérificateurs.

Supprimer le commit, réécrire l’historique ou rendre le dépôt privé ne révoque rien. Ces actions réduisent l’exposition future, elles ne retirent pas la copie d’un clone, d’un cache, d’une archive ou d’une capture de journal. La révocation vient donc avant le nettoyage Git. Toujours.

Après révocation, il faut identifier le périmètre : branches, tags, forks, archives de CI/CD, journaux, artefacts, miroirs et postes ayant cloné le dépôt. Ensuite seulement, réécrire l’historique avec un outil dédié, forcer la mise à jour des références distantes et demander aux détenteurs de clones de repartir d’une copie propre. Cette opération casse les références locales et les requêtes en cours. C’est acceptable : le secret compromis a déjà cassé le contrat de confiance.

La supervision doit corréler la date d’exposition avec les journaux d’utilisation du secret. Une révocation arrête l’usage futur, elle n’efface pas les actions déjà effectuées. Les droits associés au secret déterminent la suite : lecture seule limitée, écriture sur un dépôt, accès à une base de données ou capacité de signature ne déclenchent pas la même investigation.

La rotation planifiée réduit la fenêtre de validité, mais ne dispense jamais de révoquer. Une rotation mensuelle d’un jeton exposé aujourd’hui laisse plusieurs semaines à un attaquant. La rotation est une mesure d’exploitation, la révocation est une réponse d’urgence.

🐝 Ce qui arrive si on s’en passe

Sans détection en amont, le secret ne reste pas dans un fichier : il se recopie dans les images de conteneurs, les caches de construction, les artefacts de pipeline, les miroirs et les forks, autant de supports que personne n’inventorie. Les dépôts publics sont balayés en continu par des robots, et un jeton valide peut être employé avant même la fin de la revue. Faute d’identités distinctes par environnement, l’usage frauduleux se confond avec le trafic légitime dans les journaux du fournisseur : ni imputation, ni datation de la première utilisation. Sans inventaire des secrets, la rotation devient impossible à planifier, puisque la liste des valeurs actives et de leurs porteurs n’existe nulle part. Et la découverte tardive impose une réécriture d’historique en urgence, qui invalide tous les clones et toutes les branches en cours.

🦫 Explication de la marmotte 🍫

Un secret est une information qui permet d’accéder à un service ou de prouver une identité. Il peut s’agir d’un mot de passe, d’une clé privée ou d’une chaîne donnant accès à une base de données. Le code source est copié entre postes, serveurs de test, archives et outils de travail. Une valeur inscrite dans ce code peut donc rester accessible longtemps après sa suppression visible.

Pour éviter cela, le projet garde seulement les noms des réglages attendus. Les valeurs réelles restent sur le poste de développement ou dans un service réservé à leur stockage. Au lancement du programme, les valeurs sont fournies temporairement au programme sans être ajoutées aux fichiers partagés.

Avant chaque enregistrement de modification, un programme de contrôle recherche des formes connues de secrets et des longues chaînes inhabituelles. Il bloque l’enregistrement si une valeur suspecte apparaît. Un second contrôle parcourt régulièrement toutes les anciennes versions du projet, car supprimer un fichier ne supprime pas automatiquement son contenu de l’historique.

Si un secret actif est trouvé, il faut d’abord le désactiver et en créer un nouveau. Nettoyer l’historique vient ensuite, car des copies du projet peuvent déjà exister ailleurs. Enfin, il faut vérifier les traces d’utilisation du secret : une désactivation empêche les accès futurs, mais ne révèle pas seule ce qui a été fait avant sa découverte.

À lire aussi

• Comptes de service Git à révoquer réellementLes comptes de service Git accumulent des identités et jetons persistants qui échappent souvent à la révocation, à l'inventaire et à la supervision.
• Durcir les postes de développeurs contre le vol de code et secretsLes postes de développeurs constituent une cible souvent oubliée du durcissement, alors qu’ils concentrent code source, identités, secrets et accès de production.
• Protéger les branches Git et permissions entrepriseGestion des branches et des permissions Git en entreprise comme surface de sécurité, protection de la branche principale et revue obligatoire avant fusion.
• Intégration continue avec Git : automatiser vos workflowsGuide technique sur l'intégration continue avec Git, détaillant les configurations, cas d'usage, risques et bonnes pratiques pour automatiser vos workflows.

Pages voisines

La citent

• Attributs du cookie de session
• Écrire des scripts Bash système fiables et sûrs en production
• Écrire un outil jetable proprement, sans faille ni dette
• JavaScript et SQL côté web, ce qu'il faut savoir des deux langages
• Python pour l'automatisation défensive, usages et garde-fous
• OSINT défensif : mesurer et réduire l'exposition publique
• Tester, auditer, répondre et migrer
• Transformer mots de passe et secrets applicatifs en clés

Prévenir les secrets codés en dur dans Git

Elle cite

• Gestion des secrets applicatifs distribués avec rotation
• Installation locale : guide complet pour déployer un site en local
• Les secrets dans les dépôts Git