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 — supprimer le fichier seul procure un faux sentiment de sécurité.

Le piège de la suppression suivie d’un commit

Lorsqu’un développeur remarque qu’un identifiant a été enregistré, son premier réflexe est de supprimer la ligne et de pousser un correctif. Mais le secret demeure 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 déjà été public ou répliqué, considérez que le secret est compromis dès qu’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 pas seulement comme 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 pour supprimer le secret de tous les commits accessibles et forcez l’actualisation des miroirs.
• Ajoutez une analyse des secrets en pré-commit et dans la CI 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ésolvent pas par 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 et fournit le contexte nécessaire pour prioriser leur rotation — la clé concernée, l’endroit où elle est accessible et le degré d’urgence de l’exposition.

À quoi ressemblent de bonnes pratiques concrètes

Considérez tout secret ayant un jour été enregistré dans un dépôt comme déjà exposé et concevez vos systèmes pour qu’ils puissent résister à cette exposition. Des identifiants à courte durée de vie et soumis à une rotation automatique 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.

Déplacez la détection en amont 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 pour détecter ce qui passe entre les mailles du filet. L’objectif n’est pas un nettoyage ponctuel, mais un contrôle permanent qui rend les nouvelles fuites rares, visibles et rapides à révoquer.

À retenir

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