A leaked credential does no damage while it exists. It does damage while it works, and the interval between those two facts is the only part of this you control.
Exposed keys are typically used within minutes, because public repositories are scanned continuously. That makes the ability to revoke quickly worth more than any decision about where secrets are stored.
What a secret actually is
Every running product holds credentials it did not choose and cannot operate without. A database password. A payment provider’s live key. A mail service token. A cloud account that can create and destroy infrastructure. None of these were security decisions when they were created. They were setup steps.
Secrets management is the answer to four questions about them, and only the last one is urgent. OWASP’s secrets management cheat sheet is the reference if you want the long version.
| Question | Answer |
|---|---|
| Where do they live? | A file, a laptop, a password manager, a managed store, all of the above |
| How do they reach code? | Environment variables, mounted files, fetched at startup |
| How do they change? | Rotation: replace and invalidate the old |
| How fast can they die? | Revocation, and this is the one that matters |
Founders spend most of their attention on the first question, because it feels like the security one. It is the fourth that decides how bad a bad day gets.
Which points at where they should live. The category is a managed secret store: something that holds the value centrally, hands it to your application at run time, records who read it, and lets you revoke it from one place. Your cloud provider has one and most application hosting platforms include one. Whether you pay for it is not the interesting question. Whether a leaked value can be killed from a single place, without hunting across machines, is.
Why credential exposure hits small teams hardest
Credential exposure is the most common way small companies suffer a serious incident, and it is common for an unglamorous reason: it does not require anyone to attack you.
Public code hosting is scanned continuously and automatically, by security vendors, by researchers, and by people who intend to use what they find. What they do with an exposed cloud key is usually to run up compute costs on someone else’s account, and sometimes considerably worse.
There is a second, quieter version that skips GitHub entirely. Secrets pasted into a support chat, sent to a contractor over email, or copied into a shared document during onboarding. These never trigger an alert, they never get rotated, and they persist in message history long after the person has moved on. The laptop of a contractor you worked with for six weeks in 2024 is still, in a meaningful sense, part of your production environment.
The first hour after a credential leaks
If it has happened, the order matters more than the thoroughness.
- Revoke the credential. Not delete the file. Not rewrite history. Not make the repository private. Revoke, so the key stops working. Everything else is reversible and this is the only step that stops the clock.
- Issue a replacement and deploy it. Accept a few minutes of broken functionality over an unknown period of valid access.
- Look at what the old credential did. Whatever logs the affected service keeps, this is what they are for. You are asking whether it was used from somewhere you do not recognise, and when.
- Then do the housekeeping. Remove the file, fix the ignore rules, and decide whether the repository should have been public.
- Write down which credential it was and when. If a customer or an auditor asks in eight months, this note is the entire answer.
The instinct under pressure is to reverse steps one and four, because deleting the file feels like undoing the mistake. It undoes nothing. The credential was copied the moment it was published, and a repository’s history survives in every clone and fork.
Where secrets management goes wrong
- The source of truth is a file passed between people. It works at three people. It has no answer to who currently holds it, and no way to take it back.
- Rotation is theoretically possible and never practised. NIST’s secure software development framework treats protecting and rotating secrets as a named practice, not a nice to have. A team that has never rotated a credential does not know how long it takes, which means the answer during an incident is “we found out that evening”.
- One credential does everything. The key used for a small automation is also the key with full administrative rights, because that was the one that already existed and worked.
- Credentials that never expire. A token issued in year one, still valid, still in use, held by people who no longer work there.
- Nobody knows the full list. You cannot rotate what you cannot enumerate, and the credentials that hurt are the forgotten ones, not the ones on the wiki.
- Third party keys treated as less serious. The analytics token is not a low-value secret if it can read customer data.
Questions to ask about your secrets
- If our production database credentials leaked right now, how long until they are useless to whoever has them? A number in hours is a good answer. An unsure look is the finding.
- Can we produce a list of every credential our product uses, right now, without reading the code?
- Which of our credentials has full administrative rights, and does anything actually require that?
- Who has held a production credential at any point, including contractors and people who have left?
- When did we last rotate anything, and how long did it take?
- If a secret appeared in a public repository tonight, who would find out, and how?
That last question has a good answer available cheaply. Most code hosting platforms will scan your repositories for exposed credentials and alert you, and several will notify the provider directly so the key is revoked without you. Turning that on is a ten minute task that answers the question permanently.
Start here. Turn on secret scanning at your code host, then rotate one real credential end to end and time it. The number you get is your actual exposure window, and it is usually longer than anyone guessed.
A secret you cannot revoke in an hour is not a secret you own. It is one you are hoping nobody has read.