Les secrets n’expirent pas lorsque vous les supprimez : nettoyer l’historique Git

En bref : Une clé API divulguée et enregistrée dans un dépôt reste dans l’historique bien après la suppression du fichier. La détection, la rotation et la réécriture de l’historique sont toutes indispensables — la suppression seule procure un faux sentiment de sécurité.

Le piège du commit de suppression

Lorsqu’un développeur remarque un identifiant sensible enregistré dans un commit, son premier réflexe est de supprimer la ligne et de pousser un correctif. Mais le secret reste présent dans l’historique Git et peut être récupéré par toute personne disposant d’un accès au clone. Si le dépôt a un jour été public ou répliqué, considérez le secret comme compromis dès l’instant où il a été poussé.

La seule hypothèse sûre consiste à considérer qu’un secret divulgué reste actif jusqu’à sa rotation.

La véritable séquence de remédiation

• Effectuez immédiatement la rotation de l’identifiant — considérez-le comme compromis, et non simplement exposé.
• Révoquez la clé divulguée et vérifiez si elle a été utilisée pendant la période d’exposition.
• Réécrivez l’historique afin d’éliminer le secret de tous les commits accessibles et forcez l’actualisation des répliques.
• Ajoutez une analyse des secrets avant les commits et dans la CI/CD afin que la prochaine fuite soit détectée avant d’être enregistrée.

La détection doit être continue

Les fuites de secrets ne se résument pas à un nettoyage ponctuel ; elles constituent un problème de détection permanent. Une analyse effectuée uniquement au moment du commit ne détecte pas les secrets poussés par d’autres voies, tandis qu’une analyse limitée à l’historique ne détectera pas l’erreur de demain. Les deux sont essentielles.

L’analyse de KENSAI met en évidence les identifiants exposés avec le contexte nécessaire pour prioriser leur rotation — quelle clé est concernée, où elle est accessible et quel est le degré d’urgence de l’exposition.

À quoi ressemble une bonne hygiène en pratique

Considérez tout secret ayant un jour été présent dans un dépôt comme déjà exposé et concevez vos systèmes de façon à ce que cette exposition reste maîtrisable. Des identifiants à courte durée de vie, dont la rotation est automatisée, transforment une clé divulguée en un problème qui expire de lui-même, plutôt qu’en une porte ouverte pendant des mois.

Anticipez la détection grâce à des hooks de pré-commit et de pré-réception qui bloquent un secret avant même qu’il ne soit enregistré, et complétez-les par une analyse côté serveur qui détecte ce qui leur échappe. L’objectif n’est pas un nettoyage ponctuel, mais un contrôle permanent qui rend les nouvelles fuites rares, visibles et rapidement révocables.

À retenir

Supprimer un secret divulgué est l’étape la moins importante. Effectuez d’abord sa rotation, purgez ensuite l’historique et mettez en place une détection continue afin de réduire les périodes d’exposition plutôt que de les voir se répéter.