Here is the scenario. Someone on your team set up a new repository and it went up public instead of private. The codebase had API keys in it: your payment processor, your email provider, maybe your cloud credentials. A vendor's secret scanner found them before you did, and now you have an automated email telling you to act within 48 hours.
We have worked this incident with clients. The instinct in the room is always the same, and it is always wrong.
The instinct: lock the door
The first thing everyone wants to do is make the repository private and declare the problem contained. It feels decisive. It is not remediation.
Once a key has been exposed in a public repository, you must treat it as compromised, full stop. Scrapers index public GitHub continuously and clone interesting repositories within minutes of them appearing. The window between "pushed" and "harvested" is not measured in days. Making the repo private closes the door after the copy has already left the building. It is a necessary step and it settles nothing.
The same logic applies to rewriting git history. Force-pushing the keys out of the visible tree does not un-ring the bell. The keys were public. Rotate them.
What to do, in order
1. Inventory before you touch anything. List every credential that lived anywhere in the repository, including history, config files, and comments. Payment processors, email providers, cloud accounts, database connection strings, webhook secrets. The inventory takes thirty minutes and prevents the classic failure: rotating the two keys the vendor emailed about and missing the four they did not.
2. Rank by blast radius. Payment keys and cloud root credentials first. A leaked payment key can move money or exfiltrate customer data. A leaked cloud key can spin up cryptomining infrastructure on your bill or delete your backups. Email keys matter, but they are usually a spam problem, not an existential one.
3. Rotate with continuity in mind. This is where teams freeze: the exposed key is embedded in a running production system, and rotating it feels like it might break order processing. The answer is to sequence, not to skip. Generate the new credential, deploy it to every consumer, verify traffic flows on the new key, then revoke the old one. Most providers support two live keys precisely so rotation does not require downtime. Freezing for two days because you are afraid to rotate is choosing a known compromise over a manageable deployment.
4. Take the vendor deadline seriously, but understand what satisfies it. When a payment processor gives you a 48-hour notice, replying "we made the repository private" does not close the finding. Rotation closes the finding. Say so explicitly in your response: which keys were rotated, when, and confirmation the old ones are revoked.
5. Check for use of the exposed credentials. Pull provider logs for the exposure window. Unfamiliar IPs, unusual API calls, new resources you did not create. Most exposures we have worked showed no abuse, but you only get to say that after you have looked.
The 24 hours after the 24 hours
The incident is not over when the keys are rotated. The keys were in the repository because the development process put them there, and the process will do it again.
The durable fixes are unglamorous: secrets move to environment configuration or a secrets manager, a pre-commit scanner blocks the next accidental key, repository creation defaults to private with someone actually accountable for access settings, and whoever set up the repo gets a walkthrough, not a reprimand. In our experience the person who made the mistake is usually new, usually rushing, and usually the easiest person in the building to turn into the process's strongest advocate.
One more uncomfortable finding worth looking for: multiple credentials for the same service scattered across the codebase usually means the code has accumulated 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 an organization gets at the state of its own repository, and it is worth taking that look on purpose rather than waiting for the next automated email.
If you are staring at one of those emails right now, or want the repository review before the incident instead of after, start a conversation. We also cover secure platform work as part of ColdFusion security engagements, where this exact scenario shows up more often than anyone would like.