Okay, so I’ve been running GitHub Advanced Security for my team for about six months now, and while the secret scanning is fantastic for catching secrets in the code itself, I keep hitting this same wall.
We had a near-miss last week where a `.env.example` file (meant for onboarding) was accidentally committed with real-looking placeholder values. It didn’t trigger anything because, as far as I can tell, secret scanning primarily trawls through the repository code but seems to treat common config and environment file patterns differently? Or maybe it just doesn’t scan them with the same intensity.
Here’s my thinking:
- So many modern leaks come from config files—`.env`, `config.yaml`, `*.toml`, `*.properties`, even `docker-compose.yml` sometimes.
- We use the push protection rules, and they’re great for blocking a secret key in a `.py` file, but they didn’t flag a database URL pattern in a `docker-compose.override.yml`.
- I know you can add custom patterns, which I’ve done, but it feels like the out-of-the-box patterns for secrets should *also* aggressively scan recognized config file formats. It’s where secrets are most likely to *live*, right?
Am I missing a setting? Or is this a genuine gap? I’d love to hear how others are handling this.
What I’ve done as a workaround:
- Created a custom pattern for our internal secret format and set it to scan all file types.
- Added a pre-commit hook that does a secondary scan for config files.
- But it feels like this should be a native, emphasized part of the service.
Has anyone else built a more elegant workflow for this? Or is everyone just accepting that config files are a blind spot?