A secret committed to a repository does not become safe again when you delete it in a later commit — it lives in git history, in every clone anyone has ever made, in CI logs that echoed it, in a fork someone made before the deletion, indefinitely, and the only real fix once that happens is treating the secret as burned and rotating it. This is the fact that should drive every decision in this lesson: prevention (never letting a secret land somewhere it can leak) is cheap and the failure mode of forgetting it is expensive, while rotation (changing a secret's value on a schedule or in response to exposure) is the control that bounds the damage of the leaks prevention inevitably misses anyway.
Teams that treat secrets management as "store the password somewhere other than the code" have solved a much smaller problem than the one that actually matters. A secret sitting in an environment variable, unrotated for three years, shared identically across every service that happens to need it, with no record of which service last used it or when, is barely safer in practice than one hardcoded in source — it is just harder to notice when it is exposed, and it takes down every service sharing it the moment it has to be revoked in an emergency.
The discipline this lesson builds is threefold: where a secret should actually live (a secrets manager or KMS, scoped and access-controlled, not a shared environment variable), how it should be rotated (on a schedule, with an overlap period, without downtime), and why the two are the same problem — a secret you cannot rotate cleanly is a secret you will not rotate promptly when an incident demands it.
Analogy🏏Cricket
🏏 Think of it like cricket: A team's dressing-room safe holds match fees and player valuables during a tournament, and the combination is known to exactly the manager and the team's designated security liaison — not written on a whiteboard, not shared in a group chat for convenience, not the same combination reused from the previous tour because changing it each time felt like unnecessary friction. When a support staff member's phone was lost during one tour with the combination saved in a notes app, the team changed the safe's combination within the hour, not because they had proof the phone had been compromised, but because a secret that might have leaked has to be treated as leaked the moment there's real doubt, and changing a combination costs the team a few minutes while leaving it unchanged risks everything the safe protects. That fast, low-friction change was only possible because the team had a clear, rehearsed process for updating the combination and informing exactly the people who needed the new one — not a scramble to figure out who even knew the old one. Just as a safe's combination has to be changeable quickly, cleanly, and to exactly the right people, a secret has to be rotatable without becoming an operational crisis every time it happens. Just as treating a possibly-exposed combination as compromised is cheap insurance against an expensive alternative, treating a possibly-exposed secret as burned and rotating it immediately is cheap insurance against the alternative. The insight is that the actual security property isn't the secret's current strength — it's how fast and how cleanly it can be changed the moment there's genuine doubt about it.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.