When a secret reaches a repository, a log or a chat, revoke it at the provider first, then rotate and redeploy, then clean up the leak. OWASP's secrets management guidance says to rotate immediately after exposure and to revoke the exposed secret first. Removing the commit is not enough.
Why revoke first
Anyone who copied the secret can keep using it until the provider invalidates it. OWASP says restarting an application does not revoke a stolen credential: revocation or lease expiry at the provider does. Deleting the file from git history does not help for the same reason, since clones and caches may already hold it.
The runbook
- Revoke the secret at its source: cloud console, API provider, database.
- Issue a replacement and put it in your secrets manager, not in code.
- Redeploy services that use it, and confirm they work.
- Check usage logs for the old secret between exposure and revocation. OWASP says to log who requested each secret, when it was used and any unexpected access, such as use from an unexpected IP address.
- Remove the secret from where it leaked, including logs and history if practical.
- Find the cause and fix the path that allowed it.
- Record what happened, when and what you did.
If the secret was an encryption key rather than an API token, see what to do when an encryption key leaks.
Prevent the repeat
OWASP's guidance, in short:
- Do not hardcode secrets in source code, Docker ENV or ARG instructions, or config files.
- Avoid environment variables where other injection methods exist, since they are visible to all processes and can appear in logs or dumps.
- Mask or encrypt secrets so they are never logged in plaintext.
- Prefer short lived, dynamic secrets generated per session or consumer.
- Grant access per secret, scope CI/CD credentials to what each job needs and use separate vaults per application and environment.
- Automate rotation where possible, since manual rotation is error prone.
See also keep MCP secrets out of git.
An example timeline
A developer pushes a cloud access key to a public repository on a Friday afternoon. A scanner alert arrives within minutes. The on-call engineer disables the key in the cloud console first, which ends the attacker's window. Next a new key is created, stored in the secrets manager and rolled out to the service. Then the team reviews access logs for the period the key was exposed, looking for unfamiliar addresses or unusual calls. Only after that is the commit cleaned up and the pipeline fixed to block the pattern. The order keeps the risk window as short as possible, and the record shows each step.
Quick check
Is deleting the commit enough?
No. Treat any secret that was exposed as compromised and revoke it.
Why not rotate before revoking?
Rotating without revoking leaves the old secret valid. Make sure the old one stops working.
Safeguard's policies and gates can block risky changes in pull requests, and its free scan is a quick way to check a project's dependencies.
Sources
Last reviewed: 19 October 2026.
