Exposing secrets in a public GitHub repository is a real production emergency. Public repositories are continuously scanned by automated bots, and leaked credentials can be discovered within minutes.
If this happens, act immediately.
1. Assess the Impact Immediately
Start by identifying exactly what was exposed.
Questions to ask:
- Were API keys leaked?
- Did database credentials appear in the repository?
- Were cloud credentials exposed (AWS, GCP, Azure)?
- Did payment gateway secrets become public?
- Were JWT signing keys included?
- Were admin or service tokens exposed?
The faster you understand the scope, the faster you can contain the issue.
2. Revoke and Rotate All Exposed Secrets
Deleting the file is not enough.
Assume any exposed credential has already been copied and rotate it immediately.
Generate new credentials for:
- API keys
- Database passwords
- Access tokens
- Cloud credentials
- Authentication secrets
- Webhook secrets
After rotation, update all environments and redeploy applications so production stops using old credentials.
3. Remove Secrets from Git History
Removing the .env file in a new commit does not erase it from earlier commits.
Clean repository history using tools such as:
git filter-repoBFG Repo Cleaner
Once cleaned:
- Force-push the updated history
- Ask collaborators to re-clone or reset local repositories if necessary
Remember: history cleanup improves hygiene, but secret rotation is the actual remediation.
4. Investigate for Suspicious Activity
Review logs to determine whether exposed credentials were abused.
Check:
- Cloud audit logs
- Database access history
- API request logs
- Authentication events
- Billing and usage anomalies
Look for unusual activity after the exposure timestamp.
5. Notify the Team and Stakeholders
Security incidents should be communicated clearly.
Inform relevant stakeholders such as:
- Engineering teams
- Security teams
- Project owners
- Management (if required)
Document:
- What happened
- What was exposed
- Actions taken
- Current status
Transparency helps teams respond faster and improve future processes.
6. Prevent It from Happening Again
Once the incident is resolved, strengthen your workflow.
Recommended safeguards:
- Enable GitHub Secret Scanning
- Add
.envfiles to.gitignore - Use pre-commit secret detection
- Add CI/CD security checks
- Store secrets in dedicated secret managers
- Follow least-privilege access principles
The goal isn't only fixing the leak — it's making sure the next one never happens.
Quick Checklist
| Step | Action | Status |
|---|---|---|
| 1 | Assess the impact | ☐ |
| 2 | Revoke and rotate secrets | ☐ |
| 3 | Remove secrets from Git history | ☐ |
| 4 | Investigate for suspicious activity | ☐ |
| 5 | Notify team and stakeholders | ☐ |
| 6 | Prevent it from happening again | ☐ |
Final Thought
Secret exposure incidents happen even to experienced teams. What matters most is how quickly you detect, rotate, contain, and improve your process afterward.
Written by Kashaf Abdullah
Software Engineer | MERN Stack | Web Development
Found this helpful? Leave a ❤️ and bookmark it for later!
Let's discuss in the comments: Have you ever accidentally leaked secrets? What steps did you take?