Direct answer
Order the work by the question "can an attacker still get in with what leaked?" First stop ongoing harm (hours), then find out whether the credentials were actually used (days), then remove the root cause and add guardrails so it cannot recur (weeks). With limited capacity, the first phase gets everyone, later phases get explicit owners, and anything deferred is written down with leadership's sign-off. Progress is shown as a short, fixed set of numbers, not a task list.
Prioritised plan
| Horizon | Goal | Actions |
|---|
| Hours (0-24) | Stop the exposure and assume the credentials are compromised | Turn on the storage service's public-access block for the bucket. Revoke and rotate every exposed credential (treat them as valid and in attacker hands until proven otherwise). Copy the bucket policy (the rules stating who may read the bucket) and access logs to a separate write-once location that the affected accounts cannot edit (tamper-resistant), before anything changes further. |
| Days (1-7) | Scope the damage and close sibling gaps | Search the bucket's access logs for reads from unknown addresses during the period it was publicly readable (the exposure period, which began before you discovered it), and search the cloud audit logs for the leaked keys being used: successful sign-ins or API calls from unfamiliar addresses or at odd times, and any creation of new users or keys. Sweep all other buckets for public access. Scan repositories and buckets for other stored secrets. Fix the pipeline that wrote credentials into that bucket. |
| Weeks (2-8) | Make the class of failure impossible | Organisation-wide guardrail (a policy enforced on every account, not just this bucket) that blocks public buckets. Move workloads to a secret manager and short-lived credentials (temporary tokens that expire on their own). Secret scanning in continuous integration (CI). Run a drill (deliberately create a harmless public test bucket and confirm an alert fires) to prove detection works. |
Evidence of actual use of a credential changes everything: it becomes a full breach response, with legal and privacy teams pulled in for notification obligations.
Fitting limited capacity
Suppose three engineers and 5 working days, so 15 person-days (pd) in week 1. The task sizes below are the team's own estimates, taken from how long similar tasks took before, rounded up to whole days; you would substitute your own.
- Hours phase: 3 pd (all three, one day).
- Days phase: sweep 2 pd + log analysis 3 pd + pipeline fix 3 pd = 8 pd.
- That leaves 15 - 3 - 8 = 4 pd, which starts the credential migration (8 pd in total, so 4 pd remain).
- Weeks phase: remaining migration 4 + guardrail 4 + CI secret scanning 2 + drill 1 = 11 pd, which fits in week 2's 15 pd and leaves 4 pd for interruptions.
Nothing here is dropped, but the deep fixes move to week 2, and that timing is a decision shown to leadership. If an estimate slips, the first thing to move is the drill, never the rotation, and the change is reported the same day. A sign-off record can be one short entry: "Deferred to week 2: the remaining 4 pd of the credential migration (4 of its 8 pd start in week 1), guardrail, CI scanning. Interim control: keys rotated, public access blocked. Owner: named engineer. Date due: end of week 2. Approved by: named VP, date."
Business constraints versus fix depth
The trade-off is fast-and-shallow versus slow-and-deep. Rotating a database password that a nightly batch job depends on can break the business, so the safe fix is: issue the new secret, cut consumers over in an agreed window within 24 hours, then revoke the old one. If no window exists, add a compensating control (a network allow-list so only the batch host can use the password) with a time limit, and record it as an exception. The deep fix (no long-lived passwords at all) is weeks of work and is sequenced, not skipped.
Showing progress
- Time to containment: time from discovery to the last exposed credential revoked (a hard number, reported first). This is different from the exposure period above, which is how long the bucket was readable before anyone noticed.
- Rotation coverage: credentials rotated / credentials found exposed (say 4 / 4).
- Guardrail coverage: buckets passing the public-access check / all buckets.
- Open remediation items by horizon, with the count on plan versus slipped.
Daily one-line update during the first week, then weekly.
Pitfalls
- Fixing the bucket but not rotating the credentials: the copy the attacker already downloaded still works.
- Rotating without checking logs, so nobody learns whether the incident is bigger.
- Letting the weeks phase decay once the incident is off the news. Give each item an owner and a date at once, and report on it.
