Un secret a été committé : pourquoi supprimer le fichier ne suffit pas, et dans quel ordre réagir

Objectif

Contenir un identifiant qui a été committé dans un dépôt, dans l'ordre qui limite les dégâts, y compris lorsque c'est un agent qui a fait le commit.

Prérequis

Les droits pour révoquer l'identifiant chez son émetteur ; un accès en écriture au dépôt ; un accès aux journaux d'utilisation de l'émetteur.

Étapes

1. Révoquer ou faire tourner l'identifiant en premier. Les recommandations de GitHub sur la suppression de données sensibles conseillent de considérer le secret comme compromis et de le faire tourner ; la réécriture de l'historique vient après. Partir du principe que des scanners automatisés surveillent les push publics.
2. Déployer l'identifiant de remplacement vers chaque consommateur légitime. Les consommateurs qui se cassent révèlent où l'ancien était utilisé.
3. Vérifier dans les journaux de l'émetteur si l'ancien identifiant a été utilisé depuis l'instant du commit, depuis des adresses inattendues ou avec des actions inhabituelles. Consigner ce qui est trouvé.
4. Retirer le fichier de l'arborescence actuelle et l'ajouter à .gitignore s'il ne doit jamais être suivi.
5. Si le dépôt l'exige, réécrire l'historique avec un outil conçu à cet effet ; GitHub documente git-filter-repo pour cela. Se coordonner avec les personnes qui collaborent : chaque clone doit être re-cloné ou rebasé, et d'anciennes branches repoussées réintroduiraient le secret.
6. Demander à l'hébergeur de purger les vues en cache et les références de pull request, si son processus le permet ; les forks et les clones existants restent hors de contrôle.
7. Rechercher dans les journaux de CI, les artefacts de build, les images de conteneurs et les messages de discussion susceptibles d'avoir capturé la valeur.
8. Ajouter un scanner de secrets en pre-commit ou au moment du push pour éviter la récidive, et consigner l'incident avec les horaires.

Résultat attendu

La valeur exposée est inutilisable avant même que le nettoyage ne commence ; l'historique est nettoyé là où cela compte ; on sait si l'identifiant a été utilisé.

Limites et base de vérification

La réécriture de l'historique ne peut pas rappeler les copies déjà faites ; la révocation est la seule étape qui les neutralise. Certains secrets (clés de signature, certificats de longue durée) nécessitent une réémission et une redistribution de la confiance, ce qui prend plus de temps que de faire tourner une clé d'API.