We found an old API key in our code. Does it matter?

The question

It's a reasonable guess, and it's wrong more often than people expect. Security researchers scanning public GitHub code this year found 543,699 unique credentials that were still valid when tested — not just findable, but usable. The median exposed credential had been sitting in public view for 784 days. About 1 in 10 were older than 6 years.

What we told them

Age tells you nothing about whether a leaked key still works. A credential doesn't expire just because the project around it ended — it expires when someone actually revokes it, and that step gets skipped constantly. The common pattern: a developer notices the leak, deletes the file or scrubs the commit, and considers it handled. The actual key behind it, the thing that grants access, never gets rotated on the provider's side. GitHub's own secret-scanning and push-protection catch a lot of exposures, but catching a leak and revoking the credential are two different jobs — and only one of them is automatic.

So the real question isn't "is this old?" It's "has anyone with access to this key actually gone into that service and killed it?" If the answer is no, treat it as live, regardless of how stale the surrounding code looks. Here's what that means in practice:

• Revoke it at the source, not just the repo. Deleting the key from your code does nothing if the key itself is still active in AWS, Stripe, SendGrid, or wherever it grants access.
• Check history, not just the current branch. A key removed from the latest commit is still sitting in every earlier commit and every fork — treat the whole history as exposed.
• Assume forks and clones exist. Public repos get copied automatically by bots and researchers within minutes of going public. You can't un-expose it; you can only make it useless.
• Rotate on a schedule for anything that touches production. If a key's age is unknown or its exposure history is unclear, the fastest fix is also the simplest: issue a new one and retire the old.