Skip to content

GitHub — Secrets in Code

What this is

GitHub is the world's largest code platform. Over 100 million developers and 400+ million public repositories. Developers make two recurring mistakes:

  1. They commit secrets into code — API keys, tokens, database passwords, private certificates.
  2. They create personal forks of work repositories to "tinker at home" and forget to make them private.

Every such commit lives in git history forever, even after deleting the file or force-pushing.

Why this matters

Secret leaks through public commits are the fastest way to get compromised. Typical scenario:

  1. A dev pastes an AWS key into .env.example, forgetting to comment out the real value.
  2. git push — the key is now in a public repo.
  3. An attacker running background scans of new GitHub commits finds the key within 20-40 seconds.
  4. Five minutes later your AWS has new instances mining crypto for $50k/month.

According to GitGuardian's annual reports, 23 million exposed secrets were detected on public GitHub in 2024. BCP Portal monitors your domain / organization / keywords in new commits, so you find the leak before attackers do.

What we look for

The platform recognizes 80+ secret types, including:

  • AWS — Access Keys, Secret Keys.
  • GitHub / GitLab — Personal Access Tokens, App tokens.
  • Cloud — Google API Keys, Azure tokens.
  • Payment — Stripe live keys, PayPal credentials.
  • AI / LLM — OpenAI, Anthropic API keys.
  • Communications — Slack tokens, Discord webhooks, Twilio.
  • JWTs with production issuers.
  • Private keys — RSA, EC, OpenSSH in any format.
  • Database passwords in connection strings.

Each type has false-positive filters: tests, examples (your-key-here, xxxxxx, EXAMPLE_KEY) are ignored automatically.

What we scan

Without connecting your organization

The platform searches all public GitHub for mentions of your DataSources (domain, brand, keywords). Each match is analyzed for secrets.

With your GitHub organization connected

Additionally we scan:

  • All public repositories of your organization.
  • Public forks by employees — the most common source of leaks.
  • Private repositories of the organization — if you grant the relevant access.

Active key validation (optional)

For some finding types (AWS, Stripe, GitHub) the platform can automatically check if the key still works — this lets you know exactly what needs urgent rotation and what's already dead.

Validation uses read-only requests that don't modify your systems. Enabled via a flag in service settings.

Severity

Severity Criteria
Critical Active secret (AWS / Stripe / OpenAI) in a non-test, non-example file
High Recognized secret type in any file
Medium Generic high-entropy string with keywords password, secret, token
Low Domain or keyword mention without a secret pattern

What you see in the dashboard

A GitHub finding contains:

  • A direct link to the specific line in the repo (github.com/org/repo/blob/.../file#L42).
  • The secret type — e.g., AWS Access Key.
  • Context — ±3 surrounding lines.
  • Commit author and date.
  • Validation status: whether the key is still active (if you enabled validation).
  • Severity and recommended action.

How to connect

Quick start (no OAuth)

Works out of the box — the platform searches public GitHub by your DataSources. Enough for small companies.

  1. Settings → Detection Sources → GitHub → Connect.
  2. Authorize at github.com.
  3. The platform requests minimal permissions: organization read, public and private repo access (if you want private monitored).
  4. Choose which organizations / repositories to monitor.
  5. The first scan starts automatically.

Personal Token vs GitHub App

For small teams a personal access token from one person works fine. For organizations we recommend a GitHub App — it doesn't depend on a single person and has higher rate limits.

Scan schedule

  • Quick mode (search across public GitHub) — hourly.
  • Full scan of your organization — every 6 hours or daily depending on size (a full scan of a large org can take several hours).

FAQ

What to do when an active AWS key is found? 1. Immediately deactivate the key in AWS Console — 30 seconds. 2. Check CloudTrail for suspicious activity over the last few days. 3. Remove the secret from git history (git-filter-repo or BFG). 4. Run a post-mortem: how did the secret end up in code, how to prevent recurrence (pre-commit hooks, secret scanning).

Do we scan other users' private repos? No. Only public ones + your own via OAuth grant. An attacker can't use BCP Portal to peek at someone else's private code.

How many false positives? Type-specific patterns (AWS, Stripe, GitHub PAT) — under 2% false positives. Generic high-entropy matches — 15-20%. Validation mode brings false-positives on active keys to near-zero.

Are the secrets themselves stored in the platform? The keys are stored encrypted, access restricted by role. In reports and exports they are masked (AKIA...XXX). 90 days after resolution the secret is fully deleted.