Workflow

Scan GitHub for Leaked Secrets

Enumerate an organization's public GitHub repos and scan full commit history with TruffleHog for leaked keys and credentials.

100%

Notes on this workflow

How It Works

Lists every public repo, then scans each one's full git history for leaked keys.

Repos over 100 MB are skipped so one giant repo cannot stall the run.

Results

A PDF of secrets found, ranked by whether they still work. Values are redacted. Repo list included.

Also writes report.json.

Overview

A key deleted from a repository is not a key that has been rotated. It is still in the commit that added it, still in every fork and clone, and still valid until somebody revokes it. Scanners that look at the current tree report the file is clean, which is true and beside the point.

This reads the history. Every public repository an organization owns is enumerated and cloned, then scanned commit by commit, so a credential that lived for one afternoon in 2023 is still found. Results are ranked by whether the secret was verified as live against its provider, which is the difference between an incident and a chore, and every value is redacted so the report can be shared with the team that has to rotate them. Run against your own organization it is exposure management for the surface you publish on purpose.

No token is required to enumerate or clone. The public API and a git clone are enough.

Pipeline

  1. Read the target organization or user.
  2. Enumerate its public repositories through the unauthenticated API.
  3. Reduce the result to clone URLs.
  4. trufflehog clones each repository and scans its full git history, with the repositories split across the fleet.
  5. Findings collect into one report, ranked by verification state and redacted.

Inputs

  • Target organization or user. The GitHub account whose public repositories are enumerated and cloned. The default is trickest, which runs clean and shows the shape of the report.
  • GitHub token. Not set, and not needed. Enumeration uses the unauthenticated public API and each repository is cloned the way anyone else would clone it. A token with repo scope extends the same scan to private repositories and to code search across GitHub.
  • Repository size limit. The ceiling above which a repository is skipped instead of cloned. It defaults to 100 MB so one data-sized repository cannot hold up the whole run.

Outputs

  • Secrets report (PDF). One document per run, findings ranked by confidence with live-validated secrets first, each value redacted to its first and last four characters.
  • Repository inventory. Every public repository the account owns with its clone URL, last push time and primary language. This is the artifact when no secret comes back.
  • Verification state per finding. Each secret marked verified against its provider or unverified, which is the split between an incident to page someone for and a cleanup task.

Sample output

From a completed run against the trickest organization.

Repository enumeration returns what it needs to clone, plus enough metadata to prioritize:

full_nameclone_urlpushed_atlanguage
trickest/cvehttps://github.com/trickest/cve.git2026-07-31T12:13:17ZHTML
trickest/wordlistshttps://github.com/trickest/wordlists.git2026-07-31T13:16:29Znull
trickest/actionhttps://github.com/trickest/action.git2026-07-30T09:41:02ZGo
trickest/containershttps://github.com/trickest/containers.git2026-07-29T16:22:11ZDockerfile
trickest/dsievehttps://github.com/trickest/dsieve.git2026-07-28T11:05:44ZGo

Which reduces to the clone list the scan runs over:

https://github.com/trickest/action.git
https://github.com/trickest/containers.git
https://github.com/trickest/dsieve.git

No secrets came back from these, which is the expected result for repositories that are meant to be public. The value is in running it before someone else does.

FAQ

Does this need a GitHub token?

No. Repositories are listed through the unauthenticated public API and cloned the way any anonymous user would clone them, so a run works with nothing but the organization name.

What would adding a token do?

A token with repo scope extends the same scan to the organization's private repositories, and to code search across GitHub, which is how you find your keys sitting in somebody else's repository rather than your own.

Why scan the full commit history instead of the current tree?

Because deleting a file does not delete the commit that added it. A scanner that reads only the current tree reports a clean repository while the key is still one git log -p away, in every fork and every clone. This run clones each repository and walks its history for that reason.

What does verified mean on a finding?

That the scan took the candidate secret to the provider it belongs to and the provider accepted it, so the credential is live right now. Unverified findings are pattern matches that still need a human to judge. Rotate the verified ones first.

Why are large repositories skipped?

So one archive-sized repository cannot hold the run open while everything else waits. If a repository above the limit genuinely needs coverage, scan it on its own rather than raising the ceiling for every run.

Get a personalized demo

See Trickest in Action

A 30-minute walkthrough. We map the platform to your stack and answer pricing and deployment questions for your environment.