Secrets Exposure Risk Calculator

How Secrets Exposure Risk Calculator fits into production review

Secrets Exposure Risk Calculator belongs in the first triage pass after a key, token, password, private URL, webhook secret, or credential-like string appears in a pull request, log stream, ticket, build artifact, paste, screenshot, or support bundle. The useful question is not simply whether the text looks secret. The decision needs source, age, scope, provider, privileges, rotation status, and whether the value could still authenticate against a live system.

Different evidence types require different handling. A cloud access key with account-level permissions is not the same as a test token with a disabled prefix. A database URL in a failed CI log carries different blast radius from a public mobile-app API key. A Slack webhook, Stripe restricted key, GitHub PAT, npm token, SSH private key, and signed URL each have their own revocation path and exposure window. Grouping them under one generic severity is how real incidents get under-rotated.

A useful review record should identify where the value appeared, who could read that surface, whether search engines or package registries could have cached it, and which systems need evidence of rotation. For repository incidents, check commit history and forks, not only the current branch. For logs, check retention, export sinks, alert payloads, and third-party processors. For screenshots or tickets, check whether the value was copied into collaboration tools with broad history retention.

When this result can be misleading

Secret-like strings create false positives. UUIDs, hashes, trace ids, sample keys, redacted placeholders, public identifiers, and randomly generated non-credentials can score high on pattern or entropy while carrying no authentication power. A triage system should not burn operator time rotating values that never granted access. Confirm provider format, active status, and permission scope before declaring an incident.

The reverse is more dangerous: low-entropy values can still be sensitive. Basic-auth passwords, shared webhook secrets, legacy API keys, database names, internal bearer tokens, and signed URLs may not look statistically random. Screenshots may reveal only enough of a value to identify the credential family, and partial redaction can still expose account id, environment, or service name. Do not let entropy become the only signal.

Rotation evidence matters more than deletion evidence. Removing a value from the visible page, branch, or ticket does not revoke copies already pulled by bots, build logs, mirrors, or users with access to history. Close the finding only when the old credential is disabled, dependent systems are updated, audit logs show no unexpected use after exposure, and the source that leaked it has a prevention control.

For high-severity exposure, include a minimal timeline: first public appearance, first internal detection, revocation time, last observed use, and the owner who confirmed replacement. That timeline separates a cleaned-up file from a contained credential incident.