GitHub Secret Scanning: What It Catches and What It Misses

GitHub secret scanning is a built-in feature that automatically detects credentials committed to GitHub repositories. It covers over 200 token formats from 100+ service providers—including AWS, Stripe, OpenAI, Google Cloud, Slack, and Twilio—and can alert both the repository owner and the token issuer within seconds of a push.

For public repositories, secret scanning is enabled by default and free. For private repositories, it requires GitHub Advanced Security (GHAS), a paid add-on available to GitHub Enterprise customers. Since 2024, GitHub has also offered push protection—a feature that blocks pushes containing detected secrets before they reach the repository.

This makes GitHub secret scanning the most accessible credential detection tool available. It requires zero setup on public repos and catches the majority of common credential formats. But as part of a complete credential security strategy, it has meaningful blind spots that leave teams exposed if they treat it as their only line of defense.

GitHub secret scanning is a strong baseline, not a complete solution. It doesn't scan git history, can't detect custom secret formats, and push protection can be bypassed. Pair it with a dedicated scanner like gitleaks or TruffleHog for full coverage.

How GitHub Secret Scanning Works

GitHub's scanning operates at two layers:

Partner Program Alerts

When GitHub detects a secret matching a partner's token format, it notifies the partner directly. The partner can then auto-revoke the credential. This happens automatically on all public repositories.

Partners include: AWS, Azure, Google Cloud, Stripe, Twilio, SendGrid, Slack, npm, PyPI, NuGet, Mailchimp, Shopify, DigitalOcean, OpenAI, Anthropic, and 100+ others.

The partner notification is the most powerful feature of GitHub's scanning. When it works, the credential is revoked before the developer even sees the alert—the token issuer acts on GitHub's notification and invalidates the key automatically.

User Alerts

Repository administrators receive alerts in the Security tab when secrets are detected. Alerts include:

The secret type and provider
The commit SHA and file location
When the secret was first detected
Remediation suggestions


Security → Secret scanning alerts → [Alert detail]
├── Secret type: Stripe API Key (sk_live_)
├── Location: config/payments.js:14
├── Commit: abc123f
├── Detected: 2026-03-13T08:00:00Z
└── Status: Open

Push Protection

Push protection is the proactive layer. Instead of alerting after a secret is committed, it blocks the push entirely:

Developer runs git push
GitHub scans the push payload for known secret patterns
If a secret is found, the push is rejected with an error message
Developer must remove the secret and push again

Push protection is available for public repositories (free) and private repositories (requires GHAS).

Setup Guide

Public Repositories

Secret scanning is enabled by default on all public repositories. No configuration needed. Partner alerts fire automatically.

To enable user alerts:

Go to Settings → Code security and analysis
Enable Secret scanning
Optionally enable Push protection

Private Repositories (GHAS Required)

For organizations with GitHub Advanced Security:

Go to Settings → Code security and analysis (org level)
Enable GitHub Advanced Security for target repositories
Enable Secret scanning and Push protection


# You can also enable via the API
curl -X PUT \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/OWNER/REPO/properties/values" \
  -d '{"security_and_analysis":{"secret_scanning":{"status":"enabled"},"secret_scanning_push_protection":{"status":"enabled"}}}'

Custom Patterns (GHAS)

Organizations with GHAS can define custom secret patterns using regex:

Go to Organization Settings → Code security → Secret scanning
Click New pattern
Define the regex pattern, optional keywords, and test against sample content

Example custom pattern for an internal service token:


Pattern: svc_[a-zA-Z0-9]{32,64}
Before secret: ("|'|=|\s)
After secret: ("|'|\s|$)

Custom patterns are applied to all repositories in the organization and generate the same alert workflow as built-in patterns.

What GitHub Secret Scanning Catches Well

High-Coverage Provider Detection

GitHub's partnership program means the most common credential types are well-covered:

Provider	Format	Auto-Revocation
AWS	`AKIA[0-9A-Z]{16}`	Yes
Stripe	`sk_live_[A-Za-z0-9]{24,}`	Yes
OpenAI	`sk-proj-[A-Za-z0-9]{48,}`	Yes
GitHub PAT	`ghp_[A-Za-z0-9]{36}`	Yes
Google Cloud	Various service account formats	Yes
Slack	`xoxb-`, `xoxp-`, `xoxs-`	Yes
Twilio	`SK[0-9a-fA-F]{32}`	Yes
npm	`npm_[A-Za-z0-9]{36}`	Yes
SendGrid	`SG.[A-Za-z0-9_-]{66}`	Yes

The auto-revocation loop—GitHub detects the secret, notifies the partner, partner revokes the key—is the fastest remediation path available. It happens without developer intervention. When auto-revocation doesn't fire, you'll need to follow a manual emergency response process.

Push Protection Effectiveness

Push protection catches the most common leak vector: a developer accidentally including a credential in a commit and pushing it. GitHub's 2024 data showed push protection blocked over 1 million secret pushes in its first year, with a low false positive rate on supported patterns.

Zero-Configuration Baseline

For public repositories, scanning starts immediately. No CI pipeline changes, no pre-commit hook installation, no tool dependencies. This makes it the lowest-friction option for solo developers and open-source maintainers.

What GitHub Secret Scanning Misses

1. No Git History Scanning

GitHub secret scanning only analyzes commits as they're pushed. It does not scan existing git history.

If a secret was committed six months ago, removed in a subsequent commit, and is still in git history—GitHub won't flag it. The secret remains accessible via git log, in forks, and potentially in GitHub's commit cache.

Why this matters: The most dangerous leaked secrets are the ones nobody knows about. A historical scan is the only way to find them. Tools like TruffleHog and gitleaks with --log-opts handle this. See Secret Scanning in CI/CD: detect-secrets vs gitleaks vs TruffleHog for details.

2. No Custom Secret Detection (Without GHAS)

Without GitHub Advanced Security, you can't define custom patterns. If your organization uses internal service tokens, custom API key formats, or non-standard credential patterns, GitHub's built-in scanning won't detect them.

Even with GHAS custom patterns, the detection is regex-only—no entropy analysis, no verification.

3. No Credential Verification

GitHub tells you that something looks like a Stripe key. It doesn't tell you whether that key is currently active. The difference matters for triage: a verified active credential is a P0 emergency; an expired or test credential may be informational.

TruffleHog's verification model fills this gap—it actually tests detected credentials against provider APIs. See the tools comparison for how this works.

4. Push Protection Can Be Bypassed

Developers can bypass push protection by providing a reason (false positive, used in tests, will fix later). GitHub logs the bypass, but the secret still reaches the repository.

This is a design choice—GitHub prioritizes developer velocity over hard blocks. But in practice, "will fix later" often becomes "never fixed."

Organizations can configure push protection to not allow bypasses, but this requires GHAS and organization-level enforcement.

5. Limited Scope: Only GitHub

GitHub secret scanning only works on GitHub-hosted repositories. If your team uses GitLab, Bitbucket, Azure DevOps, or self-hosted Git servers, GitHub's scanning doesn't apply. This is obvious but worth stating: platform-native tools only protect one platform.

6. No CI/CD Log Scanning

Secrets leak through CI/CD build logs as often as through code commits. A printenv during debugging, a verbose test output, or an improperly masked variable can expose credentials in build logs. GitHub secret scanning doesn't analyze workflow run logs or build artifacts.

7. No `.env` File Awareness

GitHub scanning analyzes file content for secret patterns but doesn't have special handling for .env files, Docker Compose secrets, Terraform state files, or other configuration formats where secrets commonly appear. If a credential doesn't match a known pattern, it won't be flagged—even if it's obviously a secret based on the variable name (DATABASE_PASSWORD=hunter2).

GitHub Secret Scanning vs. Third-Party Tools

Capability	GitHub Secret Scanning	gitleaks	TruffleHog
Auto-setup (public repos)	Yes	No (requires install)	No (requires install)
Provider auto-revocation	Yes (100+ partners)	No	No
Push protection	Yes	Via pre-commit hook	Via pre-commit hook
Custom patterns	GHAS only	TOML config	Go plugins
Git history scanning	No	Yes	Yes
Credential verification	No	No	Yes (700+ verifiers)
Entropy-based detection	No	Limited	Yes
CI/CD log scanning	No	No	Yes (with integrations)
Non-GitHub platforms	No	Yes	Yes
SARIF output	Yes	Yes	Yes
Offline operation	No	Yes	Partial (no verification)
Cost	Free (public), GHAS (private)	Free (MIT)	Free (open-source)

The Practical Recommendation

Use GitHub secret scanning as your baseline—it's free, zero-config, and the partner auto-revocation loop is genuinely powerful. Then layer additional tools:

GitHub secret scanning — Catches partner-format secrets, auto-revokes, alerts in the GitHub UI
gitleaks pre-commit hook — Catches secrets before they reach GitHub, works offline, covers custom patterns
TruffleHog periodic scans — Sweeps full git history, verifies which credentials are active, covers entropy-based detection

This three-layer approach means:

Secrets are caught at commit time (gitleaks)
If a developer bypasses or skips the hook, GitHub catches it on push
Weekly TruffleHog scans find anything that slipped through both layers and tell you if it's still active

Configuring GitHub Secret Scanning for Maximum Coverage

Enable Everything Available

For organizations on GHAS:


Organization Settings → Code security
├── Secret scanning: Enabled (all repos)
├── Push protection: Enabled (all repos)
├── Bypass setting: Require admin approval for bypasses
├── Custom patterns: Define internal token formats
└── Validity checks: Enable (for supported providers)

Monitor and Triage Alerts

Set up notifications so secret scanning alerts reach the right people:

Repository admins get alerts by default
Configure security manager role for centralized triage
Use the Security Overview dashboard (org level) to see alert trends
Set up webhook events for secret_scanning_alert to pipe alerts into Slack or PagerDuty

Handle Push Protection Bypasses

Review bypasses regularly. The Security tab shows all bypassed secrets and the justification provided. Treat "will fix later" bypasses as open action items—schedule remediation.

Conclusion

GitHub secret scanning is the best zero-effort credential detection available. The partner auto-revocation loop alone justifies enabling it. Push protection adds a meaningful prevention layer.

But it's not enough on its own. No history scanning, no custom patterns (without GHAS), no credential verification, no non-GitHub coverage—these gaps leave real exposure. Teams that treat GitHub scanning as their complete secrets strategy will miss the credentials that matter most: the ones that don't match known patterns, the ones buried in git history, and the ones that are still active.

Next steps:

Verify secret scanning is enabled on all your GitHub repositories
Enable push protection and configure bypass policies
Install gitleaks as a pre-commit hook for local coverage
Run a one-time TruffleHog history scan to find existing leaks
If on GHAS, define custom patterns for any internal credential formats

Rafter integrates credential scanning into comprehensive code security analysis. Start a scan at rafter.so.