I got a GitHub secret scanning alert for a leaked API key: what do I do first?

By Ohad Krispin, founder of VibeRaven · LinkedIn

Rotate the key with its provider first, then update the value in Vercel and redeploy. A GitHub secret scanning alert means a string in your repository matched a supported secret pattern, so treat that key as compromised. GitHub's secret scanning page says to rotate the credential immediately and calls removing it from Git history time-intensive and often unnecessary once it is revoked. For a partner provider's secret found in a public source, GitHub sends the match to the provider, and its partner docs leave revoking the key and notifying you to the provider. GitHub's pattern table lists no Supabase service_role or anon JWT, so a quiet inbox does not mean a clean repo.

Paste this to your agent

Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Repository check

Check this in your repo

Find keys written into the repo, including ones GitHub does not list

For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer. It reports service_role_key_in_client_code as a blocker when a source file contains a hardcoded Supabase service_role JWT or an sb_secret_ literal, and secrets_in_repo for env-style file names that .gitignore does not cover. It reads the files in the folder, not git history or your GitHub alerts, so it cannot tell whether a key was pushed, flagged or already rotated.

It is a repository check, not a live database test: it does not call GitHub, Supabase or any other provider. It is advice, not a gate, and it exits with code 1 when it finds a blocker.

npx -y viberaven@1.7.1 check

What it printed on a fixture repo

On 2026-10-31 we ran it on a small Next.js and supabase-js fixture repo made for this page, not a customer repo. lib/supabase-admin.ts held a made-up service_role JWT written into createClient, and an .env with a placeholder value was committed with no rule in .gitignore for it. The output is below, with the folder shortened to ~/notes-app. The repo had no Supabase migrations, so it also printed rls_disabled, which is about policies and not about the key. The exit code was 1.

$ npx -y viberaven@1.7.1 check

viberaven check · ~/notes-app

🔴 No RLS policy proof in migrations  (rls_disabled)
   Missing SQL evidence for both "enable row level security" and "create policy".
🔴 Service role key used in client code  (service_role_key_in_client_code)
   lib/supabase-admin.ts:5: contains a hardcoded service_role JWT. This file is not marked server-only, so it can end up in a client bundle, and the service role key skips RLS entirely. Move the call behind a server route or edge function and rotate the key.
🟡 Configuration filenames need review  (secrets_in_repo)
   This filename-only check found files not covered by .gitignore (.env). Contents and Git tracking were not checked by this finding. Base configuration may be intentionally tracked; credential content remains unverified.
⚪ No error monitoring detected  (missing_monitoring)
   No Sentry/PostHog (or similar) instrumentation was found. Production errors will only surface when users complain.

Verdict: ❌ 2 blockers, 1 warning · score 50
Fix: viberaven fix · Details: ~/notes-app/.viberaven/agent-tasklist.md

Which keys does GitHub secret scanning recognize?

Only the patterns in its supported patterns table. The rows below are from that table as fetched on 2026-10-31. A key outside the table raises no alert, and a partner-only row raises no alert in your repository: GitHub says partner secrets are reported directly to the provider and are not displayed in your repository alerts.

secret type                      partner  user alert  push protection
supabase_secret_key              yes      yes         yes
stripe_api_key                   yes      yes         yes
stripe_webhook_signing_secret    yes      yes         no
openai_api_key                   yes      yes         yes
resend_api_key                   yes      yes         yes
vercel_personal_access_token     yes      yes         yes
neon_connection_uri              yes      no          no

Supabase service_role or anon JWT (eyJ...): not listed
Clerk: not listed

Does GitHub revoke the key for me?

No. GitHub's partner program page says that when a match of a provider's secret format is found in a public source, a payload with the matched value is sent to an HTTP endpoint the provider chose. It tells providers to consider such secrets public and compromised, and says a provider can revoke the exposed secrets and notify the affected users, but how is up to the provider. The page describes this only for public sources. Check the key in the provider's dashboard rather than assuming it was revoked.

Do I also have to clean the key out of git history?

Not before rotating, and often not at all. GitHub says rewriting history is time-intensive and often unnecessary if you have already revoked the credential. The order is the same one the env file page gives: revoke first, then decide whether a history rewrite is worth it. For the Supabase server key, the steps are on the service role key rotation page.

Checklist

What to do, in order

01
Find keys written into the repo, including ones GitHub does not list. For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer. It reports service_role_key_in_client_code as a blocker when a source file contains a hardcoded Supabase service_role JWT or an sb_secret_ literal, and secrets_in_repo for env-style file names that .gitignore does not cover. It reads the files in the folder, not git history or your GitHub alerts, so it cannot tell whether a key was pushed, flagged or already rotated. It is a repository check, not a live database test: it does not call GitHub, Supabase or any other provider.
```
npx -y viberaven@1.7.1 check
```
02Open the alert in the repository's Security and quality tab and note the secret type, the file and the commit.
03Create a new key with the provider and revoke or delete the old one. For a Supabase service role key, follow the rotation page linked below.
04Set the new value in Vercel for every environment that used the old one, then redeploy.

Check whether other env files are tracked, and untrack them:

git ls-files -- '.env*' '*/.env*'
git rm --cached .env
printf '.env*\n!.env.example\n' >> .gitignore

06Look at the provider's usage or logs between the push and the rotation for requests you did not make.
07Search the code for keys GitHub does not list, such as a legacy service_role JWT written into a source file.

Sources

Official docs behind this checklist

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

Is a private repository scanned too?

GitHub says secret scanning runs automatically on public repositories. For private repositories it needs GitHub Secret Protection on organization-owned repositories (GitHub Team or GitHub Enterprise Cloud); user-owned private repositories need GitHub Enterprise Cloud with Enterprise Managed Users, or GitHub Enterprise Server with Secret Protection enabled. The partner page describes sending matches to providers only for public sources.

Is deleting the file or the commit enough?

No. The key still works until it is revoked, and GitHub warns that commits with the data may still be reachable in clones, forks, cached views on GitHub and pull requests. Revoke first.