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 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 publier 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 que le secret est compromis dès sa publication.

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

La véritable procédure 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 de supprimer le secret de tous les commits accessibles et forcez l’actualisation des miroirs.
• Ajoutez une analyse des secrets avant commit et dans la CI/CD afin que la prochaine fuite soit détectée avant son enregistrement.

La détection doit être continue

Les fuites de secrets ne se résolvent pas par un nettoyage ponctuel ; elles nécessitent une détection continue. Une analyse effectuée uniquement lors des commits ne détecte pas les secrets publiés par d’autres moyens, tandis qu’une analyse limitée à l’historique ne détectera pas l’erreur de demain. Les deux sont essentielles.

L’analyse de KENSAI révèle les identifiants exposés avec le contexte nécessaire pour prioriser leur rotation — la clé concernée, son emplacement 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, renouvelés automatiquement, 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 son enregistrement, puis associez-les à une analyse côté serveur pour détecter 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 rapides à révoquer.

À 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 au lieu de les voir se répéter.