TL;DR
Your GitHub repository is a security boundary. Enable secret scanning and Dependabot, review .gitignore for sensitive files, use branch protection rules, and audit collaborator access. 5 critical items must be fixed before launch, 6 important items within the first week, and 4 recommended items when you can.
Quick Checklist (5 Critical Items)
Secret Protection 4
Dependency Security 4
Access Control 4
GitHub Actions Security 3
Before Making a Repo Public
Before changing a private repository to public, run through this entire checklist twice. Once a secret is in public git history, consider it compromised. Even if you delete it, bots scrape public repos constantly and secrets can be captured within seconds of exposure.
Use tools like git-secrets or truffleHog to scan your entire git history for secrets before making a repo public.
I accidentally committed a secret. What do I do?
First, rotate the secret immediately. The credential is compromised regardless of what you do with git history. Then, use git filter-branch or BFG Repo-Cleaner to remove it from history. Finally, force push and have all collaborators re-clone.
Is a private repo enough to protect secrets?
No. Private repos can become public accidentally. Team members change. Backups might be less secure. Always use environment variables and secrets managers, even for private repos. Treat .gitignore and secret scanning as required, not optional.
How do I share secrets with my team?
Use GitHub Secrets for CI/CD, a secrets manager (1Password, Doppler) for team access, and environment variables for local development. Never commit secrets to the repository, even in private repos.
Scan Your Repository
Check for exposed secrets and security misconfigurations in your codebase.
Start Free Scan