LeakWatch looks for credentials that end up in public git *and* in the site you deployed, checks whether they still work, and tells you before a stranger finds them. Here is each part of that, mechanism by mechanism.
Figures frozen at build time (2026-09-18). The live feed is current to the minute.
These tools solve overlapping but different problems. This is where the lines actually fall.
| Criterion | LeakWatchHosted, watches public git | GitGuardianHosted platform, repo-integrated | GitHub secret scanningBuilt into GitHub | TruffleHog / gitleaksOpen-source CLI, you run it |
|---|---|---|---|---|
Finds leaks in repos you don't controlWhy it mattersMost keys leak from a fork, a contributor's own repo, or a snippet — not from yours. GitGuardian does watch public GitHub for an organisation's secrets, including developers' personal repositories, but that perimeter monitoring belongs to its business tiers rather than its free one. | Yes | Partial | No | No |
Verifies the secret is still liveWhy it mattersSeparates a real incident from a string that merely matches a pattern. TruffleHog verifies credentials against providers and can report only the verified ones; gitleaks matches patterns and does not check whether a key still works. | Yes | Yes | Yes | Partial |
Works without installing anythingWhy it mattersThe first scan should cost nothing but a URL. GitHub's scanning runs on repositories hosted there once enabled — it is on for public repositories, but it is not something you can point at an arbitrary repository from outside. | Yes | No | Partial | No |
Gates a CI pipeline with nothing to installWhy it mattersA build step that needs a vendored binary or a marketplace action is one more thing to keep updated and trust. LeakWatch's CI gate is one HTTPS call with curl and jq — the job posts its diff and fails on a non-zero count. ggshield and the open-source CLIs must be installed into the runner image first. GitHub's push protection blocks flagged secrets at push time, but only on repositories hosted there and not as a step you place in your own pipeline. | Yes | Partial | Partial | No |
Covers GitLab and CodebergWhy it mattersNot everything lives on GitHub. | Yes | Yes | No | Yes |
Full git history scanWhy it mattersDeleting the key in a later commit does not remove it from the clone. | Yes | Yes | Yes | Yes |
Scans the site you deployed, not only the repoWhy it mattersA key in the JavaScript bundle your visitors download is live by definition — nobody removed it. The repo-facing scanners read git. Reading what a domain actually serves — bundles, source maps, response headers — is a different perimeter, covered by separate tooling (DAST scanners, bundle checkers) rather than by any of the three. | Yes | No | No | No |
Flags config files served in productionWhy it mattersA readable /.git/ means the whole history is downloadable, rotated secrets included. These are HTTP-layer findings, not git findings: /.env served as plain text, a browsable /.git/ directory, a published source map, missing CSP or HSTS, cookies without Secure or HttpOnly. | Yes | No | No | No |
Correlates a secret across code and productionWhy it mattersCommitted and still served is the only finding that needs no interpretation. Requires seeing both sides at once. A tool that reads only git cannot know whether the key is still deployed; a tool that reads only the site cannot know whether it was ever committed. | Yes | No | No | No |
Detects your own secret formatsWhy it mattersAn internal service, a partner's API, a legacy key prefix — no scanner ships with a pattern for a token only your company issues. Custom detection is common; what differs is who can turn it on. GitGuardian's custom detectors are a Business-plan public beta, and a pattern is submitted as a request that their engineering team validates and deploys rather than something you switch on yourself. GitHub's custom patterns need Secret Protection (formerly Advanced Security) on an organisation-owned repository. The open-source CLIs take custom rules in a config file you own, but you still have to run them on every clone. | Yes | Partial | Partial | Yes |
Priced for a single developerWhy it mattersTeam-priced tools start above what a solo maintainer will pay. GitGuardian has a free tier for small teams; its paid plans are sold per developer seat and aimed at organisations. GitHub's secret scanning is free on public repositories. | Yes | Partial | Yes | Yes |
Compiled from each product's public documentation and pricing pages as of 23 August 2026, for their generally available offerings. These products change often — if a line here is out of date or wrong, write to [email protected] and it will be corrected.
| Feature | Free0€ · forever | Solo4.99€ · per month |
|---|---|---|
| Username check across public git | Yes | Yes |
| Affected repositories and severity | Yes | Yes |
| Deep scan (full git history) | 1 every 30 days | Unlimited |
| Site scan (deployed front-end + config) | 1 every 30 days | Unlimited |
| Repo ↔ site correlation | Yes | Yes |
| Commit URL and full secret | Deep scan only | Every leak |
| Liveness check (is the key still active?) | Deep scan only | Every leak |
| Free trial (14 days, monthly plan) | No | Yes |
| Continuous monitoring | No | Yes |
| GitHub App push-time monitoring | No | Yes |
| Email / Discord / Slack alerts | No | Yes |
| Dismiss a leak as a false positive | No | Yes |
| Public API access | 60 req/min, masked | 300 req/min |
| CI/CD scanning from the API | 50 scans/day | Unlimited + batch |
A string that looks like an AWS key is a guess. A key the provider answers to is an incident.
A pattern scanner can help you detect strings that look like AWS keys, but it cannot tell you whether those keys are actually valid or still provide access. LeakWatch combines 372 detection patterns with 24 provider-specific validators. When a candidate is detected, the corresponding validator makes a single read-only request to the provider to check whether the credential is still accepted.
Supported providers and credential types include AWS, GitHub, GitLab, Stripe, OpenAI, Anthropic, Google, Azure, Discord, Telegram, npm, Hugging Face, database connection strings, private keys, and more.
That call is strictly read-only. Never a write, never a purchase, never a deletion: any credential we find is used exactly once, solely to check whether it is still active, and never again.
A secret deleted in the next commit is still in the history, and history is what an attacker clones.
Removing a key in a later commit does not remove it from the repository. Whoever clones gets every commit ever pushed, so the deleted line is still there,hidden in a `git log`. That's why a current-tree scan can come back clean even when a repository is still leaking secrets.
A deep scan mirrors the full repository, covering every branch, tag, and commit, not just the default branch. It runs in the background, typically taking about a minute, and up to 20 minutes for very large histories. You'll be notified when it's done. Scans run on public repositories you own; the clone itself is anonymous, just like any visitor. The free plan includes one deep scan every 30 days, while Solo removes the limit.
A key in an old commit may have been rotated. A key served by your live site has not.
Everything above looks at your code. This looks at what you deployed. Point LeakWatch at a domain you have verified and it reads what a visitor's browser reads: the HTML, the JavaScript bundles, the inline scripts — and the source maps, which are where hardcoded keys are actually legible. A minified bundle hides a key in a 200,000-character line; its `.map`, published by default by most build tools, gives back the original source with the constant spelled out.
The same pass checks the configuration a server exposes without meaning to: a `/.env` served as plain text, a readable `/.git/` directory (which means the whole history is downloadable, rotated secrets included), a stray SQL dump, a missing Content-Security-Policy, cookies without `Secure` or `HttpOnly`, response headers advertising an exact version. Single-page apps answer `200` on every path, so a naive check reports every one of those files as exposed; LeakWatch fingerprints the site's own not-found response first and requires the body to match the file it asked for.
Because scanning a site means probing paths and returning secrets in the clear, it only runs on domains whose owner has proved control — a DNS TXT record on `_leakwatch.yourdomain`, or a file under `/.well-known/`. Ownership is re-checked before the report is served, not just when the scan starts.
Committed and still being served means nobody rotated it. That is the one finding with no ambiguity.
Group a repository and the domain it ships to into a project, and the report puts the intersection first. A secret found only in git history might have been revoked months ago — you cannot tell from the commit. A secret found only in a bundle might be a publishable key that belongs there. The same value on both sides is neither: it was committed, it was deployed, and it is still live.
That is the finding a repo-only scanner cannot produce, because it never looks at production, and a site-only scanner cannot produce either, because it never looks at the history. It is also the one that tells you what to revoke first.
Install once, pick your repositories, and every push to them is checked as it arrives.
Signing in tells LeakWatch which accounts are yours. The GitHub App is what turns that into monitoring: you install it once, choose the repositories it covers, and repositories you create later can be included without going through the setup again.
It asks for two read permissions and nothing more — Contents (read), to see the code in the commits you push, and Metadata (read), which GitHub requires of every app. No write access, no issues, no actions, no ability to change anything in your repository. On each push GitHub delivers a webhook, the scan is queued on the spot, and the alert follows the scan: there is no polling interval to wait out and no crawl scheduled behind it. Uninstalling the app from your GitHub settings revokes the installation token immediately, and monitoring stops with it.
Email, Discord or Slack — with the provider, the repository, the commit and the revocation steps in the message.
An alert should let you act without investigating first. Each one names the provider and the kind of credential, the repository and the exact commit, and shows the secret masked — enough to recognise the key, never enough to use it. It ends with the link to that provider's own revocation page. The same secret across ten commits is one alert, not ten.
Everything the dashboard shows is available under /api/v1, keyed to your account.
Findings go where you already look: a CI job that fails a build on a live key, a SIEM, an internal dashboard. REST and JSON with a published OpenAPI schema — scans, monitored repositories, your own leaks, the public feed and the detector catalogue are all endpoints. Keys are created and revoked from your dashboard and shown once, at creation.
The build refuses the commit that carries the key — one HTTPS call, no action, no binary.
Every other way of gating a pipeline asks you to install something: an action pulled from a marketplace, a scanner vendored into your runner image, a pre-commit framework to adopt. This one is a request. The job posts the diff it is about to merge, reads how many secrets came back, and exits non-zero if that count is not zero — with curl and jq, which your CI image already ships.
Your content is not kept. The diff is scanned in the worker's memory and discarded when the response is sent — no third party, no model call. Only the result is recorded: how many secrets, of which types and severities, which is what the CI/CD tab of the dashboard lists for 90 days. Never the diff, never a secret value. That is also why this endpoint does not test the key against its provider, unlike the rest of LeakWatch — validating means sending the credential onwards, which is the one thing this route promises never to do.
It complements monitoring rather than replacing it: a gate only sees what goes through your pipeline, and most keys leak from somewhere else — a fork, a contributor's own repository, a gist pasted while debugging.
Further reading: What it costs when the key gets through: rotate, clean, verify
Type a username and you see, without an account, how many secrets tied to it are already public and how bad they are. Sign in and two free scans every 30 days come with it: one deep scan of your full git history, and one scan of a domain you verify. Continuous monitoring is what a subscription adds; the first look never costs anything.
Check a username