Credential Exposure Window
also called Secret Dwell Time, Time to Rotation
The interval between a secret becoming readable outside its intended boundary and the moment it stops being honoured, which is the only quantity a scanner's finding can shorten.
A pipeline secret scanner produces a finding with a timestamp, and the timestamp is almost always misread. It records when the organisation found out. The quantity that determines damage starts earlier - at the commit, the log line, the screenshot in a ticket - and ends only when the issuer stops honouring the credential.
Measuring it as an interval changes behaviour, because it makes visible that deleting the secret from the repository moves neither endpoint. Teams that track it stop arguing about history rewriting and start arguing about rotation automation, which is the argument worth having.
Why it matters
Exposure is not a state to be cleared; it is a duration during which an attacker may have held a valid credential. The follow-up is scoped by it: which audit logs to review, which resources to assume were reachable, which data to treat as read. A team that cannot state the window cannot scope the investigation, so the investigation expands to everything or shrinks to nothing.
The metric also shows where detection spending goes wrong. Moving a scanner from nightly to pre-receive shortens the detection half and does nothing to the rotation half. If rotation needs a change request and a deploy it takes 48 hours, so the fast scanner has bought 8 hours against a 48 hour tail.
Implementation patterns
- Record both endpoints. First exposure from the commit timestamp or log entry, not the alert; revocation confirmed at the issuer, not "rotated" in a ticket.
- Split it into detection time and rotation time, because they have different owners and different fixes.
- Make rotation a one-command operation per credential type before buying better detection. The usual blocker is that nobody knows which services read a given secret - a configuration-management problem wearing a security costume.
- Prefer short-lived credentials so the window has a ceiling that does not depend on anyone noticing: workload identity, 15 minute tokens, per-environment scoping.
- Scan history on onboarding, not only new commits, and treat every hit as live until the issuer confirms otherwise.
Industry example
The 2019 NDSS paper by Meli, McNiece and Reaves on secret leakage in public code repositories scanned public commits in real time for close to six months and found leaks across more than 100,000 repositories, with thousands of new unique secrets appearing every day. The authors describe leakage as rampant rather than exceptional.
Two consequences follow. Discovery is automated and continuous on the attacker side too, so assume a credential in a public commit is known within minutes. And because the volume is routine, handling belongs in a runbook with a measured duration rather than being improvised each time.
Failure scenarios
- Measuring from the alert, which makes the window look like minutes and the handling adequate.
- Treating a private repository as a boundary: every clone, CI cache, fork and laptop backup is outside it, and none can be enumerated afterwards.
- History rewriting counted as remediation, leaving a valid credential and broken branch references.
- Allowlisting a finding to clear the dashboard, which is how a live key survives for a year.
- Rotation that breaks production, so the team learns to delay it - the window's real cause in mature organisations.
Trade-offs
Driving the window towards zero costs credential inventory, automated rotation per credential type, short-lived tokens, and tolerance for rotations occasionally causing an outage. That last cost is underestimated: frequent rotation surfaces every place a secret was hard-coded, which is valuable and disruptive in the same week.
| Choose | Gains | Pays |
|---|---|---|
| Short-lived workload identity | bounded window by construction | migration work and a new failure mode when identity is down |
| Fast detection only | cheap to deploy | leaves the rotation tail untouched |
| Manual rotation on finding | no upfront cost | a window measured in days |
When not to use it
When the credential cannot grant anything. Test fixtures, documented dummy keys and expired credentials produce findings whose window is meaningless, and tracking them dilutes the metric until nobody reads it. Mark them as non-credentials with a reason and keep the metric for secrets an issuer would honour.
It is also the wrong primary metric where secrets are already short-lived and automatically issued: the window is bounded by the token lifetime, and the useful measure becomes the count of long-lived credentials still in existence - a countdown, not a duration.
Interview question
Q: "Your scanner finds an active production database password committed six weeks ago. Walk me through the first two hours, and tell me which number you would report afterwards."
What a strong answer covers: rotate first and audit the credential's use across the full six weeks; the assumption that the secret is known because readers cannot be enumerated; history purge and better detection as follow-ups rather than first steps; and that the number reported is the window split into detection and rotation time, with an owner for whichever half was larger.
Quick check
Quiz: Which shortens the window - deleting the commit or rotating the key? - Rotating, because the window ends when the issuer stops honouring the credential.
Flashcard: Where does the credential exposure window start? - At first exposure, the commit or log line, not the scanner's alert - which is why detection and rotation time are tracked separately.