Home / Security and data

A committed secret is burned: rotate it now, never by the date

A secret tracked by a repository is treated as compromised from the moment it is written, not when someone proves it has been read, and the fix that reaches every copy is to rotate the identifier, with history rewriting coming second and not always necessary.

A secret tracked by a repository is treated as compromised from the moment it is written, not at the point when someone proves it has been read: that is the rule this course holds, built on the order of priority set out by GitHub's official documentation, consulted on 2 September 2026, between rotation and history rewriting.

Rewriting history does not replace rotation

Cleaning up a repository's history, by removing the offending file from a past commit, gives the reassuring impression of having erased the problem. The same source is explicit on this point: revoking and rotating an exposed secret is the priority, cleaning up the history comes second, precisely because the key is already compromised by the time it is discovered. A copy of the repository may exist elsewhere, a mirror, a clone on another machine, a backup: rewriting history only reaches the copy being worked on, never the other possible copies. Only rotating the identifier itself protects against each of these copies, known or not.

The commit's age says nothing about the token's state

A token found in a commit a month old is not necessarily still active: it may have been changed in the meantime for a reason unrelated to this discovery. The file's age therefore settles nothing, in either direction. The date on a configuration file is only a piece of context, not proof. The example below illustrates the difference between looking at a date and actually testing a token, on a fixture created for the 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"

The file jetons_valides.txt here stands in for the service that issued the token. With the real provider, that role is played by an authenticated request, sent by you, against the service in question, never by comparing two local strings of characters or by a commit's date.

Rotate first, never wait for proof of reading

Waiting for proof that the secret was actually read by someone else before rotating it amounts to betting on an absence of proof rather than on security. That proof almost never arrives in time, and sometimes never arrives at all. Rotate the identifier as soon as it is discovered, without waiting for confirmation, then clean up the history afterwards if time allows. The previous lesson covers what to do before a secret even ends up in a repository.