Secrets Exposure Calculator
Quantify hardcoded secret exposure across repositories: scan coverage, finding precision, unrotated live secrets and total exposure days.
Inputs
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
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
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.
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.
Secret Exposure Score
= 77.5 / 100
Exposure Level
= High
Effective Scan Coverage
= 52.5
Finding Precision
= 42.7
Live Secrets Not Yet Rotated
= 13 secrets
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
- Infrastructure as Code Risk CalculatorCommonly used together
- Secrets Rotation CalculatorCommonly used together
- Supply Chain Security CalculatorCommonly used together
- Cloud Key Management CalculatorCommonly used together
- Cloud Security Health Score CalculatorAlso in Cloud Security
- Cloud IAM Risk CalculatorAlso in Cloud Security