Une clé d’API dans l’historique Git : les 7 étapes de gestion des secrets que j’aurais aimé appliquer avant

Le scénario est banal au point d’en être ennuyeux. Un fichier de configuration ajouté « temporairement » pendant une phase d’intégration, avec une clé d’API en clair dedans. Le fichier est retiré trois jours plus tard par un commit propre, avec un message explicite. Tout le monde passe à autre chose.

Six mois après, un développeur qui reprend le projet remonte l’historique pour comprendre l’origine d’un paramètre, et retrouve la clé. Toujours valide. Utilisée en production. Le commit de retrait n’avait rien retiré du tout : il avait seulement rendu le problème invisible dans l’état courant du dépôt.

Voici les sept étapes dans l’ordre où je les appliquerais aujourd’hui. Cet ordre compte beaucoup : les équipes commencent presque toujours par l’étape 4 — choisir un outil de chiffrement — alors que les étapes 1 et 2 déterminent si le reste servira à quelque chose.

Étape 1 — Inventorier les secrets, historique compris

L’inventaire ne porte pas sur l’état actuel du dépôt mais sur tout ce qu’il a contenu. C’est une distinction essentielle : la question n’est pas « quels secrets sont dans le code » mais « quels secrets ont un jour été poussés quelque part ».

Passez l’historique complet dans un détecteur de secrets — plusieurs outils libres font cela correctement — et acceptez le bruit. Un premier passage remonte beaucoup de faux positifs : chaînes de test, exemples de documentation, valeurs factices. Trier prend quelques heures et c’est du temps bien investi, parce que le résultat devient votre liste de travail pour l’étape 2.

Élargissez ensuite le périmètre au-delà du dépôt principal. Les endroits qui ressortent le plus souvent : les variables de configuration de l’intégration continue, les fichiers de déploiement, les carnets d’analyse de données, les tickets et les messageries d’équipe où un identifiant a été collé « en attendant », et les images de conteneurs dont une couche intermédiaire conserve un fichier pourtant supprimé plus loin.

Le piège : croire que le dépôt privé protège. Un dépôt privé restreint l’accès, il ne le supprime pas — il reste lisible par tous les collaborateurs actuels et passés, par les intégrations tierces autorisées, et par toute copie locale. Comptez une à deux journées.

Étape 2 — Classer par sensibilité et par coût de rotation

Le réflexe est de classer par sensibilité. C’est nécessaire mais insuffisant, car cela ne dit rien de ce que vous ferez concrètement le jour où il faudra agir vite. Ajoutez donc une seconde dimension, plus opérationnelle : combien coûte la rotation de ce secret.

Une clé d’API tierce se change en cinq minutes depuis une console. Un certificat client partagé avec un partenaire implique une coordination externe et une fenêtre planifiée. Une clé de chiffrement de données au repos impose un déchiffrement puis un rechiffrement de l’existant. Ces trois secrets peuvent être également sensibles et appeler des stratégies radicalement différentes.

Le croisement des deux axes donne une matrice utile. Les secrets très sensibles et coûteux à changer sont les vrais dangers : ce sont eux qu’il faut sortir en priorité des endroits partagés, parce que si l’un fuit, la réponse d’urgence sera lente. Les secrets peu coûteux à changer peuvent, eux, être mis en rotation automatique agressive sans réflexion supplémentaire.

Le piège : découvrir en pleine urgence qu’un secret réputé simple est en réalité utilisé par quatre services dont deux n’ont pas de propriétaire identifié. Notez, pour chaque secret, qui le consomme. Comptez une demi-journée.

Étape 3 — Choisir entre chiffrement versionné et coffre centralisé

Le débat est souvent posé comme un choix exclusif alors qu’il s’agit de deux réponses à deux cycles de vie distincts.

Le chiffrement de fichiers versionnés convient à la configuration qui suit le rythme du code : elle est relue en revue de code, elle est versionnée avec la fonctionnalité qui l’introduit, elle est déployée en même temps qu’elle. L’avantage décisif est la traçabilité — vous savez qui a modifié quoi et quand, avec le même outillage que pour le code.

Un coffre centralisé convient aux secrets d’exécution à durée de vie courte, à rotation fréquente, ou générés dynamiquement à la demande. Son avantage est la révocation immédiate et centralisée, ainsi que la capacité à délivrer des identifiants temporaires plutôt que permanents.

Pour une équipe de moins d’une dizaine de personnes, démarrer avec le chiffrement versionné seul est un choix parfaitement défendable. Le coffre s’ajoute quand la rotation devient assez fréquente pour que le passage par un commit soit une gêne réelle. Introduire un coffre trop tôt ajoute une infrastructure critique à exploiter — et un point de panne au démarrage de vos services. Comptez une demi-journée de décision.

Étape 4 — Chiffrer les fichiers de configuration avec SOPS et age

C’est l’étape la plus concrète, et la plus rapide à mettre en place. L’idée est de garder les fichiers de configuration dans le dépôt, mais avec les valeurs chiffrées et les clés en clair.

Cette propriété a une conséquence pratique majeure et souvent sous-estimée : une revue de code reste lisible. On voit qu’une entrée a été ajoutée, renommée ou supprimée, sans voir sa valeur. Un fichier intégralement chiffré, à l’inverse, produit une différence illisible à chaque modification, ce qui décourage la revue et pousse à tout approuver sans regarder.

L’association de SOPS avec age est aujourd’hui la combinaison la plus simple à administrer pour une équipe de taille modeste. Le chiffrement s’adresse à un ensemble de clés publiques, une par personne ou par environnement, ce qui rend l’ajout et le retrait d’un membre explicites : on modifie la liste des destinataires et on rechiffre.

Trois règles qui évitent les ennuis. Premièrement, chiffrez pour des destinataires distincts par environnement — la clé de production ne doit pas déchiffrer la configuration de développement, et surtout l’inverse. Deuxièmement, versionnez le fichier de règles à côté du code, afin que le chiffrement soit appliqué automatiquement aux bons chemins sans dépendre de la vigilance de chacun. Troisièmement, quand une personne quitte l’équipe, retirer sa clé publique ne suffit pas : elle a pu déchiffrer avant son départ, donc les secrets concernés doivent être renouvelés.

Le piège : chiffrer le fichier mais laisser la clé privée traîner dans le dépôt d’infrastructure « pour que l’intégration continue puisse déchiffrer ». C’est l’équivalent de fermer la porte et de scotcher la clé dessus. La clé de déchiffrement de l’intégration continue doit venir du magasin de secrets de la plateforme, jamais du dépôt. Comptez une journée.

Étape 5 — Distribuer les secrets d’exécution sans les exposer

Le secret chiffré au repos doit bien, à un moment, exister en clair dans le processus qui l’utilise. C’est ce dernier mètre qui est le plus souvent négligé.

Les variables d’environnement sont la solution la plus courante et elles sont acceptables, à condition de savoir où elles fuient. Elles apparaissent dans l’inspection d’un conteneur, dans les traces d’erreur des outils qui capturent l’environnement complet au moment d’une exception, et parfois dans les journaux de démarrage d’un applicatif verbeux.

Deux mesures réduisent fortement ce risque. Configurez une liste d’exclusion explicite dans votre outil de suivi d’erreurs, en filtrant par motif de nom plutôt qu’en énumérant les variables une par une — la liste énumérée n’est jamais à jour. Et pour les secrets de la case rouge de l’étape 2, préférez le montage d’un fichier en lecture seule à une variable d’environnement : un fichier ne se retrouve pas accidentellement dans une trace d’erreur.

À éviter absolument : passer un secret en argument de ligne de commande. Il devient visible dans la liste des processus de la machine, pour tout utilisateur local. C’est aussi vrai dans un conteneur que sur un serveur classique. Comptez une demi-journée.

Étape 6 — Automatiser la rotation en commençant par le moins risqué

La rotation est l’étape que tout le monde reporte, parce qu’elle fait peur : changer un identifiant en production, c’est risquer une coupure. Cette crainte est légitime, et c’est précisément pourquoi il faut commencer par les cas où elle ne s’applique pas.

Prenez les secrets de la case « peu sensible, facile à changer » et mettez-les en rotation automatique. L’objectif de ce premier tour n’est pas la sécurité, il est de vérifier que votre chaîne de rotation fonctionne : que le nouveau secret se propage, que les services le rechargent, que rien ne conserve l’ancien en mémoire indéfiniment.

La difficulté technique réelle est presque toujours la même : les applications lisent leurs secrets au démarrage et ne les relisent jamais. Une rotation impose alors un redémarrage, ce qui transforme une opération de routine en intervention planifiée. Deux solutions existent — soit prévoir un rechargement à chaud, soit accepter le redémarrage et s’assurer qu’il est indolore grâce à un déploiement progressif.

La règle qui rend la rotation sûre est la période de recouvrement : l’ancien et le nouveau secret doivent être valides simultanément pendant un intervalle suffisant. Sans recouvrement, toute rotation est une coupure. La plupart des fournisseurs permettent d’avoir deux clés actives en même temps ; c’est exactement l’usage prévu. Comptez deux à trois jours pour la première chaîne, puis quelques heures par secret supplémentaire.

Étape 7 — Mettre en place une détection continue

Tout ce qui précède est un nettoyage. Sans cette dernière étape, l’état d’origine revient en quelques mois, parce qu’une personne pressée finira par coller une valeur en clair « juste pour tester ».

La détection s’installe à trois niveaux, et les trois sont utiles. Avant le commit, un crochet local qui refuse un secret détecté — c’est le plus confortable, car rien n’est jamais poussé, mais il est contournable et dépend de l’installation locale de chacun. Côté serveur, une analyse à chaque poussée, qui elle n’est pas contournable. Et périodiquement sur tout l’historique, pour attraper ce qui est entré avant la mise en place.

Le piège du détecteur trop bruyant : un outil qui remonte trente faux positifs par semaine sera désactivé en un mois, et vous serez moins protégés qu’avant puisque tout le monde se croira couvert. Investissez dans la configuration des exclusions dès le premier jour, et traitez chaque faux positif récurrent comme un défaut à corriger.

Prévoyez enfin une procédure écrite de réaction, tenant en une page : qui révoque, dans quel ordre, qui prévient les tiers concernés. Sur ce point, les équipes de WebGuard Agency observent que le facteur déterminant en cas de fuite n’est pas la détection mais le délai entre la détection et la révocation. Comptez une journée.

Les trois erreurs que je vois le plus souvent

Croire que retirer le fichier règle le problème. C’est l’erreur fondatrice, celle de l’anecdote d’introduction. Un commit de suppression ne supprime rien : la valeur reste dans l’historique, dans les clones, dans les caches d’intégration continue. La seule action qui neutralise un secret exposé est sa révocation. Réécrire l’historique est un nettoyage utile, jamais un substitut.

Commencer par l’outillage plutôt que par la rotation. Installer un coffre prend deux semaines, pendant lesquelles les clés déjà exposées restent parfaitement valides. L’ordre efficace est de révoquer d’abord ce qui donne accès à des données ou à de la dépense, puis d’outiller pour empêcher la récidive.

Confondre chiffré et protégé. Un fichier chiffré dont la clé de déchiffrement est accessible à tout le monde n’apporte qu’un confort psychologique. À chaque fois que vous ajoutez du chiffrement, posez la question suivante : qui peut déchiffrer, et cette liste est-elle plus courte que celle des personnes ayant accès au dépôt ? Si la réponse est non, vous avez ajouté de la complexité sans réduire le risque.

Ces réflexes valent quel que soit le type de projet, qu’il s’agisse d’une application fintech soumise à des exigences réglementaires ou d’une marketplace plus classique. La différence porte sur le niveau de preuve à produire, pas sur la méthode.

Questions fréquentes

Supprimer un secret commité par erreur suffit-il ?

Non. Un commit qui retire la ligne laisse la valeur intacte dans l’historique, accessible par n’importe qui ayant accès au dépôt ou à une copie. Réécrire l’historique est possible mais ne récupère pas les clones déjà distribués, les caches d’intégration continue ni les sauvegardes. La seule mesure qui protège réellement est la révocation puis la rotation du secret concerné. La réécriture d’historique est une opération de nettoyage complémentaire, jamais un substitut à la rotation.

Faut-il un coffre dédié ou le chiffrement de fichiers versionnés suffit-il ?

Les deux répondent à des besoins différents et coexistent très bien. Le chiffrement de fichiers versionnés, avec SOPS et age par exemple, convient à la configuration qui suit le cycle de vie du code : elle est relue en revue, versionnée avec la fonctionnalité, déployée avec elle. Un coffre centralisé convient aux secrets d’exécution à durée de vie courte et à rotation fréquente, ainsi qu’aux identifiants générés dynamiquement. Une petite équipe démarre très bien avec le chiffrement versionné seul, et n’ajoute un coffre que lorsque la rotation devient contraignante.

Les variables d’environnement sont-elles un mauvais moyen de passer des secrets ?

Elles sont acceptables mais elles fuient plus facilement qu’on ne le croit. Une variable d’environnement apparaît dans l’inspection d’un conteneur, souvent dans les traces d’erreur qui capturent l’environnement complet, et parfois dans les journaux de démarrage d’un applicatif verbeux. Si vous les utilisez, filtrez explicitement les variables sensibles dans votre outil de suivi d’erreurs, et préférez le montage d’un fichier en lecture seule pour les secrets les plus critiques.

Par où commencer quand tout est déjà en clair dans le dépôt ?

Par la rotation des secrets les plus exposés, pas par l’outillage. Beaucoup d’équipes commencent par installer un coffre, ce qui prend deux semaines pendant lesquelles les clés compromises restent valides. L’ordre utile est inverse : identifier les secrets présents dans l’historique, révoquer et faire tourner ceux qui donnent accès à des données ou à de la dépense, puis seulement mettre en place l’outillage qui empêche la récidive.

En résumé

La gestion des secrets échoue rarement par manque d’outils. Elle échoue parce que l’inventaire n’a jamais été fait, parce que la rotation n’a jamais été testée à froid, et parce que la détection a été désactivée après trois semaines de faux positifs.

Si vous ne deviez retenir que deux étapes, prenez la première et la sixième. L’inventaire sur l’historique complet vous dit ce qui est réellement exposé aujourd’hui — presque toujours davantage que prévu. Et une chaîne de rotation éprouvée sur des secrets sans enjeu transforme le jour de l’incident en procédure connue, au lieu d’une improvisation sous pression.