You pushed a secret. Now what?

It happens in every engineering team eventually. Someone commits a configuration file with a real API key, pushes it, and notices a few minutes later. The instinct is to delete the line, force-push, and hope nobody saw.

Somebody almost certainly did. Attackers continuously scan public repositories, package registries and paste sites for credentials. Exposed cloud keys can be tested within minutes of being pushed. And git is designed to remember: the secret lives on in forks, clones, caches and pull request history.

Rule one: rotate first, clean up later

The only reliable fix for a leaked secret is to make it useless. Everything else is housekeeping.

1. Revoke or rotate the credential immediately. Generate a new key, deploy it, and disable the old one. If that will break production, accept a short outage over an open door.
2. Check what the key could do. Review the provider's audit logs from the moment of the push for any use you do not recognise.
3. Then clean the history if the repository is public or widely shared, so the secret is not rediscovered later.

Check private repositories too

Leaks are not only a public-repository problem. Private repositories are cloned onto laptops, mirrored to CI systems and shared with contractors. When an attacker compromises a developer laptop or a CI provider, the secrets in your repository history are among the first things they search for.

Stop secrets reaching git in the first place

Prevention is cheaper than rotation at midnight.

• Pre-commit scanning. A lightweight hook that blocks commits containing patterns that look like keys. It catches most mistakes on the developer's own machine.
• Server-side push protection. Many git hosting platforms can reject pushes that contain known credential formats. Turn it on for every organisation and repository.
• Scan the history. Run a secret scanner across all existing repositories once. Most teams find a few old keys that are still valid.

Shorten the life of every secret

The less time a credential is valid, the less a leak matters.

1. Prefer short-lived credentials issued at runtime, such as workload identity in your cloud provider or OIDC federation for CI pipelines, over long-lived static keys.
2. Scope keys tightly. A key that can only read one bucket is a much smaller problem than one with administrator rights.
3. Set expiry dates on any long-lived tokens that remain, and keep an inventory of who owns them.

Make reporting safe

The worst outcome is a developer who notices a leak and stays quiet because they fear blame. Say clearly and often that reporting a leaked secret quickly is exactly what you want. The person who reports in five minutes saves you far more than the person who never made the mistake at all.