Retire un secret et comprends les limites de la réécriture

L’idée reçue

« J’ai supprimé le fichier dans le commit suivant, donc le token n’existe plus. »

Le blob reste accessible dans les commits antérieurs, les clones, les caches, les forks et parfois les journaux d’automatisation.

01Traite d’abord le credential

Ordre de réponse
1. Révoquer ou faire expirer.
2. Créer un remplaçant à privilèges minimaux.
3. Identifier les usages et l’impact.
4. Préserver les faits sans recopier le secret.
5. Nettoyer l’historique si nécessaire.
6. Déployer la prévention.

La réécriture ne rend pas un credential encore valide inoffensif. La rotation est prioritaire.

02Délimite l’incident

git log --all --oneline -- .env
git log -p --all -- .env
git rev-list --objects --all
git branch -a --contains <commit>
git tag --contains <commit>

À rechercher aussi
- logs CI ;
- artefacts et caches ;
- pull requests fermées ;
- forks ;
- clones de collaborateurs ;
- sauvegardes et miroirs.

03Travaille dans un clone dédié

git clone --mirror git@github.com:OWNER/REPOSITORY.git \
  repository-cleanup.git
cd repository-cleanup.git

Suspends temporairement les contributions et documente la fenêtre de maintenance. Toute nouvelle branche basée sur l’ancien historique peut réintroduire les objets supprimés.

04Utilise git-filter-repo en situation réelle

git filter-repo \
  --sensitive-data-removal \
  --invert-paths \
  --path .env

Pour remplacer une chaîne présente dans plusieurs fichiers, prépare un fichier de remplacement contrôlé et suis la procédure officielle. Ne place pas le secret dans la ligne de commande ou la documentation.

Limite du lab

Le laboratoire utilise git filter-branch uniquement dans un clone jetable afin de rester autonome sur l’agent Jenkins. Pour un incident réel, le parcours recommande git-filter-repo et la procédure actuelle de la plateforme.

05Vérifie la réécriture

git log --all -- .env
git rev-list --objects --all | grep -F '.env' || true
git fsck --full --no-reflogs --unreachable
git count-objects -vH

Compare les anciennes et nouvelles références. Une réécriture change les SHA des commits descendants, même lorsque leur contenu utile semble identique.

06Coordonne la publication forcée

Avant force push
- liste des branches et tags concernés ;
- sauvegarde de référence ;
- validation indépendante ;
- accord sur la fenêtre ;
- instructions de reclonage ;
- propriétaires des forks identifiés.

git push --force --mirror origin

Cette commande est destructive et n’appartient pas à un exercice ordinaire. Elle ne doit être utilisée qu’après revue du périmètre et validation de la procédure de récupération.

07Empêche la réintroduction

# option la plus sûre pour un collaborateur
git clone git@github.com:OWNER/REPOSITORY.git repository-clean

Un simple pull dans un clone contenant encore les anciennes références peut conserver ou republier l’historique sensible.

08Ajoute les garde-fous

Prévention
- .gitignore adapté ;
- variables protégées dans la CI ;
- secret scanning ;
- push protection ;
- revue des remotes et logs ;
- credentials courts et minimaux ;
- procédure de rotation testée.

09Observe les deux histoires du lab

bash module5-git-release-ci-project.sh run \
  /tmp/soria-git-release-ci-$USER

cat /tmp/soria-git-release-ci-$USER/evidence/secret-before.txt
cat /tmp/soria-git-release-ci-$USER/evidence/secret-rewritten-history.txt

Le token du lab est explicitement fictif. N’utilise jamais un vrai secret pour démontrer une procédure.

Défi

Écris le runbook d’incident

Définis responsables, révocation, périmètre, sauvegarde, réécriture, validation, force update, reclonage et prévention. Sépare clairement les actions urgentes des actions de nettoyage.

✓À retenir

Révoquer protège immédiatement. Réécrire réduit l’exposition historique mais exige coordination, validation et traitement des copies externes. Ce sont deux opérations distinctes.