Triage an Exposed Secret
Contain an exposed credential by identifying its provider, scope, possible use, replacement path, and revocation evidence.
A leaked key is an access incident, not only a file-cleanup task. The team needs to know which provider issued it, what it could do, whether it was used, and how to end that authority without breaking legitimate service. Do not copy the key into a new ticket or model prompt while investigating.
Begin with a safe fingerprint, key ID, or provider listing. Restrict the exposed location and preserve enough evidence to know where the copy appeared. OWASP's secrets guidance covers rotation and revocation; provider-specific controls decide the actual steps.
Incident timeline
| Stage | Question | Evidence |
|---|---|---|
| Discover | Where was the value exposed? | Path and access window |
| Classify | What account, scope, and tenant can it reach? | Provider metadata |
| Contain | Can access to the copy be restricted? | Access change receipt |
| Replace | Which callers need a new key? | Health checks |
| Revoke | Is the old key disabled at provider? | Status or denied safe request |
| Review | Was there suspicious use? | Provider and app logs |
| Close | Are backups and derived tokens considered? | Owner decision |
Do not wait for a perfect usage history before revoking a high-risk credential when the provider allows a safe replacement. At the same time, plan the cutover so a production job does not silently fail. If the provider lacks a rotation API, identify the required owner action and record the delay.
Verify the new boundary
Use an authorized harmless operation to prove the replacement works. Then prove the old key is rejected through a provider status or safe negative test. Check delayed jobs and long-lived sessions separately. A copied credential may have been exchanged for another token, so review the provider's token model before declaring the incident contained.
Keep timestamps, operators, key IDs, and decisions in the incident record. Do not include raw credential values or customer data. Mark unknown exposure and usage as unknown, not clean. Deleting a repository commit or closing a local session cannot revoke a copy.
Make offboarding verifiable
Use the offboarding checklist to identify owners, revoke grants and verify the result. Discuss a scoped review of your application's access controls.
Sources
- OWASP Secrets Management Cheat SheetAccessed
- OWASP Logging Cheat SheetAccessed