Un secret commis est brûlé : rotation immédiate, jamais la date
Un secret suivi par un dépôt se traite comme compromis à l'instant où il est écrit, pas quand quelqu'un prouve qu'il a été lu, et le remède qui atteint chaque copie est de faire tourner l'identifiant, la réécriture de l'historique venant en second et pas toujours nécessaire.
Un secret suivi par un dépôt se traite comme compromis à l'instant où il est écrit, pas au moment où quelqu'un prouve qu'il a été lu : c'est la règle que retient ce cours, construite sur l'ordre de priorité que pose la documentation officielle de GitHub, consultée le 2 septembre 2026, entre rotation et réécriture d'historique.
La réécriture d'historique ne remplace pas la rotation
Nettoyer l'historique d'un dépôt, en retirant le fichier fautif d'un commit passé, donne l'impression rassurante d'avoir effacé le problème. La même source est explicite sur ce point : révoquer et faire tourner un secret exposé est la priorité, le nettoyage de l'historique vient en second, précisément parce que la clé est déjà compromise au moment où on la découvre. Une copie du dépôt peut exister ailleurs, un miroir, un clone sur un autre poste, une sauvegarde : la réécriture n'atteint que la copie sur laquelle on travaille, jamais les autres copies possibles. Seule une rotation de l'identifiant lui même protège contre chacune de ces copies, connue ou non.
L'âge du commit ne dit rien sur l'état du jeton
Un jeton retrouvé dans un commit vieux d'un mois n'est pas forcément encore actif : il a pu être changé entre temps pour une raison sans rapport avec cette découverte. L'âge du fichier ne tranche donc rien, ni dans un sens ni dans l'autre. La date que porte un fichier de configuration n'est qu'une donnée de contexte, pas une preuve. L'exemple suivant illustre la différence entre regarder une date et tester réellement un jeton, sur un fixture créé pour l'occasion :
echo "jeton_de_prod_gamma" > jetons_valides.txt
jeton_a_tester="jeton_de_prod_gamma"
grep -qx "$jeton_a_tester" jetons_valides.txt && echo "encore actif" || echo "revoque"Le fichier jetons_valides.txt tient ici lieu du service qui a émis le jeton. Chez le fournisseur réel, ce rôle est joué par une requête authentifiée, envoyée par vous, contre le service concerné, jamais par la comparaison de deux chaînes de caractères locales ni par la date d'un commit.
La rotation d'abord, la preuve de lecture jamais
Attendre une preuve que le secret a effectivement été lu par quelqu'un d'autre avant de le faire tourner revient à parier sur une absence de preuve plutôt que sur la sécurité. Cette preuve n'arrive presque jamais à temps, et parfois jamais du tout. Faites tourner l'identifiant dès sa découverte, sans attendre de confirmation, puis nettoyez l'historique si le temps le permet ensuite. La leçon précédente traite ce qu'il faut faire avant même qu'un secret finisse dans un dépôt.
L'âge du commit contre le test réel
Un commit vieux d'un mois représente un risque faible, le temps écoulé rassure sur l'état du secret.
Seule une requête authentifiée en direct contre le service qui a émis le jeton dit s'il est encore actif.
Un développeur retrouve, dans un commit vieux de six semaines, une clé secrète oubliée dans un fichier de configuration. Il fait tourner cette clé auprès du fournisseur qui l'a émise le jour même de sa découverte, puis retire le fichier des commits suivants.
Écrivez en une phrase ce que cette situation établit, et en une phrase ce qu'elle n'établit pas.
Ce que cela établit : Elle établit que la clé compromise a été neutralisée à la source, par une rotation demandée le jour même de sa découverte.
Ce que cela n’établit pas : Elle n'établit pas que cette clé n'a été utilisée par personne d'autre pendant les six semaines où elle est restée exposée dans l'historique.
Les trois calibrages faux les plus courants
- Trop large La rotation de cette clé garantit qu'aucune copie du dépôt, présente ou future, ne contient plus jamais ce secret.
- Trop étroit Cette situation ne montre rien de plus qu'un développeur qui a corrigé un fichier de configuration.
- À côté Elle montre que le fournisseur de la clé a mis six semaines à détecter un usage anormal.
- Un secret commis dans un dépôt suivi est considéré compromis dès l'instant de l'écriture, pas quand sa lecture par un tiers est prouvée.
- Nettoyer l'historique d'un dépôt n'atteint que la copie sur laquelle on travaille, jamais les autres copies possibles du même secret.
- L'âge d'un commit ne dit rien sur l'état réel d'un jeton, seule une requête authentifiée auprès du service concerné tranche la question.
- La rotation d'un identifiant exposé se fait dès sa découverte, sans attendre une preuve que quelqu'un d'autre l'a effectivement lu.
Cherchez, aujourd'hui, un identifiant que vous avez peut être laissé dans un fichier de configuration déjà partagé ou commis, même une seule fois. Faites le tourner auprès du service qui l'a émis avant la fin de la journée, sans attendre une preuve qu'il a été lu par quelqu'un d'autre.
Ces points dépendent d’une interface ou d’une règle qui peut avoir changé depuis la rédaction. Vérifiez-les sur votre propre écran avant de vous y fier.
- Le mode exact de révocation et le journal d'usage disponible dépendent du fournisseur qui a émis le jeton : vérifiez sur le tableau de bord de ce fournisseur précis avant de considérer la rotation terminée.
Chaque affirmation datable de cette leçon renvoie ici au texte public qui la porte. Une source qui ne s’ouvre pas ne prouve rien.