Here's a scenario that plays out every single day: you fire up Cursor, scaffold a new app, connect Stripe, get payments working, push to GitHub, and deploy. You're live. You're shipping. You're a vibe coder.
Except somewhere in that flow, your sk_live_ key ended up in a config file that got committed. Your AWS credentials are in a .env that wasn't gitignored early enough. Your database password is hardcoded in a seed script from hour two.
This is the #1 mistake. Not because it's hard to fix, but because you don't know it happened until someone else finds it.
Why It Matters More Than You Think
Git never forgets. Even if you delete the file and push again, the secret is still in your commit history. Bots scrape GitHub for exposed credentials within minutes of a public push. AWS keys get exploited for crypto mining. Stripe keys get used for fraudulent charges. Database credentials lead to full data breaches.
And if your repo is private? You're still one accidental fork, one CI log, or one disgruntled contractor away from exposure.
What ShipCheck Catches
ShipCheck's Repo Secrets Scanner (available on Builder and Pro plans) clones your repository, scans every file for committed secrets, and reports exactly what it finds — with masked previews so the secret itself never leaves your control.
Here's what it detects:
- API keys: Stripe, AWS, Google Cloud, SendGrid, Twilio, and dozens more
- Tokens: GitHub personal access tokens, OAuth tokens, JWT signing secrets
- Passwords: Hardcoded database passwords, admin credentials, service accounts
- Private keys: RSA, SSH, PGP keys committed to source
- Config files:
.envfiles,credentials.json, and other config artifacts that should be gitignored
Every finding includes the file path, line number, secret type, severity, and a masked preview like sk_live_...R8F9. Your actual key is never stored or displayed in full.
The 4-Step Fix Loop
When ShipCheck finds a committed secret, here's the playbook:
Step 1: Rotate immediately
Go to the provider dashboard (Stripe, AWS, GitHub, etc.) and generate a new key. The old one is compromised the moment it hit version control.
Step 2: Move to environment variables
Store the new key in your .env file (which must be in .gitignore). Reference it in code via process.env.YOUR_KEY.
Step 3: Clean your history
Use git filter-repo or BFG Repo-Cleaner to purge the secret from all commits. A regular git rm only removes it from the latest commit — the history still has it.
Step 4: Rescan to verify
Trigger a new ShipCheck repo scan. The finding should no longer appear. If it does, you missed a commit or a duplicate. Repeat until clean.
Prevention Is Better Than Cleanup
The best fix is not needing to fix. Add .env to your .gitignore in your very first commit. Use a .env.example with placeholder values instead of real keys. Set up ShipCheck to scan your repo on every push so nothing slips through.
If you're building with AI assistants, be extra careful: they don't know that the key you pasted into the chat is live. They'll happily put it right in your source code.
Stop shipping your secrets
Upgrade to Builder or Pro and let ShipCheck scan your repo for committed keys, tokens, and credentials. Always masked. Always actionable.
Upgrade to Scan Your Repo