There's a version of "security tooling" that looks like a dashboard. You connect your repo, you wait, you get a chart of findings with a severity score, and you pay a seat fee to export them.
I don't use those. For secret scanning specifically, I run everything locally — dotguard for env files, git-based checks for history — and the reasons are less ideological than they sound.
Reason 1: the scanner sees your files, and I want to know which ones
A cloud scanner has to receive the file (or the repo, or a snapshot of it) to scan it. "We don't store it" is a policy statement, not a physical one — the bytes crossed a network boundary, and what they touched on the way is outside my audit.
For a lot of codebases that's a fine trade. For the ones I actually care about — client work under NDA, security tooling itself, anything touching payment flows — "the file left the machine" is the line. A local scanner doesn't cross that line. There's no egress to log, no retention policy to trust, no subprocessor list to read.
Reason 2: local tools compose with your existing gates
A cloud scanner's output lives in the cloud. Getting that output into a CI gate, a pre-commit hook, or a release checklist means an API call, an auth token, a webhooks setup, and a failure mode every time the cloud is down or your token expires.
A local scanner's output is an exit code and some text. That's the whole integration:
- name: Scan env files
run: npx @wuchunjie/dotguard .
No token. No network dependency at scan time (well — one npx download on first run, cacheable with a local install). The gate works on an airplane, in a restricted network, in a CI runner that can't reach the scanner's API. For teams in regulated environments where "CI can't call vendor X's API" is a hard requirement, this isn't a preference — it's the only option that works.
Reason 3: you can read the whole tool
This is the one people underestimate. A zero-dependency Node file is maybe 150 lines. I have read all 150 lines of dotguard. I know exactly what patterns it matches, I know it doesn't make network calls (there's no http import, full stop), and I know what it does with a file it can't read (logs an issue, moves on).
A SaaS scanner's matching logic is a black box behind an API. You can read its documentation — which is a description of what it does, written by the vendor, updated when the vendor updates the product. You can't read what it actually does on your file at 3am on a Tuesday.
For a tool whose job is to look at your most sensitive files, "I can read the whole thing" is a property I weight heavily.
The honest counterargument
I'll steelman the cloud version:
- Shared findings across the org. A dashboard aggregates across repos; a local tool gives you per-repo output you have to collect yourself. For a 200-repo org, the aggregation is real value.
- Tuned rules. Big vendors run their scanners against billions of files and tune the patterns accordingly. A small local tool's rules are narrower.
-
History scanning at scale. Cloud tools index your full history; a local
git log -Sis powerful but manual.
All true. My response is that I don't need those features, and for the features I do need (fast, local, CI-integrable, readable), the local tool wins on all four. If I were running security for a 500-repo org, I'd buy the cloud tool and add the local one as the pre-commit layer. I'm not running security for a 500-repo org, so I run the local one and keep my options open.
The practical setup
For a solo dev or small team, the whole stack is three commands:
npx @wuchunjie/dotguard . # scan env files, exit 1 on findings
git log -S "sk_live" --oneline # history check, ad hoc
npx @wuchunjie/gitpulse . # while you're in the repo, check its health
Nothing leaves the machine. The output is in your terminal. The tool is a file you can read. That's the whole pitch, and I'd rather have it than a dashboard.
npx @wuchunjie/dotguard
More Tools
| Tool | What it does | Command |
|---|---|---|
| scaffoldx-cli | Production-ready project templates in seconds | npx scaffoldx-cli |
| dotguard | Scan .env files for exposed secrets | npx @wuchunjie/dotguard |
| gitpulse | Git repo analytics in your terminal | npx @wuchunjie/gitpulse |
| snippetx | Terminal code snippet manager | npx @wuchunjie/snippetx |
If these save you time, consider buying me a coffee. All tools are MIT-licensed, zero-dependency, and run fully offline.
Top comments (0)