Ignore rules cover the whole env family

What this means

Passing means git check-ignore proves that .env, every .env.* variant and every *.bak* file would be ignored by your repo. Failing means at least one spelling in that family would be committed the moment someone creates it. The usual culprit is a rule written for one filename, such as .env*.local, that does not match a backup copy of the same file.

How we test it

This is a local check. You run npx securealy scan-repo on your own machine; it calls git check-ignore against sample paths such as .env.local, .env.local.bak-2026-01-01, .env.production and .env.staging.template, and nothing leaves the machine. Every path matching a rule is a pass. Any path that prints no rule is a fail; there is no warn state for this check.

Why it matters

A rule that covers .env but not .env.local.bak has leaked every token at once. In one of Kenny Hyder's own repos the ignore file said .env*.local, someone saved a backup named .env.local.bak-2026-09-07, the pattern did not match, and the file holding the hosting token, the GitHub token, the database management token and the email provider key was committed and pushed with no warning. Once a secret is in git history it has to be treated as published and rotated. The fix is not care; it is a rule that covers the family and a check that proves it.

The fix

Replace the single-spelling rule in your root .gitignore with the whole family (.env, .env.*, a negation line that re-includes .env.example, *.bak, *.bak-*, *.backup, *.orig, .vercel), and read the rest of the file for any later negation line or any subdirectory .gitignore that undoes it. Then prove it with git check-ignore -v on the sample paths and audit git ls-files for env or backup files already tracked, rotating any secret they hold.

The full runbook is in the Fix Kit, Module 00.

Prompt for your AI

Paste this into the coding agent that built the app. It reproduces the finding and stops before changing anything; the fix steps are in the kit.

Read the root .gitignore and every .gitignore in subdirectories. Do not change any file.
Run: git check-ignore -v .env.local .env.local.bak-2026-01-01 .env.production .env.staging.template
Show me the full output. Each path should print the rule that matched; list every path that printed nothing.
Run: git ls-files | grep -iE '(^|/)\.env|\.bak|\.backup|\.pem$|\.p12$|id_rsa' and show me the output. Anything other than .env.example is a tracked file that may hold a secret.
List every negation line in any .gitignore (a line that begins with the exclamation mark character) and say what it un-ignores.
Tell me what it would take to cover the whole env family, and stop before editing anything.
Finally run: git check-ignore -q .env.local.bak-2000-01-01; echo $? and show me the exit code. Expected 0, meaning covered; 1 means the finding stands.