Gitleaks + TruffleHog → GitGuardian
Gitleaks + TruffleHog ↔ GitGuardian: integration to migration path.
GitGuardian is your system of record for secret incidents, so we never re-point every repo on a single day. Gitleaks and TruffleHog stand up alongside GitGuardian first, run advisory in CI while their recall is measured against real incidents, and only then take over the CI gate detector by detector — putting rules-as-code, live verification and air-gapped local scanning in your hands. No flag day, no mass secret-rotation event, and every step rolls back via config in minutes.
The honest exception: GitGuardian's Public Monitoring and honey-token-as-a-service have no OSS parity. Our recommended exit keeps GG on that SKU and retires only what the OSS chain genuinely covers.
The idea
Run advisory to prove recall. Gate detector by detector.
The topology that makes this zero-downtime is advisory-first with a baseline: Gitleaks and TruffleHog run in CI against the same repos GitGuardian watches, a committed baseline file suppresses pre-existing findings so only net-new secrets surface, and both engines normalise into DefectDojo where their stream is compared against GG's incidents. GitGuardian keeps owning incident state, Public Monitoring and honey tokens while OSS recall against live secrets is measured. Only once recall clears threshold do we promote Gitleaks to blocking one high-confidence detector at a time, then retire GitGuardian Internal Monitoring per repo — each step config-only, each reversible.
The phases
Six steps. Each one reversible.
Baseline & inventory
We document per-repo open-incident counts by severity, validity distribution, mean time to remediation, every custom detector in the GitGuardian console, the honey-token inventory and its callback destinations, and SCIM / SSO connections — pulled read-only from the GG API and cross-referenced against git-host activity to exclude dead repos.
Stand up Gitleaks in CI (advisory)
Gitleaks runs in CI on every PR in warn-mode, writing SARIF to artifacts and DefectDojo. A committed .gitleaks-baseline.json captures pre-existing findings so only net-new secrets surface, and the ruleset starts as the upstream default with org rules added by PR. GitGuardian still owns incidents.
Add TruffleHog with live verification (advisory)
TruffleHog runs per-PR with --only-verified so the finding count drops to currently-live secrets — the right signal for a build gate. Outbound allowlists are updated for provider verification endpoints, and the combined OSS stream is compared against GitGuardian's incidents on the same repos.
Promote Gitleaks to blocking, one detector at a time
High-confidence detectors — AWS keys, GitHub PATs, Slack tokens, GCP service-account JSON, generic high-entropy secrets — flip to blocking per rule after a warn-mode soak. The pre-commit hook rolls out via .pre-commit-config.yaml, opt-in then required. Long-tail rules stay advisory until tuned.
Decommission GitGuardian Internal Monitoring, per repo
Repos with at least 30 days of OSS coverage and zero verified GG-only findings have Internal Monitoring disabled in waves — incidents go read-only, not deleted. We monitor 14 days per repo, routing any GG-only finding to a migration triage queue, with sign-off before each wave. Public Monitoring and honey tokens stay live.
Decide Public Monitoring + honey tokens
An explicit org decision, not a default: retain GitGuardian on the Public Monitoring plus Honeytoken SKU only (recommended), or fully retire GG and accept the public-surface and honey-token gaps, optionally piloting canarytokens.org and a trufflehog github --org cron for partial coverage.
Feature parity
Where the OSS chain matches GitGuardian, and where it doesn't.
| Capability | Gitleaks + TruffleHog | GitGuardian | Parity |
|---|---|---|---|
| Scan type (secrets) | Gitleaks regex plus entropy detectors; TruffleHog ~800 detectors | GitGuardian detector engine | At parity |
| Live credential verification | TruffleHog --only-verified against provider APIs | GG validity field (valid / invalid / unknown) | At parity |
| Finding format (SARIF) | Gitleaks SARIF 2.1.0 / JSON / JUnit | GG API / webhook; SARIF export per tier | Partial |
| Rule authoring | .gitleaks.toml rules; fork TruffleHog Go detectors | Vendor-managed; custom detectors in GG console UI | OSS only |
| Pre-commit / pre-receive hooks | pre-commit framework hook; server-side pre-receive (GHES / GitLab) | ggshield secret scan pre-commit (networked API call) | At parity |
| Baseline / diff scanning | --baseline-path .gitleaks-baseline.json; TruffleHog --since-commit | GG "new incidents only" view | At parity |
| Public-internet leak monitoring | trufflehog github --org cron (partial) | GG Public Monitoring (gists, paste sites, Postman, Docker Hub) | SaaS only |
| Honey-token-as-a-service | None (canarytokens.org partial) | GG Honeytoken with vendor-side callback telemetry | SaaS only |
| Incident-triage workflow | DefectDojo engagements plus SLA plus Jira routing (rebuild) | GG incident to assignee to SLA to Slack / Jira / Teams | Partial |
| Dashboards / reporting | DefectDojo / GH code-scanning | GG dashboard plus cross-org benchmark | Partial |
| API surface | Gitleaks / TruffleHog CLI plus JSON | GG REST API (incidents, honeytokens) | At parity |
| Deployment model | Self-hosted compute on CI minutes | SaaS vendor-hosted | OSS only |
| Cost model | Compute-only on org CI minutes | Per-developer or per-repo licensing | OSS only |
| Compliance (SOC 2) | Self-owned evidence (DefectDojo plus CI logs) | Inherited GG SOC 2 vendor boundary | SaaS only |
What we're honest about
The caveats most vendors leave out.
Public-internet leak monitoring has no OSS parity
GitGuardian continuously crawls public GitHub, gists, GitLab.com, Bitbucket Cloud, Postman, Docker Hub, paste sites and dev forums for org-attributable leaks — and the attribution graph linking a leak back to your org is the proprietary lift. A trufflehog github --org cron closes the single largest bucket; the rest is, honestly, gap. We retain GG Public Monitoring rather than pretend the cron is parity.
Honey-token-as-a-service has no OSS parity
GitGuardian issues fake AWS / GitHub / Slack / GCP / Azure tokens programmatically and alerts with source IP, user-agent and timestamp on any internet use. canarytokens.org covers AWS and DNS only, at project tier. We keep the GG Honeytoken SKU or pilot canarytokens.org accepting partial coverage — we don't claim a replacement that isn't there.
The incident-triage workflow is rebuild work, not drop-in
Gitleaks and TruffleHog have no incident model. DefectDojo gives the primitives — engagements, SLA timers, CODEOWNERS routing, Slack and Jira webhooks — but re-implementing GitGuardian's incident-to-assignee-to-SLA flow is real work. We budget at least two sprints for the DefectDojo build before Phase 4 and export GG incident history before any SKU is cancelled.
Live verification and history rewrite carry real operational weight
TruffleHog's --only-verified makes outbound calls to provider control planes — AWS STS GetCallerIdentity shows in CloudTrail — so CI egress must be enumerated, and you give up GitGuardian's inherited SOC 2 boundary. History rewrite is theatre without provider-side rotation first: the secret persists in forks, reflog and Wayback. We rotate, then rewrite, then force-push on a scheduled window.
Why this beats a flag day
Reversible per step, soaked before you cancel.
Through Phase 4 every step rolls back in under 15 minutes — pre-commit hooks, CI gates and aggregator parsers all flip via config with no data migration, so a bad detector is a config-only PR and a re-enabled GG repo is one admin toggle. We never disable Internal Monitoring on a repo until it has soaked at least 30 days of OSS coverage with zero verified GG-only findings, then 14 more days read-only. The one step that is not sub-15-minute reversible is cancelling the GG SKU in Phase 5 — contractual, over 24 hours to reactivate — which is exactly why it sits last, behind an explicit org decision.
See whether the OSS chain covers your secrets surface.
A call with a senior AppSec engineer. We inventory your repos, custom GG detectors and honey-token program, separate the CI and pre-commit scanning the OSS chain reproduces from the public-internet monitoring that stays on GitGuardian, and tell you honestly whether this is full retirement or a SKU reduction.
Map my migration →