When a credential leaks, the clock starts immediately. Attackers run automated scanners against public repositories, package registries, container images and paste sites, and exposed cloud keys can be used within minutes. Yet many leaked secrets stay valid for months, because nobody knows who owns them, what depends on them or how to rotate them without breaking production. This playbook gives a repeatable response for leaked API keys, cloud access keys, tokens, passwords, certificates, SSH keys and OAuth grants: triage, contain, rotate, investigate, recover and prevent. Use it alongside your wider incident response plan.
Key takeaways
- Assume a leaked secret has been used until logs prove otherwise.
- Revoke or disable first, then rotate. Deleting a commit or a file does not invalidate the credential.
- Response speed depends on work done before the incident: an inventory with owners, dependency maps and automated rotation.
- Investigate what the credential could reach as well as what it did reach.
- Every leak is evidence of a process gap. Fix the root cause, such as a missing vault or pre-commit scanning.
Where credentials leak
- Source code and history: public and private repositories, including old commits. See the GitLab public repositories study and exposed .git folders.
- Build and CI systems: logs, artefacts and runner environments. See the Codecov breach.
- Packages and images: npm, PyPI and container images. See the Docker Hub secrets leak and the Shai-Hulud npm worm.
- Configuration files: exposed .env files on web servers. See the .env cloud extortion campaign.
- Collaboration tools: tickets, chat, wikis, support cases and online formatters. See the code formatter leak.
- Third parties: suppliers holding your credentials in their systems. See the Red Hat Consulting breach.
- Endpoints: infostealer malware on developer and admin machines.
Step 1: Triage (minutes)
- Confirm it is live: check whether the credential is valid, using the provider's safe verification method where available rather than exercising its privileges.
- Identify it: credential type, issuing system, account or tenant, and owner. If there is no known owner, escalate to the platform team for that system.
- Size the blast radius: what permissions and data it grants, and whether it can create other credentials.
- Record where and when it was exposed, and whether the exposure is public or internal.
- Set severity from privilege and exposure. A public, admin-level cloud key is critical.
Step 2: Contain
| Credential | Containment action |
|---|---|
| Cloud access key | Deactivate the key; attach a deny policy if needed; review and remove any identities or keys created with it |
| SaaS or API key | Revoke in the provider's console; restrict by IP where the provider supports it |
| OAuth access and refresh tokens | Revoke the grant for the application; revoke refresh tokens; disable the OAuth app if compromised. See the SaaS and OAuth App Governance Guide |
| Personal access token (GitHub, GitLab, npm, PyPI) | Revoke the token; check for new tokens, SSH keys, deploy keys or package versions created with it |
| Password (service account or user) | Reset, revoke sessions and refresh tokens, check MFA registrations |
| Private key or certificate | Revoke the certificate; issue a new key pair; for signing keys, assess what was signed. See the Cryptographic Key Management Guide |
| SSH private key | Remove the public key from every authorized_keys file and revoke any SSH certificates. See the SSH Key Management Guide |
| Session cookies and tokens | Revoke sessions for the affected accounts. See the Token and Session Security Guide |
Removing the secret from the repository, image or page is still worth doing to stop re-use, but it is not containment. The credential remains valid until revoked, and copies already exist.
Step 3: Rotate and restore service
- Issue a replacement credential with the minimum privilege actually needed, which is often less than the original.
- Deploy it through the vault or secrets manager rather than editing configuration by hand. See the Secrets Management Guide.
- Where possible, replace the static secret entirely with workload identity federation or short-lived credentials. See the NHI Authentication Guide.
- Confirm dependent services are healthy, and watch for failed authentication from anything you missed.
The Guide to NHI Rotation Challenges covers why rotation breaks things and how to plan for it.
Step 4: Investigate
- Pull provider logs for the credential from the time of exposure (or earlier, if the exposure date is uncertain) to now.
- Look for use from unfamiliar IP addresses, regions, user agents or tools.
- Look for persistence: new users, keys, roles, OAuth apps, SSH keys, webhooks, CI secrets or package versions.
- Look for data access and export, and for resource creation such as compute used for cryptomining or LLMjacking. See the LLMjacking Guide.
- Check whether the same secret was reused elsewhere.
- Decide on notification duties for customers, partners and regulators with legal and privacy teams.
Step 5: Recover and close
- Remove any persistence found and rotate anything the attacker could have reached.
- Purge the secret from repository history, images and caches where practical.
- Update the credential's inventory record: new owner confirmation, new expiry, new scope.
- Close the incident with a timeline: exposure, detection, revocation and rotation times.
Step 6: Prevent the next one
- Scan before code reaches a repository (pre-commit and push protection), not only after.
- Scan images, packages, CI logs, tickets and chat, not just source code.
- Move secrets into a vault and inject them at runtime.
- Replace long-lived secrets with short-lived, federated credentials.
- Give every NHI an owner so triage does not stall. See the NHI Ownership Guide.
- Deploy canary tokens that alert when used, to detect leaks you do not know about.
Roles and timings
| Role | Responsibility |
|---|---|
| Security operations | Detection, triage, severity, coordination and investigation |
| Credential owner | Rotation, dependency knowledge and service recovery |
| Platform or cloud team | Revocation where the owner is unknown; log access; persistence checks |
| Legal and privacy | Notification decisions |
Agree target times in advance, for example revocation of a public critical credential within an hour of detection, and measure against them.
Practitioner checklist
- Maintain an inventory of NHI credentials with owners, scopes and dependencies.
- Document how to revoke each credential type you use, and test it.
- Revoke first, then rotate; never treat deleting the file as containment.
- Investigate for persistence and data access from the exposure date onwards.
- Replace leaked static secrets with federated or short-lived credentials where possible.
- Scan code, images, packages, logs and collaboration tools continuously, with push protection.
- Track time to detect, revoke and rotate for every incident.
Standards and references
- NIST SP 800-61 Rev. 3: Incident Response Recommendations (2025)
- OWASP Non-Human Identities Top 10 (2025): NHI2 Secret Leakage
- OWASP Secrets Management Cheat Sheet
- GitHub secret scanning and push protection
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · API Key Management Guide · Secrets Management Guide · ITDR Guide
