The half-life of a leaked AWS key.

The clock starts before you know it has

When a credential leaks publicly — to a Docker layer, a GitHub commit, an NPM tarball, a sourcemap — the clock starts not at the moment your team becomes aware, but at the moment the artefact becomes externally indexable. The two events are routinely separated by hours. In some cases by months.

The interval between exposure and the team's first awareness is the most damaging gap in most incident response timelines. The interval between awareness and rotation is the gap most incident response runbooks optimise for. The first gap is longer, larger in impact, and harder to close. This report is mostly about the first gap.

Observed timelines

These intervals are reconstructed from pattern observation across many engagements. The numbers below are typical, not extreme. They are also the numbers an audit buyer should plan against.

| Interval | Typical observation | |---|---| | Exposure → first external read | minutes to hours | | First external read → first credential test | minutes | | First credential test → enumeration of permissions | seconds | | Enumeration → first action (read, write, lateral) | seconds to minutes | | First action → team awareness | hours to days | | Team awareness → rotation complete | minutes to hours, if the runbook is ready | | Rotation complete → confidence that no derivative is loose | days to weeks |

The pattern that matters: by the time the team becomes aware, the action interval has already happened. Rotation closes future damage. It does not undo what already occurred.

Attacker behaviour during the action interval

When a credential is genuinely active, automated readers will:

• Test it against the relevant cloud API within seconds of finding it. The test is usually a benign metadata call (sts:GetCallerIdentity for AWS, who-am-i for GCP equivalents) that does not trigger most default-configured alarms.
• Enumerate the principal's permissions via the credential's own permissions, not via probes against the resource set. The enumeration is mostly invisible to resource-level monitoring.
• Move from enumeration to action only if the action is in the readable subset that the principal allows. The order is opportunistic: cheap reads first, then high-value reads (S3 buckets, secret managers, IAM roles), then writes if the principal has them.

The reason the order matters: most teams instrument resource access, not principal enumeration. The enumeration step is the warning that defenders rarely receive.

What a rotation runbook should actually contain

Most runbooks we audit during a Board-Ready engagement focus on the rotation mechanics: how to disable the key, how to issue a new one, how to redeploy. These are necessary. They are not sufficient.

A complete rotation runbook contains:

1. Disable, not delete. The compromised key should be disabled with logging retained, not deleted. The post-incident audit needs the historical record.

2. Audit of the principal's recent activity. Pull the cloud-trail logs for the principal for the window that covers exposure → rotation. Read every action. Tag anything anomalous. This is the part teams skip because it is tedious; it is also the part where the actual damage is bounded.

3. Search for derivative credentials. Did the compromised principal have permission to create access keys, OIDC tokens, or temporary credentials? If yes, the rotation does not stop the derivative. Hunt for any credential issued through the compromised principal in the window and disable it as well.

4. Pivot search. Did the principal have permission to assume other roles? If yes, the attacker may have moved laterally before the rotation. Audit the assumed-role activity for the same window.

5. Reissue the legitimate use. Until the legitimate consumer of the key is reissued, the rotation is not complete from a service-availability standpoint. Coordinate.

6. Public-surface walk. Search every public artefact the team controls for the exposed credential (not the new one). If the exposure source was a registry layer or a GitHub commit, the credential remains discoverable in history even after the rotation. Decide whether to scrub or to accept.

Why "scrub" is often the wrong choice

A common temptation after a credential leak is to scrub the historical artefact — rebase the commit, repush the image without the layer, delete the bucket object. This is rarely the right call.

Three reasons:

1. The credential is already on third-party indices. If exposure was external for more than a few hours, copies of the artefact exist in archives the team does not control. Scrubbing the source does not retract the copies.
2. Scrubbing destroys forensic evidence. The historical artefact is the only record of what the attacker saw. Scrubbing makes the post-incident analysis harder.
3. Scrubbing signals to the attacker. If the attacker is watching the public surface, a sudden scrub confirms detection. They accelerate. They do not slow down.

The right call is almost always: rotate, audit the activity window, and treat the historical artefact as a teaching artefact rather than a thing to hide.

What this means for the audit buyer

When Labs scopes a Board-Ready engagement, one of the questions the CISO asks is "what would happen if a credential leaks tomorrow." The audit produces:

• A list of credentials currently exposed in public artefacts, with the activity-window data needed to bound the action interval.
• A rotation runbook calibrated to the buyer's actual principal graph, not a generic template.
• A finding for each principal that has permission to issue derivative credentials, with a recommendation on whether that permission should remain.

The deliverable is signed by the founder. The retest 14 days later verifies that the rotation propagated through the surface and that no derivative was missed.

A note on disclosure ethics

When Labs observes during pattern research a credential that is not from a Labs client, Labs does not retain the credential, does not test it against the relevant service, and does not publish the artefact location. The standard for responsible observation is "see, classify, forget, and notify if a reasonable contact path exists."

This is documented on /trust as the Observation Doctrine. The discipline matters because the credible reason an audit firm exists is that it does not weaponise what it sees.