Should a secret-named setting get a literal value in a committed file?
Secret-named setting assigned a literal value
Warning: the name is the evidence: very likely a secret, reported so a human can decide.
What happens
DB_PASSWORD=hunter2 in a .env, "client_secret": "…" in a JSON config, api_key = '…' in a settings module, password: … in a YAML manifest, a key whose name says secret, given a literal instead of a reference. The name is the evidence, so this is a warning rather than a certainty: the scanner stays silent when the value is a placeholder, an environment or template reference, a hash, a type annotation, or a word like example or test, and on names that merely contain the word (password_hash, token_type, api_key_id).
Why it is dangerous on a populated table
Table size does not change this one: a committed credential is live from the first row, and git history keeps it after the fix.
Fires on
DB_PASSWORD=hunter2
STRIPE_SECRET="sk_live_…"
"client_secret": "0f3a…"The safe pattern
Keep the name, drop the value: read it from the environment or a secret manager at runtime and commit a placeholder or an example file (.env.example with empty values). Rotate anything that was already committed, git history keeps it.
DB_PASSWORD=${DB_PASSWORD}
# or, in .env.example:
DB_PASSWORD=How to check locally
This rule runs locally in the free CLI, or with the full corpus through the hosted service. No install, nothing leaves your machine:
npx bolvrk secrets "src/**" ".env*"