Skip to content
Calcrivo

Secrets Exposure Calculator

Quantify hardcoded secret exposure across repositories: scan coverage, finding precision, unrotated live secrets and total exposure days.

Inputs

repos
repos
repos
findings
secrets
secrets
days
secrets

Secret Exposure Score

77.5/ 100

Exposure Level

High

Effective Scan Coverage

52.5%

Finding Precision

42.7%

Live Secrets Not Yet Rotated

13secrets

Cumulative Exposure

2,340secret-days

Unscanned Repositories

60repos

Verdict

Rotate the production-privilege secrets now — treat each one as an active incident, not a backlog item

Step by step

  1. Values used

    Source repositories = 240 repos; Repositories with secret scanning enabled = 180 repos; Public or internet-visible repositories = 12 repos; Secret-scanning findings = 96 findings; Confirmed live secrets = 41 secrets; Confirmed secrets already rotated = 28 secrets; Average age of an exposed secret = 180 days; Confirmed secrets with production privilege = 9 secrets; Commit history depth scanned = Default branch history only — 0.7

  2. Secrets Exposure

    Effective scan coverage = scanned repositories ÷ all repositories × 100 × history-depth factor, where full history counts 1.0, default branch 0.7 and new commits only 0.4.

  3. Exposure scoring

    Exposure score = 2 × unrotated live secrets + 4 × production-privilege secrets + 1.2 × public repository percentage + 0.2 × uncovered percentage, clamped to 0–100.

  4. Secret Exposure Score

    = 77.5 / 100

  5. Exposure Level

    = High

  6. Effective Scan Coverage

    = 52.5

  7. Finding Precision

    = 42.7

  8. Live Secrets Not Yet Rotated

    = 13 secrets

  9. Cumulative Exposure

    = 2,340 secret-days

How it works

Coverage is discounted by history depth because a pre-receive hook only stops the next secret, not the four thousand commits already pushed. The score is driven by unrotated live secrets rather than raw findings, since a finding you have confirmed and rotated has cost you time but no exposure, while one confirmed production key you have not rotated is an open door. Secrets in git history are effectively permanent — forks, clones, CI caches and mirrors all keep the blob — so the only remediation that counts is rotation, and cumulative secret-days is the number that shows how long you have been leaving that undone.

Formulas

Secrets Exposure

Effective scan coverage = scanned repositories ÷ all repositories × 100 × history-depth factor, where full history counts 1.0, default branch 0.7 and new commits only 0.4.

scanCoverage
Share of the estate genuinely covered
historyDepth
Discount applied for scanning less than full history
blindSpotRepos
Repositories with no scanning at all

Exposure scoring

Exposure score = 2 × unrotated live secrets + 4 × production-privilege secrets + 1.2 × public repository percentage + 0.2 × uncovered percentage, clamped to 0–100.

unrotated
Confirmed live secrets minus those already rotated
exposureDayCount
Unrotated secrets × average days exposed

Frequently Asked Questions

How is Secrets Exposure calculated?

Effective scan coverage = scanned repositories ÷ all repositories × 100 × history-depth factor, where full history counts 1.0, default branch 0.7 and new commits only 0.4. Coverage is discounted by history depth because a pre-receive hook only stops the next secret, not the four thousand commits already pushed. The score is driven by unrotated live secrets rather than raw findings, since a finding you have confirmed and rotated has cost you time but no exposure, while one confirmed production key you have not rotated is an open door.

Why does Secrets Exposure matter?

Secrets in git history are effectively permanent — forks, clones, CI caches and mirrors all keep the blob — so the only remediation that counts is rotation, and cumulative secret-days is the number that shows how long you have been leaving that undone.

What values do I need to enter?

This calculator takes 9 inputs: Source repositories, Repositories with secret scanning enabled, Public or internet-visible repositories, Secret-scanning findings, Confirmed live secrets, Confirmed secrets already rotated, Average age of an exposed secret, Confirmed secrets with production privilege, Commit history depth scanned. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Can I remove a secret by rewriting history?

Not reliably. Rewriting drops the commit from your branch, but the blob survives in forks, clones, pull-request refs, CI caches and any mirror, and on most platforms the original commit stays reachable by SHA. Rewrite if you like, but the secret is burned the moment it is pushed: rotate it.

Why is precision worth tracking?

Because low precision destroys the response process. If two thirds of findings are test fixtures and example keys, engineers stop triaging them, and the one real production key arrives in a queue nobody reads. Tune detectors and allow-list known-safe patterns before asking for faster response times.

You might also need