Not mine, thankfully — a dependency-adjacent sample project I'd cloned to poke at. Sitting in the committed .env, complete and functional: a cloud provider key. I didn't use it and notified the owner, but the episode rearranged my priorities, because my immediate next action was grepping my own repos. What I found: two expired-but-still-committed tokens I'd assumed were gone, and one config file with a staging password in a comment. Small stuff. The breach-report kind of small stuff.
30-second takeaway
- 28.65M new hardcoded secrets landed on public GitHub in 2025, up 34% in a year (industry benchmark — GitGuardian State of Secrets Sprawl 2026)
- 64% of secrets found valid in 2022 were still valid in January 2026 — detection is not remediation (industry benchmark — GitGuardian, 2026)
- CWE-798 mapping converts "found a token" → task list your team can actually work
- 12 seconds to scan a full config tree with CWE classification
(Confession: I cloned a sample dependency project to poke at it, then found a live cloud credentials file committed in its config. Not mine, but it made me go audit my own repos that same night. Found 2 expired tokens and a staging password I'd assumed were gone. (my own repos))
(Caveat: scanning finds secrets but doesn't revoke them. Rotation discipline is still on you. And a scan at T=0 doesn't prevent a commit at T+1 — you need pre-commit hooks too.)
Secrets don't leak dramatically; they leak routinely
The pattern is always the same: it worked locally, the file was in the project, git add . is fast, and "I'll remove it before pushing" — except the removal commit doesn't remove it from history, or the file was never actually in .gitignore, or a different config file (a yaml, a docker-compose, a toml) quietly carried it. Config files are the underestimated leak vector because nobody audits yaml the way they audit .env.
And rotation discipline is weaker than we admit. A key committed two years ago and "rotated" — rotated meaning re-issued, not meaning the old one revoked — is a live secret with a git history.
Audit the configs, not just the .env
EnvScan takes a pasted .env, yaml, or toml config and flags leaked secrets — keys, tokens, passwords — plus insecure settings, mapping each finding to common weakness types with a remediation checklist. The weakness-type mapping is what makes it more than a secret-grep: "this is CWE-798 territory and here's the remediation order" converts a finding into a task list your team can actually work.
Pasting beats wiring for this use case, which is the design point. The moment before you commit a config is exactly when the friction of "run a scanner against this" must be near zero.
What it is not
It sees what you paste — one file at a time, not your repo history. History is where committed secrets live forever, and purging git history is a separate, more invasive operation (BFG or filter-repo, plus revocation of every leaked credential — revocation is the part people skip). It also can't know that PASSWORD=hunter2 is fake: expect some false positives on obviously-placeholder values, and treat anything it flags in a file bound for a real environment as real until proven otherwise.
The ten-minute hygiene pass
Run your project's config files through EnvScan — the yaml and toml ones too, not just .env. For anything it finds, the remediation order matters: revoke first, rotate second, purge history third, and fix the .gitignore and pre-commit guard last so it doesn't recur. If the scan comes back clean, check whether that's because the secrets are gone or because you didn't paste the file that has them.
FAQ
What is EnvScan?
EnvScan takes a pasted .env, yaml, or toml config and flags leaked secrets — keys, tokens, passwords — plus insecure settings, mapping each finding to common weakness types with a remediation checklist. The weakness-type mapping…
Why does "Secrets don't leak dramatically; they leak routinely" matter?
The pattern is always the same: it worked locally, the file was in the project, git add . is fast, and "I'll remove it before pushing" — except the removal commit doesn't remove it from history, or the file was never actually in…
What about "Audit the configs, not just the .env"?
Pasting beats wiring for this use case, which is the design point. The moment before you commit a config is exactly when the friction of "run a scanner against this" must be near zero.
References
- CWE-798: Hard-coded Credentials — MITRE's entry for credential exposure in source — the exact class of leak this tool hunts.
Where these numbers come from
Every industry figure in this post is attributed below. Everything marked (my own ...) is my own measurement and is not an industry rate.
- GitGuardian State of Secrets Sprawl 2026 — 28.65M new hardcoded secrets on public GitHub in 2025; 64% of 2022 secrets still valid in January 2026.
Top comments (0)