An env/config security checklist

Q: What's the most-missed item?

Real-looking demo/seed values — teams skip them as examples, but scanners harvest them like live keys.

---

Before you commit config

Config is where most secret leaks start, so a pre-commit checklist is the cheapest security control you can adopt. This is a control inventory, not a pass/fail certificate — each unchecked item is a remediation task.

The checklist

No hard-coded secrets — search for sk_, AKIA, ghp_, passwords, and connection strings. Anything credential-shaped belongs in a manager.
No real-looking demo values — seed and sample files use obviously fake placeholders, never credential-shaped strings.
Insecure settings off — DEBUG=true in anything that looks like prod, wildcard CORS (*), disabled TLS, verbose logging of env vars.
Secret manager wired — values injected at runtime from env / vault / CI secrets, not read from source.
Scanning in CI — a pre-commit hook plus a CI scan step catches both the next accident and what already exists.
Rotation policy — short-lived, auto-rotated keys where the provider allows; a leaked long-lived key is a permanent window.

How to use the output

Each unchecked item becomes a tracked fix with an owner. A scanner like EnvLens generates the finding list (secrets + insecure settings, mapped to weakness types); your tracker assigns the owners. The finished checklist is evidence you looked — not a claim of safety.

What the checklist is not

It is a control inventory for config, not a full security audit. It does not cover application logic, dependencies, or infrastructure beyond the file you scanned. A clean checklist reduces a major exposure class; it does not make the system breach-free.

Authoritative references

OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
CWE-798 (Hard-coded credentials): https://cwe.mitre.org/data/definitions/798.html
OWASP Top 10 (A07): https://owasp.org/Top10/

FAQ

Is this checklist the same as a security audit?

No. It is a config-level control inventory for secrets and insecure settings. It does not cover app logic, dependencies, or infrastructure, and a clean checklist is not a safety claim.

What's the most-missed item?

Real-looking demo/seed values — teams skip them as "examples," but scanners harvest them like live keys.

Do I need both pre-commit and CI scanning?

Ideally. Pre-commit blocks the next accident at the source; CI scanning catches what already exists and what slips through. They cover prevention and detection.

Does EnvLens complete this checklist for me?

EnvLens generates the findings (secrets + insecure settings, mapped to weakness types) and a checklist; assigning owners and remediating stays with your team.

Is EnvLens a guarantee?

No. EnvLens is a config scanner. It is decision-support, not a penetration test, an audit, or a guarantee of a breach-free system.

## Disclaimer

Disclaimer (decision-support, not a security guarantee): EnvLens is a tool that helps teams find leaked secrets and insecure configuration in config files. It is not a penetration test, a security audit, or a guarantee that a system is secure or breach-free. Secret scanning reduces exposure but cannot cover every path; a clean scan is not proof of safety. Verify findings and remediate with qualified security engineers before relying on any result.

Run the env/config security checklist on your next commit — try EnvLens — try EnvLens.