A leaked API key is the most common, most expensive, most preventable incident in shipping software. Here's the checklist I run on every repo before it sees a push — and the one command that automates all of it.
Your .env holds the truth: DB_PASSWORD, STRIPE_SECRET_KEY, AWS_ACCESS_KEY_ID. It goes in .gitignore immediately, always:
# .gitignore
.env
.env.*
!.env.example
Commit .env.example instead — keys removed, structure kept, so teammates know what to fill in.
DB_PASSWORD=changeme is a secret-shaped hole. Any scanner should flag it:
envguard check --path . --strict
# exits 1 on placeholder / empty / secret-shaped values
The --strict flag makes EnvGuard fail CI on warnings — exactly what you want as a gate, not a report.
If a key ever hit the repo (even once, even deleted), it's in git history forever. Scan history, not just the working tree:
git filter-repo or BFG to scrub, then force-push.A linter that prints a warning and exits 0 is a suggestion, not a guard. Use a scanner that fails the pipeline:
--strict in your workflow as a gate.Don't hand-maintain the template. Derive it from the real file:
envguard generate .env --output .env.example
Values stripped, keys preserved. Commit that, ignore the source.
All of the above — detect, validate, strict-fail, generate template — lives in kryptorious-envguard. Free, MIT, CI-ready. Wire it once:
- name: Env security
run: pip install kryptorious-envguard && envguard check --strict
← Back to Blog · ← Kryptorious Tools
Keep reading: