Secret Sprawl Measurement Guide: Metrics That Show Real Exposure

Most organisations can say how many secret scanning alerts they closed last quarter, but not how many working credentials are sitting outside their vaults today. Secret sprawl is the spread of API keys, tokens, passwords and private keys across repositories, CI/CD systems, container images, collaboration tools, developer laptops and now AI agent configuration. Counting alerts measures scanner activity, not exposure. This guide defines the measures that do show exposure, where to collect them, how to build a baseline and a reporting cadence, and which industry figures are worth quoting. It is written for security, platform and identity leads who need to report secret risk honestly to engineering and to the board.

Key takeaways

• Measure live secrets, not alerts. The core number is credentials that still work and sit outside an approved secrets manager; everything else is a supporting indicator.
• Time to revoke beats time to close. An alert closed as "won't fix" or a file deleted from the repository leaves the credential usable, so measure until the issuer rejects it.
• Denominators decide credibility. Coverage figures are meaningless unless they state how many repositories, pipelines, registries and endpoints exist in total.
• Sprawl is spreading off Git. Industry reports now find large volumes of secrets in internal repositories, container images, MCP configuration files and CI runners, so a Git-only metric understates exposure.
• Tie each secret to an identity. Ownership and the non-human identity behind each credential turn a count into a backlog someone can burn down.

What secret sprawl measurement is for

Measurement has three jobs: show how much live exposure exists, show whether controls are reducing it, and show where the next unit of effort should go. NIST SP 800-55 Volume 1 (December 2024) frames information security measures as a way to judge whether policies, procedures and controls are adequate, and NIST SP 800-53 Rev. 5 PM-6 Measures of Performance and CA-7 Continuous Monitoring require organisations to define and track them. For secrets, that means separating three kinds of number.

• Exposure measures: how many valid credentials are where they should not be, and how privileged they are.
• Control measures: coverage of scanning and push protection, share of workloads using a secrets manager or federated identity, bypass rates.
• Response measures: how quickly a found secret is revoked, and how often the same team leaks the same type again.

Report exposure first. Control and response measures explain the exposure number; they do not replace it.

Where secrets sprawl: the surfaces to count

See the Mobile App Security Guide and the CI/CD Pipeline Identity Security Guide for the controls on those surfaces.

The core metrics

Collecting the numbers from a Git platform

GitHub's REST API exposes organisation alerts at GET /orgs/{org}/secret-scanning/alerts (administrators or security managers). Useful filters are state, validity (active, inactive, unknown), resolution (including revoked, wont_fix, false_positive and used_in_tests), is_publicly_leaked, is_multi_repo and is_bypassed. Alert objects carry created_at, resolved_at, push_protection_bypassed, validity, first_location_detected and has_more_locations. Two cautions:

• Resolution is not revocation: only revoked claims the credential is dead, and even that is a human assertion. Re-check validity on a schedule.
• Use hide_secret=true when extracting data into a metrics store, so the reporting pipeline does not become another place secrets sprawl to.

GitHub's security overview also offers push protection metrics (in public preview) filterable by bypass date. Other platforms and scanners have equivalents; normalise them into one schema before reporting.

Building a baseline you can trust

1. Build the denominator first: enumerate repositories (including archived and internal), pipelines, registries, cloud accounts, collaboration workspaces and managed endpoints. Without it, coverage is a guess.
2. Run verified scans per surface: record each finding with surface, location, secret type, verification result and first-seen date. Treat TruffleHog's unknown results and secrets with no validity checker as "unconfirmed", not "safe". GitGuardian's 2026 report states that 46% of critical leaked secrets lack validation checkers.
3. De-duplicate to distinct secrets: the same key in ten repositories is one credential to rotate and one spread score of ten. Use fingerprints or hashed values, never the plaintext.
4. Attach an owner and an identity: map each secret to the service account, app or workload it authenticates, and to a team. Unowned secrets are a metric in their own right.
5. Freeze the baseline and report deltas: publish month-on-month change in live exposed secrets, time to revoke and coverage. Recalculate history when coverage grows, or label the jump as new visibility rather than new risk.
6. Test the numbers: sample ten "resolved" findings each month and check at the issuer that they no longer authenticate. This is the measurement equivalent of an audit mode check.

A worked scorecard

A one-page monthly scorecard keeps the conversation on exposure. The example below uses illustrative values only, to show the shape; it is not benchmark data.

• Show the denominator in the cell: "91% of 1,240" tells a reader that the estate grew, which "91%" alone hides.
• Separate new visibility from new risk: when a new surface such as container registries joins scope, add it as its own line for one quarter before folding it into the headline.
• Keep the narrative short: one sentence on the largest change and one on the next action. Leaders act on direction and ownership, not on raw counts.
• Escalate by privilege, not volume: any live admin credential older than 24 hours goes to the risk owner, whatever the total.

Decision guidance: what to measure first

• Small organisations or startups: start with live exposed secrets and time to revoke across Git and CI only, using built-in platform scanning. See the Startup Identity and Secrets Security Guide.
• Mid-sized organisations: add container registries, cloud storage and collaboration tools, and introduce privilege weighting so effort goes to admin credentials first.
• Large or multi-cloud organisations: measure per business unit and per cloud provider, add sprawl debt by owner and vault adoption, and reconcile findings across overlapping scanners as OWASP recommends.
• Endpoint measurement: only where policy and law allow monitoring developer machines; otherwise measure indirectly through credential types that should never exist on laptops (long-lived cloud admin keys) and through issuer logs. See the Endpoint Privilege Management Guide.
• Agentic and AI workloads: add MCP configuration files, agent repositories and LLM API keys as a separate line so growth in this category is visible.

What the industry reports say, and how to use them

External figures help frame risk but come mostly from vendors who sell detection, so attribute them and never present them as your own baseline.

The useful lessons are structural rather than numeric: credentials outlive their discovery, generic secrets are the hardest to verify, and internal repositories and CI runners hold more than public code.

Detection and reporting cadence

• Daily: new verified findings on any surface, new push protection bypasses, any use of a known-leaked credential in issuer logs.
• Weekly: open live findings by owner and age, time to revoke for the week, unowned secrets.
• Monthly: the full metric set with deltas, coverage by surface, recurrence by team, sample re-verification of resolved findings.
• Quarterly: privilege-weighted exposure trend and vault and federation adoption for leadership, mapped to NIST CSF 2.0 GV.OV-03 (risk management performance is evaluated and reviewed).

Where identity fits

Every sprawled secret is the credential of a non-human identity, and many sprawled secrets are shared by several systems. Identity-backed measurement asks, for each secret, which identity it belongs to, what that identity can do and whether the workload could use a short-lived federated credential instead. Counting identities that still rely on static secrets is often a better programme metric than counting secrets, because removing the static secret ends the sprawl for good. See the Secrets Management Guide and the Cloud Secrets Managers Guide.

Common failure patterns

• Reporting alert closure as remediation: files get deleted but keys stay live. The Docker Hub secrets leak found most removed secrets were never revoked.
• Counting candidates as secrets: raw counts inflate and confuse. In the Twitch breach, GitGuardian reported about 6,600 secret candidates across roughly 6,000 leaked repositories but did not test validity; a credible metric separates candidates, verified and unconfirmed.
• Measuring Git only: during the Shai-Hulud npm worm, credentials were harvested from CI runners and developer machines, and Wiz reported that more than 60% of leaked npm tokens were still valid on 1 December, a week after the wave began. None of that appears in a repository metric.
• Stopping the clock at takedown: in the CISA Private-CISA GitHub leak, the repository was public for about six months and the AWS keys stayed valid for about 48 hours after it was taken offline. Time to revoke must run to the issuer.
• No denominator: "95% coverage" of the repositories the scanner already knows about says nothing about the ones it does not.
• Putting secrets in the dashboard: exporting raw alert payloads into a BI tool creates a new store of plaintext credentials.

Framework mapping

Practitioner checklist

• Build an asset inventory for every surface before reporting any coverage figure.
• Make live exposed secrets (verified or active, outside an approved store) the headline metric.
• Measure time to revoke at the issuer, not time to close the alert.
• De-duplicate findings into distinct secrets and track spread per secret.
• Assign every secret an owner and a non-human identity; report unowned secrets.
• Weight exposure by privilege so admin credentials are fixed first.
• Re-verify a sample of resolved findings every month.
• Add CI runners, container registries, collaboration tools and MCP configuration to scope.
• Keep plaintext secrets out of the metrics pipeline (hide_secret=true, fingerprints).
• Track adoption of secrets managers and federated short-lived credentials as the structural fix.

Standards and references

• NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• OWASP: Secrets Management Cheat Sheet
• GitHub Docs: REST API endpoints for secret scanning
• Truffle Security: TruffleHog documentation
• GitGuardian: State of Secrets Sprawl 2026
• GitGuardian: State of Secrets Sprawl 2025

Related NHI Mgmt Group resources: Git Secret Scanning Guide · Top 10 Secrets Management Mistakes · Secrets Management Buyer's Guide · Application Security Posture Management (ASPM) Guide · Secrets Management Maturity Model