Here is the scenario. Someone on your team created a new repository, and it went up public instead of private. The code had API keys in it: your payment processor, your email provider, maybe your cloud account. A provider's scanner found them before you did, and now an automated email asks you to act within 48 hours.
If your API keys leaked on GitHub, the fix is rotation, not privacy. Rotation means you issue a new key, move every system onto it, and revoke the old one so the exposed value stops working. Then you check the provider's logs for misuse. We have worked this incident with clients, and the first instinct in the room is always to lock the door instead.
Is making the repo private enough?
Making the repository private is not enough. A key that was public is compromised, because you cannot know who copied it while it was visible. Going private closes the door after the copy has already left the building. It is a necessary step and it settles nothing.
The alert itself tells you how closely public code is watched. GitHub runs secret scanning automatically on public repositories, and when it finds a partner's secret it notifies that provider "so they can take action, such as revoking the credential." That is usually where the vendor's email comes from. If a friendly scanner found your key, assume other scanners did too.
Rewriting git history does not fix it either. Force-pushing the keys out of the visible tree does not un-ring the bell. GitHub's own documentation calls history removal "time-intensive and often unnecessary if you've already revoked the credential." Rotate first.
What to do in the first 24 hours, in order
Work through five steps in sequence, and do not skip ahead to the cleanup.
1. Inventory every credential. List every secret that lived anywhere in the repository, including history, config files, and comments. Include payment keys, email keys, cloud keys, database connection strings, and webhook secrets. The inventory takes about thirty minutes. It prevents the classic failure: you rotate the two keys the vendor emailed about and miss the four it did not mention.
2. Rank the keys by blast radius. Blast radius is the damage a key can do in the wrong hands. Rotate payment keys and cloud root credentials first. A leaked payment key can move money or expose customer data. A leaked cloud key can run cryptomining on your bill or delete your backups. Email keys matter, but they are usually a spam problem.
3. Rotate without taking production down. Teams freeze here, because the exposed key runs order processing and rotation feels risky. Sequence the work instead of skipping it. Create the new credential, deploy it to every consumer, confirm traffic flows on the new key, then revoke the old one. Providers design for this. When you rotate a key in the Stripe Dashboard, both the old and new keys work for up to 7 days. A two-day freeze out of fear chooses a known compromise over a manageable deployment.
4. Answer the vendor with what closes the finding. "We made the repository private" does not close a 48-hour notice. Rotation does. State which keys you rotated, when you rotated them, and that the old ones are revoked.
5. Check the logs for use of the old keys. Pull provider logs for the exposure window. Look for unfamiliar IP addresses, unusual API calls, and resources you did not create. Most exposures we have worked showed no abuse. You only get to say that after you have looked.
What stops leaked keys from happening again?
Leaked keys come back unless the development process changes. The keys were in the repository because the process put them there, so the incident closes when the process changes, not when the keys rotate.
The durable fixes are unglamorous. Secrets move to environment configuration or a secrets manager. A pre-commit scanner blocks the next accidental key. New repositories default to private, and one named person owns access settings. The developer who made the mistake gets a walkthrough, not a reprimand. In our experience that person is usually new and usually rushing, and often becomes the process's strongest advocate.
One more finding is worth looking for on purpose. Several credentials for the same service, scattered across the codebase, usually mean the code has grown more than one way to do the same thing. Key hygiene problems and code hygiene problems travel together. The incident is often the first honest look a team gets at its own repository, so take that look deliberately. The same credential inventory matters even more once AI agents hold keys, which is why it opens the audit we run before an AI agent gets production credentials.
If you are looking at one of those vendor emails right now, or want the repository review before an incident instead of after, start a conversation. This exact scenario also shows up in our ColdFusion security work more often than anyone would like.