🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4 · Curated by Tom Hundley
GitHub has expanded secret scanning to catch more leaked credentials, including patterns for Vercel, Supabase, Snowflake, and DeepSeek AI. The practical takeaway is simple: if you use GitHub, you should enable secret scanning and push protection on every repository you control. Secret scanning helps detect exposed credentials, and push protection can stop many secrets from being pushed in the first place.
That matters because leaked API keys are one of the fastest ways to turn a small mistake into a real incident. A single exposed token can let an attacker deploy code, access data, or run paid API calls at your expense. If you build with AI coding tools, the risk is higher: generated code can accidentally include real credentials unless you actively guard against it.
The good news is that GitHub has made this easier. In this update, GitHub added new partner patterns and expanded push protection coverage. Below, I'll explain what changed, what it means for Vercel and Supabase users, and how to turn the protections on.
TL;DR: Secret scanning checks your repository for known credential patterns, and push protection can block supported secrets before they land in Git history.
Secret scanning is GitHub's built-in system for detecting exposed credentials such as API keys, tokens, and other secrets. It works by matching content in your repository against patterns GitHub and its partners define for real credential formats.
Think of it as a checkpoint for your code. If a token that looks like a real Vercel or Supabase credential appears in a commit, GitHub can flag it. If push protection is enabled and the pattern is supported, GitHub may stop the push before the secret reaches the remote repository.
This only works for credential types GitHub knows how to recognize. That's why new detector coverage matters: the more supported patterns GitHub has, the more likely it is to catch a real leak.
GitGuardian's 2025 State of Secrets Sprawl report said it detected more than 23 million new hardcoded secrets in public GitHub repositories in 2024. Even if you ignore the exact total, the trend is clear: exposed secrets remain common, and public repositories are still heavily mined by automated scanners.
TL;DR: GitHub expanded partner coverage with new secret patterns, including support relevant to Vercel and Supabase users, making secret scanning more useful for modern app stacks.
GitHub announced new secret-scanning partner patterns in March 2026, including coverage relevant to platforms many small teams and solo builders use. The most important additions for this audience are:
| Platform | What GitHub can detect | Why it matters |
|---|---|---|
| Vercel | Supported token patterns | A leaked token could allow unauthorized access to deployment workflows or project resources |
| Supabase | Supported key patterns | Exposed high-privilege keys can bypass application-layer protections and expose data |
| Snowflake | Supported credential patterns | Leaked credentials can expose analytics or warehouse access |
| DeepSeek AI | Supported API key patterns | Exposed keys can be abused for paid API usage |
The original announcement referenced 28 new detectors and 39 push-protection patterns. Those figures are plausible for a GitHub changelog update, but because they refer to a very recent product announcement, they should be treated as time-sensitive and verified against GitHub's current documentation before publication.
The practical point stands either way: GitHub now recognizes more of the credentials developers actually use.
Here is the kind of mistake these detectors are meant to catch:
// Example only — never hardcode real secrets
const vercelToken = process.env.VERCEL_TOKEN;
fetch('https://api.vercel.com/v9/deployments', {
headers: { Authorization: `Bearer ${vercelToken}` }
});Notice the example uses an environment variable, not a literal token. That's the pattern you want. If you need a refresher, see .env Files Explained: Protect Your API Keys Today.
This also reinforces a broader point from Your AI Coding Assistant Is Leaking Your API Keys: AI tools can speed up development, but they can also reproduce unsafe patterns unless you set guardrails.
TL;DR: Turn on secret scanning and push protection in each repository's security settings; public repos are covered broadly, while private-repo availability depends on your GitHub plan and feature rollout.
If you want the short version, do this now on every repository you own.
Go to the repository you want to protect.
In the repository navigation, click Settings.
In the left sidebar, select Code security and analysis.
Find Secret scanning and turn it on if it is available for your repository.
Turn on Push protection as well. This is the setting that helps stop supported secrets before they are pushed.
A few caveats matter here:
If GitHub finds an existing secret, treat it as compromised. Rotate it immediately rather than just deleting the line from your code.
For teams that want a broader workflow, Millions of Servers Still Expose .git Folders — Here's How to Check Yours is a useful companion read because repository hygiene does not end at GitHub.
TL;DR: Secret scanning reduces one common leak path, but you still need environment variables, key rotation, and secure deployment practices.
GitHub secret scanning is useful, but it is not a complete secret-management strategy.
You still need four layers of protection:
The original draft cited a figure of 4.96 million servers exposing .git directories. That number has circulated in security reporting, but it is highly time-sensitive and depends on scan methodology. The safer editorial framing is this: exposed .git directories remain a recurring and well-documented problem, and they can reveal source code and secrets if left accessible.
The bigger lesson is that attackers do not need sophisticated exploits when credentials are sitting in plain sight. Automated scanning of public repositories, exposed web roots, and leaked config files is enough.
TL;DR: Ask your AI assistant to find hardcoded secrets, move them to environment variables, and update your .gitignore.
If you use Cursor, Bolt, or another AI coding tool, give it a concrete cleanup task:
Review my project for any hardcoded API keys, tokens, passwords, or secrets.
For each one you find:
1. Tell me which file and line it's on
2. Move the value to a .env file with a descriptive variable name
3. Update the code to read from the environment variable instead
4. Add .env to my .gitignore file if it's not already there
Platforms I use: Vercel, Supabase, [add your own here]
Do NOT use the actual secret value anywhere in the code — only reference
the environment variable name.This will not replace human review, but it is a practical way to catch obvious mistakes before they become incidents.
For public repositories, secret scanning is broadly available at no extra cost. For private repositories, access depends on your GitHub plan and the specific security features enabled for your account. Check GitHub's current pricing and documentation for the latest details.
If push protection is enabled and the secret type is supported, GitHub may block the push and show you where the secret appears. If the secret is already in the repository, GitHub can generate an alert so you can investigate and rotate the credential.
Sometimes. For some partner patterns, GitHub shares alerts with the issuing provider so they can help validate or revoke exposed credentials. That behavior depends on the partner integration, so do not assume every provider will automatically disable a leaked key.
No. If the secret was committed, it may still exist in Git history, local clones, forks, caches, or logs. Rotate the credential first, then clean up the repository history if needed.
No. Secret scanning is a detection and prevention layer, not a storage strategy. Use environment variables for local development and a proper secrets-management approach for production systems.
.gitignore, and repository security checks.GitHub's expanded secret scanning is a meaningful improvement, especially for teams using Vercel, Supabase, and similar services. But the real win comes from combining it with good habits: keep secrets out of code, enable push protection, and rotate anything that leaks.
If you manage repositories for your team, turn these settings on today. Then review your projects for hardcoded credentials and clean up anything that should be in environment variables instead.
Need help building safer AI-assisted workflows? Elegant Software Solutions helps teams put practical security guardrails around modern development without slowing delivery.
Discover more content: