Respond to a leaked secret

A secret that left its intended boundary must be treated as compromised. Automated scanners pick up keys from public repositories within minutes, and deleting the commit, force-pushing or making the repo private does not undo the copies already made. Forks, caches, CI logs and container layers keep their own copies. The only real fix is to make the leaked value useless, then find out whether anyone used it. Order matters: rotate first, then investigate, then clean up, because cleaning up first gives a false sense of safety and can destroy evidence.

A [SECRET_KIND] was exposed: [EXPOSURE] Only if [USED_BY] is given: It is used by: [USED_BY]

Write the response plan.

1. Rate the severity from what the secret can do (its scopes and permissions), how public the exposure was, and for how long.
2. Order the steps so the leaked value is revoked first. If there are signs of active misuse, revoke at once and accept the outage. Otherwise, where revoking it at once would cause an outage, say so and give the fastest safe order: create a second credential, deploy it, then revoke the old one, with a time limit on that window. If the credential type or provider is unclear, give the generic containment steps first, then ask.
3. If the repository is available, search it for every place the secret is read (environment variable names, config keys, secret manager paths) so the rotation misses no consumer. List the places you found.
4. Say how to check whether the secret was used during the exposure window (first exposure to revocation): which audit or access logs this kind of credential has, what to filter on, and what unexpected use looks like. Include persistence an attacker may have created with it: new users, keys, tokens, OAuth apps, webhooks, deploy keys or scheduled jobs.
5. Cover clean-up as hygiene after revocation, and say what it does not fix: remove the secret from current code and config; rewrite history only if needed, with a coordinated force-push; ask the host to purge cached views where it offers that; and check the other places copies live (forks, pull request refs, CI logs and artifacts, container image layers, chat, tickets, paste sites).
6. Say who to notify: the security owner and the owner of the service the credential protects. If personal or customer data may have been accessed, involve legal or privacy staff early, because notification deadlines may apply.
7. Recommend the two or three controls that would have prevented this specific leak, for example push-time secret scanning, short-lived credentials such as workload identity federation for CI, and least privilege on the replacement.

• Never ask for the secret's value. If the user pasted it, tell them in the first line that it is now exposed in this conversation too and must be rotated regardless.
• Never present deleting the commit, rewriting history or making a repository private as a fix.
• Give exact console paths or CLI commands only when you are sure of them for this provider. Otherwise name the provider's official documentation page to follow. Do not invent flags.
• Do not run any command that changes production; the user runs the steps. Mark each command that changes state.
• Do not decide whether a legal notification is required; say who should decide.
• Keep it short enough to follow during an incident: imperative sentences, one action per line.
• Separate what you verified from what you inferred. Mark inferences as such.
• When you do not know, say "I don't know" once and state what would settle it.

Severity

One line: critical, high, medium or low, and why (what an attacker could do with it).

Do now

Numbered steps for the next 15 minutes, revocation first.

Rotate

Numbered steps to issue the new secret and update every consumer, with the consumers found in the repo.

Investigate

Which logs to check, the time window, the filter, and what counts as suspicious use.

Clean up

A checklist in order, after rotation: code and config, history, caches and other copies, with what each step does and does not achieve.

Notify

Who, and what to tell them.

Prevent

Two or three controls, each tied to how this leak happened.

Incident record

Fields to record: credential, exposure start, detection, revocation time, evidence of use, follow-ups.

Unknowns

Facts you need from the user that would change the plan. "None" if none.