Detect, respond, and recover
Contain without destroying evidence
Limit ongoing harm, preserve useful evidence, and avoid impulsive changes that make the incident harder to understand.
Containment stops the damage from growing. It is not the same as immediately deleting every affected system — and the difference decides whether you can ever answer “what did they access?”
During an active incident, two jobs run at once. Containment limits ongoing harm. Investigation reconstructs what happened. Impulsive destructive actions serve the first job by killing the second.
The standard containment moves
- Revoke exposed credentials, so stolen authority stops working.
- Isolate compromised components — pull them from the load balancer or the network rather than wiping them.
- Block known abuse at the edge: IPs, tokens, endpoints.
- Preserve relevant logs and snapshots before anything changes or expires.
Record each action and its time as you go:
02:14 confirmed stolen token is creating unauthorized releases
02:17 exported provider audit events (before any changes)
02:19 revoked the deployment token
02:21 verified a deploy attempt with the old token fails
That timeline has two readers: the teammate joining mid-incident, and future-you writing the review next week.
The instinct that destroys the timeline
A stolen deployment token is still creating releases. The panicked instinct is to delete the malicious releases and the build history — make the bad thing disappear. Deleting the build history stops the visible activity but destroys the timeline and leaves the token valid. You erased your only record of what the attacker did, and they can still deploy.
The order that works: preserve the history first, revoke the credential second, clean up last. Revocation is the move that actually stops the attacker, and it destroys nothing.
Containment has costs, and that is acceptable. Revoking the deployment token may temporarily stop all deployments, including your urgent fix. Plan a separate recovery identity — a break-glass deploy credential kept offline — so containment does not lock the responders out too.
Coordinate the destructive steps
Any action that cannot be undone — wiping a server, deleting data, rotating every key at once — goes through the incident lead first. That is not bureaucracy. It is the mechanism that keeps recovery and investigation possible while individual responders move fast on the reversible actions.
Rehearse this with a disposable token in a test project. Order the containment actions, run them, and prove two things at the end: the token can no longer deploy, and its identifier and activity history are still available. Containment succeeded when the attacker’s access is dead and the evidence is alive.
Lesson completed