Gitleaks has settled in as the most-deployed open source secret scanner, and the right way to run it has evolved noticeably over the last two years. The defaults are reasonable but rarely optimal, and a few specific recipes turn it from a noisy nuisance into a tool engineers actually keep enabled. This post collects the configurations we have found durable in production.
Where should Gitleaks run in your pipeline?
The honest answer is: in multiple places, with different rule strictness at each. A pre-commit hook with a small, high-confidence ruleset catches the bulk of accidental commits before they ever leave a developer's laptop, with sub-second performance on most repos. A pre-receive hook on the Git server, or a required CI check at the PR level, runs the full ruleset and blocks merges. A nightly full-history scan, with the broadest rules and slower performance, catches drift and validates that historical scrubbing held.
The mistake we see most often is running only the CI check, which means developers find out their secret was committed after they have already pushed. The pre-commit hook is the single highest-leverage change for most teams, and the friction is acceptable if the ruleset is tuned for low false positives at that stage.
How do you tune for a monorepo?
The monorepo problem with Gitleaks is allowlists. The default config will flag every test fixture, snapshot file, and example configuration in a large repo, and the resulting noise drives developers to disable the tool. The right pattern is a per-path allowlist with specific rules disabled for specific directories rather than global excludes. The .gitleaks.toml format supports per-rule path filters and per-path regex exceptions, which is what you want for managing this at scale.
A second monorepo-specific recipe is to scan only changed files in PR-level CI rather than the full repo. The git diff scoping reduces scan time from minutes to seconds and matches what reviewers actually care about. Reserve full-repo scans for the nightly job. Gitleaks supports both modes directly via the protect and detect subcommands.
What about custom rules for internal secret formats?
Most organizations have internal credential formats not covered by Gitleaks defaults: internal service tokens, signed JWTs with a recognizable issuer, custom API key prefixes, and database connection strings unique to their stack. These are the highest-signal rules you can add because false positive rates on internal formats are essentially zero. The rule syntax is regex-based with optional entropy filtering, and a well-tuned rule for a specific internal format is a 15-minute exercise.
The pattern we recommend is treating internal rules as code, reviewed and versioned like any other security control. A registry of approved internal credential formats lives in a central repo, and the Gitleaks config across the organization references it. When a new internal format is introduced, the rule lands at the same time and propagates without per-team work.
How do you handle the historical secret problem?
A new Gitleaks installation typically finds dozens or hundreds of historical secrets in any non-trivial repo, and the response to that initial scan determines whether the program succeeds. The wrong response is to demand rewriting Git history, which breaks every fork and clone and produces immense friction for marginal benefit on most historical secrets. The right response is to triage: rotate any credentials still valid, document the rest as known historical findings, and configure Gitleaks to baseline against the existing state going forward.
Gitleaks supports baselining via the --baseline-path flag, and a baseline file checked into the repo lets you adopt the tool without flooding developers with historical alerts. The baseline should be reviewed quarterly and shrunk over time as the underlying findings are remediated. Treat the baseline as technical debt to pay down, not as a permanent exemption list.
What about non-Git secret leaks?
Gitleaks scans Git repos, which means it misses the substantial fraction of secret leaks that happen in CI logs, container images, deployed artifacts, and chat messages. The recipe we use is Gitleaks for source, plus complementary tools for the other surfaces: TruffleHog for CI logs and container layers, custom log scrubbing in your observability stack, and Slack DLP for chat. These are different tools because they require different scanning models, and trying to do everything in Gitleaks produces a worse outcome than running purpose-built tools at each surface.
The integration pattern that works is centralizing findings from all surfaces into a single secret leak inventory, deduplicating across sources by credential fingerprint, and routing to a single response runbook for rotation and root cause analysis.
How Safeguard Helps
Safeguard integrates Gitleaks findings, plus TruffleHog, plus container image scans, into a unified secret inventory deduplicated by credential fingerprint. Griffin AI distinguishes test fixtures and example credentials from real secrets using context analysis, which reduces the actionable alert volume by 60 to 80% on typical monorepos. Policy gates enforce pre-commit Gitleaks adoption across repos and block merges that introduce new secrets, with override workflows that require security review. Our zero-CVE base images and SBOM tooling reduce the secondary scanning load on container layers, and TPRM monitors vendor disclosures of credential leaks so you know to rotate when an upstream supplier is breached.