Secrets that leak in public GitHub repos

What actually leaks

• API keys and tokens - cloud providers, payment processors, third-party services.
• Cloud credentials - AWS access keys, GCP service-account JSON, Azure connection strings.
• .env files committed by accident, with database URLs and passwords.
• Private keys - SSH keys, TLS certificates, signing keys.
• Hardcoded passwords and database connection strings in source or config.

Why it is worse than it looks

Once a secret hits a public repo, treat it as compromised. Bots continuously scan the public event stream of GitHub and can find a fresh key within minutes. Deleting the commit is not enough - the value stays in the git history and in anything that already cloned or cached the repo.

How to prevent it

• Keep secrets in environment variables or a secret manager, never in source.
• Add a thorough .gitignore (.env, *.pem, credential files) before the first commit.
• Enable GitHub secret scanning and push protection on your repos.
• Rotate any secret the moment you suspect it was exposed - rotation is the only real fix.
• Review repository visibility regularly so an internal repo never silently goes public.

What to do after a leak

If a secret has already been exposed, move fast:

• Rotate or revoke the secret immediately - before you do anything else.
• Check the provider logs for any unauthorized use while it was live.
• Remove it from the git history if it must not persist, then force-push.
• Add monitoring so the next exposure is caught in minutes, not weeks.

Catch the exposure early

Prevention reduces the odds, but mistakes still happen. The faster you learn that a repo went public, the faster you can rotate keys and limit the damage. Continuous monitoring of your accounts turns a silent leak into an immediate alert.