Every secret scanner misses some credential types, and teams usually find out which ones only after a leak their tool did not flag. Gitleaks, GitHub secret scanning and TruffleHog are the three most widely used scanners, and their rule sets overlap far less than their marketing suggests: they count coverage in different units, verify in different ways and leave different gaps. This guide compares them on the evidence, using the published rule and pattern data as of 27 October 2026: how each counts and structures its rules, where coverage differs for common credential types, how push protection and validity checks change the picture, and how to combine and extend them so your own credential inventory is covered. It is for AppSec and platform teams choosing or tuning scanners. For evaluating commercial products see the Secrets Scanning Buyer's Guide.
Key takeaways
- The headline numbers are not comparable. GitHub lists 531 patterns (token types), Gitleaks ships 222 rules, and TruffleHog has about 890 detector packages, most covering one provider; each unit means something different.
- No single tool covers everything. Spot checks find types covered by one tool and missed by another in every direction, for example crates.io tokens (no Gitleaks rule, no TruffleHog detector), Snowflake (no Gitleaks rule) and Okta (no GitHub pattern).
- Verification is the biggest functional difference. TruffleHog verifies most detectors against the live service; GitHub validity-checks 165 provider patterns on GitHub.com; Gitleaks verifies nothing and relies on precise patterns and entropy.
- GitHub coverage depends on licence and visibility. 413 patterns are in the partner programme for public repositories; 118 are detected only in private repositories with Secret Protection.
- Coverage should be measured against your inventory. List the credential types your organisation actually issues and uses, then test each scanner against samples of them.
How identity and access work across secret scanners
Each scanner represents "a kind of secret" differently, which shapes what it can find and how it reports it.
| Aspect | Gitleaks | GitHub secret scanning | TruffleHog |
|---|---|---|---|
| Unit of coverage | Rule: id, regex, keywords, optional entropy and allowlists | Pattern: one token type of one provider (secretType) | Detector: Go package per provider, often matching several token formats, with a verification routine |
| Count (27 Oct 2026) | 222 default rules | 531 patterns from 207 providers | About 890 detector packages; the project states over 700 support active verification |
| Generic detection | generic-api-key with entropy 3.5 | Non-provider patterns (private keys, HTTP basic and bearer headers, connection strings) and AI-detected passwords | Detector-led; generic matching is limited |
| Verification | None | Validity checks for 165 provider patterns on GitHub.com; none for generic patterns | Live verification per detector; results labelled verified, unverified or unknown |
| Blocking at commit | Pre-commit hook and CI failure | Push protection on 465 patterns | CI failure with --fail |
| Where it scans | Git history, directories, stdin | GitHub repositories (and other GitHub content as enabled) | Git, GitHub organisations, S3, GCS, Docker images and more |
| Licence | MIT | GitHub feature (Secret Protection for private repositories) | AGPL-3.0 |
The counting difference is not a technicality. GitHub lists GitLab as 12 separate patterns, Gitleaks has 15 GitLab rules (one per token type, from deploy tokens to CI job tokens), and TruffleHog has 2 GitLab detectors. All three may still catch a GitLab personal access token. Compare coverage by credential type, not by totals.
Admin roles and privileged access
Coverage is only useful if the right people can act on findings and the wrong people cannot tamper with rules.
- GitHub: repository owners, organisation owners, security managers, enterprise administrators and users with the admin role can define custom patterns. Only the pattern's creator can edit it or run a dry run. Treat alert dismissal and push protection bypass as privileged actions and review them.
- Gitleaks: the configuration file is the control. Keep a central configuration that extends the default rules (
[extend] useDefault = true), protect it with code owners, and review every allowlist change andgitleaks:allowcomment. - TruffleHog: verification calls third-party APIs with found credentials. Run it under a controlled service identity, limit who can run organisation-wide verified scans, and log those runs.
- Scanner tokens: organisation-wide scans need read access to every repository; that token is itself a high-value secret. See the GitHub Personal Access Tokens Security Guide.
Integrations, API tokens and service accounts
Coverage spot checks by credential type
The table compares coverage for credential types that matter to identity and NHI programmes. It counts entries whose name matches the provider in each tool's published data on 27 October 2026; "none" means no matching rule, pattern or detector was found.
| Credential type | Gitleaks | GitHub | TruffleHog | Gap to watch |
|---|---|---|---|---|
| crates.io API token | None | cratesio_api_token, push protection, no validity check | None | Repositories outside GitHub need a custom rule for the cio prefix |
| NuGet API key | None (only nuget-config-password) | nuget_api_key with validity check on GitHub.com | Detector with verification | Gitleaks users need a custom rule |
| Doppler tokens | doppler-api-token matches personal tokens only | Six token types with validity checks | All documented prefixes, verified | Service tokens (dp.st.) missed by default Gitleaks |
| 1Password service account token | Rule present | Private repositories with Secret Protection only, no validity check | Not checked | Public repository leaks not reported to 1Password through the partner programme |
| Infisical credentials | None | None | Legacy service tokens only | Rely on short TTLs and IP limits, not scanning |
| Snowflake | None | 3 patterns, including programmatic access tokens | Detector | Gitleaks users need a custom rule |
| Okta API token | okta-access-token | None | Detector | GitHub-only programmes miss Okta tokens |
| Generic JWT | jwt and jwt-base64 | Vendor JWTs only | JWT detector with OIDC-based verification | GitHub misses first-party JWTs |
| HashiCorp Vault tokens | vault-service-token and vault-batch-token | Service, batch and root service token patterns, private repositories only, no validity check | Vault detectors | Public leaks of Vault tokens are not reported through the partner programme |
| AI provider keys (Anthropic, OpenAI, Hugging Face) | Rules for Anthropic API and admin keys, OpenAI and Hugging Face tokens | Anthropic 5 patterns, OpenAI 1, Hugging Face 2, with validity checks on some | Detectors with verification | New AI key formats appear quickly; re-test after each scanner release |
| Databricks | One API token rule | 12 patterns including OAuth secrets, refresh tokens and session tokens | Token detector | Gitleaks and TruffleHog miss Databricks OAuth and session credentials |
| AWS access keys | Access key and Bedrock API key rules | 3 patterns with validity checks | Detector, verified | Well covered everywhere |
The individual credential pages go deeper: see the RubyGems, NuGet and Crates.io Publishing Tokens Guide, the Doppler, 1Password and Infisical Service Tokens Guide and the JWT and Session Tokens in Code and Logs Guide.
Encoded and wrapped secrets
Secrets are often committed in a form the pattern does not expect: base64-encoded in Kubernetes manifests, embedded in a JWT, URL-encoded in a connection string or split across lines. Coverage drops sharply in these cases. In the GitHub pattern data, only 21 of 531 patterns are marked as supporting base64-encoded detection; Gitleaks has a specific jwt-base64 rule but most of its rules match the raw form only. Include encoded samples in your coverage test, and where your manifests routinely encode secrets, decode them in a pre-processing step before scanning or use a tool that decodes automatically.
Metadata and context
Beyond detect or miss, tools differ in what they tell the triager. GitHub offers extended metadata (owner, issue and expiry dates) for 70 patterns as a preview feature, and token metadata for GitHub's own tokens. TruffleHog detectors can attach extra data to a result, for example the issuer, algorithm and expiry of a JWT. Gitleaks reports the rule, file, commit, author, entropy and a fingerprint. Rich metadata shortens the time from finding to owner, which is often the slowest step in remediation.
Partner programme and visibility
GitHub's partner programme matters most for public code: when a partner pattern appears in a public repository, GitHub notifies the provider, which can revoke the credential. Of the 531 patterns, 413 are partner patterns and 118 are detected only for private repositories with Secret Protection. GitHub Enterprise Server differs again: 30 of the patterns validity-checked on GitHub.com, including the NuGet API key, are not validity-checked on Enterprise Server, so self-hosted estates should confirm coverage against the documentation for their version. A credential type outside the partner programme can sit in a public repository with nobody told; the Toyota T-Connect Key Exposure 2022 involved an access key that stayed in a public GitHub repository for almost five years.
Logging and detection
Measuring coverage properly
- Build the inventory: list every credential type your organisation issues or consumes: cloud keys, CI and VCS tokens, SaaS API keys, secrets manager tokens, package registry tokens and internal service keys.
- Collect samples: for each type, obtain revoked or test credentials in the real format. Never use live secrets as test data.
- Run every scanner: scan a test repository containing the samples, in realistic contexts (config files, code, environment files, base64-encoded values).
- Record the matrix: detected or not, blocked at push or not, verifiable or not, per tool and type.
- Close gaps: write custom rules for missing types, preferring the tool where blocking happens earliest.
- Re-run on each scanner upgrade: rule sets change frequently; keep the test repository as a regression suite.
Metrics
- Inventory coverage: share of your credential types detected by at least one scanner in your pipeline (target: 100 percent).
- Block coverage: share detected before code reaches the shared repository (pre-commit or push protection).
- Verification coverage: share of detected types that can be validity-checked.
- Custom rule count and precision: number of custom rules and their confirmed true positive rate.
- Duplicate findings: the same secret reported by multiple tools, which shows overlap and helps deduplicate triage.
Hardening baseline
Choosing and combining scanners
| Situation | Practical combination | Why |
|---|---|---|
| All code on GitHub with Secret Protection | GitHub push protection plus custom patterns; Gitleaks or TruffleHog for history and non-GitHub sources | Blocking at push with validity checks, filled out by a second rule set |
| GitHub without Secret Protection on private repositories | Gitleaks pre-commit and CI; TruffleHog verified scans on a schedule | Private repositories get no GitHub-only patterns without the licence |
| GitLab, Bitbucket or self-hosted Git | Gitleaks in CI plus TruffleHog for verification | GitHub patterns do not apply |
| Containers, buckets and artifacts | TruffleHog source scans for images and storage | Repository scanners do not see built artifacts |
| Large incident or acquisition | TruffleHog --results=verified first, then broader triage | Live credentials ranked first |
Rollout
- Pick a primary blocking control: GitHub push protection or a Gitleaks pre-commit hook, depending on your platform and licence.
- Add a second engine in CI: run the other rule set in report mode for a month, compare findings, then decide which rules to enforce.
- Write custom rules for gaps: extend the Gitleaks default configuration or define GitHub custom patterns, using GitHub's dry run (a sample of up to 1,000 matches, across all repositories or up to 10 selected ones) before enabling push protection on them.
- Schedule verified scans: run TruffleHog verified scans across history and artifacts weekly, routing live findings to an incident queue.
- Deduplicate: feed all findings into one triage queue keyed on a hash of the secret, so the same key reported by three tools is one ticket.
Small teams can usually stop at one blocking control plus one scheduled verified scan. Large organisations benefit from a central rules repository, a coverage regression suite and per-rule precision tracking. See the Generic API Key Detection Guide for tuning.
Framework mapping
| Control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | OWASP and ATT&CK |
|---|---|---|---|
| Scanning code and artifacts for secrets | RA-5, SI-4 | DE.CM-09, ID.RA-01 | OWASP NHI2 Secret Leakage; T1552.001 Credentials In Files |
| Blocking secrets at commit or push | SA-11, CM-3 | PR.PS-06 | OWASP CICD-SEC-6 Insufficient Credential Hygiene |
| Credential type inventory | CM-8 | ID.AM-02 | T1078 Valid Accounts |
| Revocation of verified findings | IA-5 | RS.MI-01 | T1552 Unsecured Credentials |
Common misconfigurations
- Choosing by total rule count: a bigger number does not mean your credential types are covered.
- Assuming GitHub covers private repositories: secret scanning on private repositories, including the 118 non-partner patterns, depends on Secret Protection being enabled.
- Running only verified results:
--results=verifiedhides secrets the tool cannot verify, including many internal and HMAC secrets; useverified,unknownfor coverage. - Overriding rather than extending defaults: a custom Gitleaks configuration without
useDefaultsilently drops the built-in rules. - Never re-testing: upstream rule changes can remove or alter detection for a type you depend on.
- Ignoring non-Git sources: images, buckets, wikis and CI logs hold the same secrets.
Practitioner checklist
- List every credential type your organisation issues or consumes.
- Build a test repository of revoked or test samples in realistic contexts.
- Run Gitleaks, GitHub secret scanning and TruffleHog against it and record the coverage matrix.
- Write custom rules or patterns for every gap and add them to the regression suite.
- Enable blocking at commit or push for the highest-risk types.
- Schedule verified scans across history and artifacts, keeping unknown results in scope.
- Confirm Secret Protection coverage for private GitHub repositories.
- Deduplicate findings from all tools into one triage queue.
- Re-run the coverage test after every scanner upgrade.
Standards and references
- GitHub Docs: Supported secret scanning patterns
- GitHub Docs: Defining custom patterns for secret scanning
- GitHub Docs: Evaluating alerts from secret scanning
- Gitleaks: Default rule configuration
- Gitleaks: Documentation
- Truffle Security: TruffleHog
- Truffle Security: TruffleHog detectors
Related NHI Mgmt Group resources: Secrets Scanning Buyer's Guide · Git Secret Scanning Guide · Generic API Key Detection Guide · OWASP NHI Top 10 NHI2 Secret Leakage Guide