# How LeakWatch's secret scanner works — LeakWatch

> Inside the LeakWatch pipeline: ingesting the public commit firehose, 400+ regex patterns, heuristic and ML false-positive filtering, and strictly read-only secret validation.

Source: https://leakwatch.net/blog/how-leakwatch-secret-scanning-works

---

[← Blog](/blog)

# How LeakWatch's secret scanner works

July 20, 2026 · 0xCr0c0 · 4 min read

## Introduction

**What is LeakWatch, and why monitor public forges (GitHub, GitLab, Codeberg)?**

LeakWatch is a service for developers that monitors activity on code hosting platforms in real time, looking for API keys, secret tokens, certificates, and credentials for databases or websites.

By continuously scanning your repositories, LeakWatch makes sure that if you ever leak sensitive data by accident, you hear about it long before someone with bad intentions puts it to use.

Everything described below runs continuously, and you can watch the output of it: the [live feed of leaked API keys](/leaks) lists what the pipeline is finding across GitHub, GitLab and Codeberg as it happens, with every key masked and every repository withheld.

## Data ingestion

### First challenge: ingesting an ocean of code

Every second, platforms like GitHub, GitLab, and Codeberg receive thousands of public commits. Most are innocuous code changes — but every so often, sensitive data gets published by mistake or inattention.

Our scanner uses these platforms’ public APIs and samples “at random” from those thousands of commits to analyze them more closely. To cope with this massive flow — the *firehose* — we use **Celery Beat** to schedule regular collection tasks (every `n` seconds) distributed across workers.

**An important note on our approach:**

Respecting the restrictions imposed by the GitHub and other forge APIs matters to us. That is why we implemented strict rate-limit handling and use ETag caching, so we never overload their servers.

In reality, scanning the ocean of public commits is not the heart of the project. This public analysis is our full-scale playground: it lets us train our algorithms, build a representative dataset, and demonstrate the tool’s effectiveness to the community. **LeakWatch’s primary purpose remains the targeted protection of our customers’ private repositories.** The public firehose is our technology showcase; securing your internal code is our actual mission.

For the curious, the endpoints we use for that public showcase are:

-   `/events` for platforms like GitLab and GitHub
-   `/repos/search?sort=updated` for Codeberg

### Pipeline and detailed commit analysis

Our detection and analysis pipeline is long and intricate, but it breaks down into three stages:

-   **Text-based detection.** This stage analyzes pushed code with more than 400 complex regular expressions, covering a wide range of patterns (cloud keys, AI providers, SaaS, databases).
-   **Heuristic false-positive filtering.** The algorithm looks for patterns typical of fake API keys (`test`, `dummy`, and friends). If the engine judges them too prevalent, the finding is flagged as a false positive.
-   **Machine learning.** We use machine learning models (scikit-learn) trained on hand-labeled leaks to sharpen true-leak detection and suppress false positives.

The list isn’t a secret: every secret type the engine recognizes, with its severity, is published as [the public detector catalogue](/docs) — `GET /api/v1/detectors`, no key required. It’s the same catalogue the scanner runs on, so what you read there is what actually fires.

### Real-time validation: the read-only challenge

Once the algorithm suspects a secret, we still have to confirm it actually works. For classic API keys (`github`, `claude`, `stripe`, and so on), we simply query the provider’s API.

One of LeakWatch’s biggest technical challenges, however, was validating critical secrets — **database credentials** and **AWS keys** — without **ever altering the victim’s environment**. Running a destructive action (writing to a table, modifying cloud resources) is out of the question. So we made a strict choice: only **100% read-only** verification modules. For AWS, for instance, we call nothing but `sts:GetCallerIdentity`; for databases, we list existing schemas and never read the data inside the rows.

This entirely non-intrusive approach lets us confirm ethically and reliably whether a key is still live. We can then judge the severity of the leak, warn its owner, and surface the alert in our interface — while guaranteeing that no collateral damage occurs during verification.

## The real-time interface

Once a leak is confirmed, the clock is ticking. That is why LeakWatch ships a web dashboard built with React that surfaces alerts instantly over **WebSockets**.

As soon as a validated secret clears our pipeline, the information propagates through a Pub/Sub system (Redis) and appears on your screen immediately, with no page refresh. The interface offers dedicated views per provider type (AWS, databases, and so on) and also includes a supervision area for labeling data and tracking our machine learning model’s performance.

## A robust, secure deployment

To support this infrastructure reliably, we run a modern, fully containerized stack:

-   **FastAPI** at the core of the system, for a fast, asynchronous API.
-   **PostgreSQL and Redis** for storage, data redundancy, caching, and the task queue.
-   **Caddy** as the reverse proxy, automatically issuing HTTPS/TLS certificates to secure traffic.

```
              +-------------------------+
              |  GitHub / GitLab /      |
              |  Codeberg public APIs   |   (ETag + dedup cache)
              +------------+------------+
                           |
                           v
              +-------------------------+
              |  Celery worker          |
              |  collectors -> pipeline |
              +------------+------------+
                           |
            +--------------+--------------+
            |              |              |
            v              v              v
        regex_engine    context.py    fp_classifier
                           |
                           v
              +-------------------------+
              |  validator registry     |   live API check per match type
              |  (20 providers + DBs)   |
              +------------+------------+
                           |
                           v
              +-------------------------+
              |  Postgres + Redis pub/  |
              |  sub -> WebSocket -> UI |
              +-------------------------+
```

![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp)

Gabriel Diyan (0xCr0c0)

Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about).

[GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab)

LeakWatch

Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about).

Scan

-   [Product](/product)
-   [Live feed](/leaks)
-   [Trends](/leaks/trends)
-   [API docs](/docs)
-   [CI/CD](/docs?tab=ci)

Read

-   [Blog](/blog)
-   [Changelog](/changelog)
-   [About](/about)

Verify

-   [Security](/security)
-   [Privacy](/privacy)
-   [Terms](/terms)
-   [Legal](/legal)
-   [Contact](/contact)
-   [Status](https://status.leakwatch.net)

© 2026 LeakWatch

[GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)