Leaked Secret Incident Response Workflow
Treat a leaked credential as compromised instantly: rotate first, then hunt usage, then patch the leak path, preserving evidence throughout.
Objective
Neutralize a leaked secret by rotating it within minutes, detecting any unauthorized use from saved evidence, and closing the leak path that produced it.
Environment
- Secret inventory with owners and rotation procedures
- Audit logs for the system the secret protects
- Authority to revoke credentials on affected systems
Steps
1. Confirm and classify the leak
Verify the secret is real and current (not revoked or test), and classify its scope: read-only token, deploy key, or user-data access credential.
Expected state: The leak is confirmed valid with a scope classification that drives urgency.
2. Rotate immediately, dual-issued
Create a replacement credential, deploy it to consumers, then revoke the old one, using dual-credential windows where the system supports them.
Expected state: The old secret stops working while all legitimate consumers run on the new one.
3. Hunt unauthorized usage from pre-rotation logs
Search audit logs for use of the old secret before rotation: unusual source IPs, novel API calls, privilege escalations, or data exports.
Expected state: A usage report exists covering the leak window with any anomalies flagged for follow-up.
4. Preserve evidence before cleanup
Snapshot the leak artifact (commit, ticket, screenshot) and relevant logs before deleting the leaked copy, maintaining the chain for investigation.
Expected state: Evidence copies exist in the incident record even after the public leak copy is scrubbed.
5. Close the leak path
Fix what allowed the leak (hook rejection, CI masking, secret manager adoption) and scan for the same pattern elsewhere in the estate.
Expected state: The specific path is closed and an equivalent scan shows no sibling leaks.
Decision points
Rotate before or after confirming misuse?
- Rotate immediately
- Investigate then rotate
Rotate immediately for anything touching user data or production; investigation never justifies leaving a live leaked credential.
Public disclosure of the incident?
- Proactive notice
- Quiet fix
Follow legal and policy guidance; if user data was accessed with the secret, proactive disclosure is usually required.
Expected outcome
A leaked credential that loses power within minutes, with unauthorized use detected from preserved logs and the leak path structurally closed.
Verification
The old credential fails authentication everywhere; the usage report covers the leak window; a repeat of the leak path test is rejected by the new guardrail.
A leaked secret is compromised the moment it leaks
Debating whether anyone saw the credential grants attackers the time to use it. The response order is fixed: rotate to remove its power, then investigate with the logs you saved, then close the path that leaked it.
leak: deploy key in a public gist (found 14:02Z)
14:04Z confirmed valid, scope: repo write (prod deploy)
14:06Z ROTATE: new key deployed to CI (dual window)
14:12Z REVOKE old key -> auth fails everywhere
14:13Z hunt (audit log 10-22 00:00Z to 14:12Z):
usage: CI runner x 41 (expected)
anomalies: 14:07Z from 198.51.100.9?? no --
(post-revoke probe attempt, blocked)
evidence: gist snapshot + log export -> incident record
14:30Z scrub public copy (takedown + history note)
15:10Z path fix: pre-push secret scanner liveRotation speed is the whole game
Every other step can be imperfect if rotation is fast. A credential leaked at 14:02 and dead by 14:12 has a ten-minute exposure window; the same credential rotated tomorrow has an exposure window attackers can mine at leisure. Pre-built rotation runbooks are what make the fast path real.
Save the evidence you are about to destroy
Scrubbing the gist and revoking the key both destroy information: who saw it, when it leaked, how it was used. Snapshotting the artifact and exporting the logs before cleanup preserves the ability to answer the questions legal, security, and the postmortem will ask.