Limitations
What secretcheck intentionally does not do — read before relying on it.
secretcheck is a pre-commit safety net, not a comprehensive secret-scanning platform. Know what it doesn't cover before treating a clean run as a guarantee.
- Pattern-based, not entropy-based. Rules match known formats (AWS keys, JWTs, private
key headers, etc.) and generic
key = "..."assignments. A high-entropy string that doesn't match any pattern — or a secret split across variables — can slip through. - Staged files only, by default.
secretcheck scanlooks at what's staged for the current commit. Secrets already sitting in git history before you installed the hook are not retroactively found — usesecretcheck scan --allfor a one-off audit of tracked files, or a dedicated history-scanning tool for the full git log. - Local, not a server-side gate. The hook runs on the committer's machine.
git commit --no-verifyor a bypassed/uninstalled hook means nothing stops a secret from being committed — for a hard guarantee, pair this with a server-side check (e.g. a CI step runningsecretcheck scan --all --no-prompton every push). - RE2 regex only for custom rules. No backreferences or lookaheads in
customRulespatterns — this is deliberate (RE2 can't be pathologically slow on adversarial input), but it means some patterns expressible in PCRE can't be written directly.
If you need guaranteed, org-wide prevention (not just a helpful local nudge), run secretcheck in CI as well as pre-commit, and consider it one layer alongside secret rotation and least-privilege credentials — not a replacement for either.