How to count live credentials without confusing matches and keys

Substantially revised October 4, 2026. An earlier version described “roughly 14,000 findings,” “525 live credentials,” a webhook in more than 40,000 locations, and an ownership percentage as observed Cremit results. We could not establish a reproducible population, time window, deduplication rule, or source record for those figures. They have been removed. The useful question remains: what exactly does each count represent?

Start with the unit being counted

One credential can appear in a repository file, its commit history, and a ticket. Those are several observed locations, but may be one credential. A detector can also flag a string that is not a working credential. Record the source occurrence, the deduplicated credential record, and the last verification outcome separately. None of these is interchangeable with the number of accounts or workloads that use the key.

Before reporting a total, state the organization and connected sources in scope, the scan period, the time of the last validity check, the credential types eligible for issuer checks, and how repeated sightings of the same value were grouped. A new source connection can increase the occurrence count without creating a new key. A new check can change a status without changing where the key was found.

Separate live, unresolved, and inactive evidence

Cremit counts a finding-secret record as live when its latest status is ACTIVE or MANUAL_ACTIVE. The second status records a human confirmation; it should not be presented as an automated issuer check. PENDING and UNVERIFIED remain unresolved, and MANUAL_REVIEW_REQUIRED means the type needs a person to assess it. Do not subtract those records from a risk report as though the issuer rejected them.

REVOKED and MANUAL_REVOKED also need context. Cremit distinguishes a credential that was previously confirmed active and is now marked inactive from one never confirmed active. A human-marked revoked status needs its supporting issuer or owner record. Neither current inactivity nor deletion from a source proves that the value was never exposed or used in the past.

GitHub’s own validity-check guidance uses active, inactive, and unknown for supported patterns; unknown includes unsupported or unsuccessful checks. This is another reason a smaller “active” number cannot be read as the full exposure count. The features and supported patterns depend on the repository configuration and plan.

Use the count to decide what to check next

For an active credential, record the issuing service, permission or access scope where available, observed public and internal locations, last verification time, and the assigned responder. For AWS and GCP keys that support it, Cremit can show access analysis, but that analysis does not replace issuer activity logs. The person who authored an exposed file is a lead, not automatically the current owner.

For an unresolved or manually reviewed value, identify which check is missing: unsupported type, transient issuer error, absent context, or a human decision still pending. If the location is public or the value is sensitive, do not wait for a neat count before coordinating containment with the issuer and service owner. For a revoked value, confirm the old value is rejected and review the relevant access window and copies.

A reporting format that can be audited

Report separate rows for observed locations, distinct credential records, currently active (including manually confirmed active, labeled separately), pending or inconclusive, manual review, previously active now revoked, and never confirmed active. Add the snapshot time, source coverage, check provenance, and unresolved cases. A percentage is useful only when its numerator and denominator refer to the same population and period.

Cremit scans supported connected sources and verifies supported credential types. Its inventory can also include vault-only and manually registered records that have no scan finding or automatic validity status. It does not inspect every system, prove misuse, infer every runtime consumer, or automatically rotate or revoke a key. Treat the dashboard as a starting point for an issuer-led investigation, not a universal exposure census.

Primary sources

GitHub Docs — Validity checks and unknown results

GitHub Docs — Evaluating secret scanning alerts

OWASP NHI Top 10 — Secret Leakage