I Failed a Build Over One Line in .env. That's the Point.

In late November, a staging API key unknowingly found its way into a public repository. It was part of a `.env` file that had been committed by mistake and never removed. For eleven days, this key circulated through webhook calls from an unknown machine. The irritating aspect was that the team's pipeline was equipped with a linter, type checker, and dependency audit, yet it lacked a specific tool to detect live secrets in files.

The solution was straightforward: add a single CI step that would prevent building when a `.env` file contained potential credentials. This is where the concept of "dotguard" comes in. It's a zero-dependency Node script that scans every `.env*` file in a repository for things like API keys, passwords, tokens, and database URLs. This scan is purely based on regex patterns and takes under a second on a medium-sized monorepo.

The script found five issues in a test project, including hardcoded passwords, API keys, and database URLs. The key feature of this tool is that it exits with a status of 1 when it detects a potential secret. This is the crucial part: when this step fails, the build is halted before any human even looks at the code diff. The CI configuration is minimal, consisting of four lines.

This setup ensures that any commit introducing a secret into a `.env` file triggers an immediate red build, prompting swift fixes. The tool is designed to scan only `.env*` files, meaning secrets pasted into READMEs or test fixtures are not within its purview. It also doesn't touch the git history, so if a secret was committed recently, it won't be detected by the current scan.

However, the tool is effective against the specific issue of fresh secrets entering the repository via a pull request. The initial week of implementing this hard secret gate can be challenging, as developers might commit local `.env.local` files or use temporary credentials for testing. But once people understand the value of this gate, they quickly adapt, making changes like copying `.env.example` to `.env` as a routine.

The true value of this tool lies in its simplicity and effectiveness. By installing and integrating it into the CI pipeline, teams can catch potential security breaches before they become incidents.