A GitHub secret scanning alert flags a live cloud key — what is your response order?

## Why the order is the answer Almost every candidate knows all five actions. The differentiator is sequencing, because the sequence encodes what you believe about exposure. A credential in a repository has already been read by everything with access to that repository — clones, forks, CI runners, caches, mirrors, and on public repositories, automated harvesters that watch the public event stream and try keys within seconds. Every minute spent rewriting history before revoking is a minute the key still works. ## Step 1: revoke and reissue Go to the issuing provider and invalidate the credential. Then create a replacement and deploy it wherever the old one was legitimately used. Yes, this can cause an outage in a service that was depending on the leaked key — that outage is the cost of the leak, and it is smaller than the cost of leaving a live key public. If rotation is genuinely impossible without a coordinated change, that is a finding about your credential design, not a reason to delay. On public repositories the partner programme may have got there first: GitHub forwards matches for partner patterns to the issuing provider, and some providers revoke automatically or email the account owner. Treat that as a bonus, never as your plan. ## Step 2: assume use, then check The question after revocation is what happened while the key was live. GitHub cannot tell you that; only the provider's audit trail can. Look for calls from unfamiliar addresses or regions, unusual API calls, new resources, or new credentials created using the leaked one — the last is how a short exposure becomes a persistent foothold. Fix the scope of the exposure, not just the key: if the credential could create other credentials, revoking it alone may not be enough. Validity checks on the alert are triage input for prioritising among many alerts. "Active" means rotate now. "Inactive" means the key cannot be used today; it does not mean it was never used. ## Step 3: resolve the alert properly An alert is closed with a **resolution**, and the vocabulary is meaningful: `revoked` for a real credential you have invalidated, `false_positive` for something that only looked like a key, `used_in_tests` for a fixture, and `wont_fix` for an accepted risk. Add a resolution comment saying what you did — this is what a future auditor or the next engineer reads. Resolving an alert has no effect on the credential; it is the record of your decision, and mass-closing alerts to clear a dashboard is exactly the behaviour that makes the whole feature untrustworthy. ## Step 4: clean history, with realistic expectations Removing the credential from history is worth doing — it stops the next person copying it out of an old commit, and it keeps a future scan clean. It is also the step candidates over-value. Two GitHub-specific facts to name: - Commits made unreachable by a rewrite can remain **addressable by their SHA** on GitHub, and pull-request views can retain content, so a rewrite does not necessarily make the value unreachable through the web interface. Where that matters, GitHub Support can be asked to remove cached views and stale references. - Repositories in the same **fork network** may retain the commit even after you rewrite yours, because a fork is not your repository. And of course every existing clone, every CI log line that echoed the value, and every backup still has it. This is why revocation is step one and cleanup is step four. ## Step 5: close the loop Enable push protection on the repository if it was not on, so the next occurrence is a rejected push rather than an incident. If the credential type was not covered by any pattern, that is the trigger for a custom pattern. If the same team leaks the same class of credential repeatedly, the real fix is upstream — the credential should not have been in a position to be pasted into a file at all. ## Communicating it A crisp senior answer sounds like: "Revoke and reissue immediately — assume it is compromised. In parallel, pull the provider's audit log to see if it was used and whether it minted anything else. Then resolve the alert as revoked with a note, remove it from history knowing forks and cached views may still hold it, and turn on push protection so it cannot happen the same way again." That is under sixty seconds and hits every point that matters.