Repository security
GitHub secret scanning for vibe-coded apps
What to do when an AI-built app commits an .env file, API key, database URL, private key, or service credential to GitHub.
A committed secret is an incident, even when the repository is private and the file was deleted five minutes later. Git keeps history. Build logs, forks, caches, and local clones may keep another copy.
The response order matters more than the cleanup command. Revoke the credential first. Then remove the value from the repository and close the path that allowed it to be committed.
Assume the value was copied
Do not wait for evidence that someone used the key. Rotate an exposed database password, API token, signing secret, or private key from the provider that issued it. Check audit logs and narrow the replacement credential to the permissions the app actually needs.
- Revoke or rotate the credential at its source.
- Review provider logs from the first public commit onward.
- Replace broad account keys with service-specific credentials.
- Record which systems and customer data the old value could reach.
Deleting the file does not delete Git history
A later commit that removes .env only changes the current tree. The earlier blob remains in history until it is rewritten. Coordinate a history cleanup with collaborators because rewritten commits change hashes and require fresh clones or careful rebases.
History cleanup is not a substitute for rotation. It reduces future discovery, but it cannot recall a value that was already copied.
Fix the path that produced the leak
Add .env* and local credential files to the root .gitignore. Keep a scrubbed .env.example with variable names and safe placeholders. Store production values in Vercel, GitHub Actions, a cloud secret manager, or another server-side store.
- Turn on GitHub secret scanning and push protection where available.
- Add a local pre-commit secret check for fast feedback.
- Fail CI when a new high-confidence secret pattern appears.
- Keep privileged values out of public prefixes such as NEXT_PUBLIC_, VITE_, and REACT_APP_.
Know which keys are meant to be public
Some browser SDKs use publishable identifiers. A Supabase publishable key, for example, is designed for client code when Row Level Security is correct. The service-role or secret key is different because it bypasses those controls. A scanner should classify the key by role, not flag every long string as a breach.
Primary source
Check your repository
See which of these issues are visible now.
ScanMySaaS reads a bounded set of security-relevant files from a public GitHub repository. It never runs repository code or reveals matched secret values.
Scan a public repository