Credential rotation replaces an authentication secret or key. In an incident, the operation also requires containment: identify where the old credential was used, revoke or disable it, remove copies from accessible stores, and check for unauthorized actions. Issuing a second credential while the first remains valid does not end the exposure.
Make this comfortable
Credential incident response: revoke access before rebuilding trust
Operational decision
A CI deploy token appears in a public build log. Pause the affected deployment workflow, revoke the token at its issuer, and inspect audit logs for use since the earliest likely exposure. Create a scoped replacement with a shorter lifetime and store it in the approved secret manager; use it only after its permissions and target environment are verified. The text block is an incident checklist, not a shell script. Rotate downstream credentials if the token could retrieve them. Remove the log from public access according to the platform's retention process, but do not mistake deletion for revocation; copies may exist. Resume the pipeline through a test deployment and monitor for denied requests using the old identity. Record owners, timestamps, evidence preserved, and the reason the incident is closed.
Deploy-token exposure response
Contain: pause workflow and revoke token at issuer
Scope: identify permission set, use history, and reachable secrets
Replace: issue least-privilege short-lived identity
Verify: test a nonproduction deployment and old-token denial
Recover: resume release flow with audit monitoring
Record: timeline, affected artifacts, owners, and follow-upCost and verification
Revocation can interrupt releases until a replacement is installed; plan a break-glass path whose use is audited and time-limited. Broad credential reuse makes scoping slower and increases the number of systems to inspect. Moving to workload identity or short-lived federation reduces standing-secret rotation work, but the trust policy itself still needs review. A clean test deployment verifies function, not the absence of unauthorized historical use; audit evidence remains necessary.
Common Mistakes
- Do not only remove a leaked log while keeping the token active.
- Do not reuse the same credential across test and production.
- Do not declare recovery before testing old-token denial.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- GitHub Actions: narrow tokens and cloud trust
- Secrets and configuration across the delivery path
- Incident response: contain impact, then learn
TLS trust operations follow-up
- TLS key compromise: replace authority and end stale sessions
- Certificate revocation: test the client behavior and status-service dependency
Linux host change follow-up
devops
resilience