How to Set Up Secret Scanning in GitHub
Leaked secrets are one of the most common and most preventable security incidents. An AWS key committed to a public repository can be exploited within minutes by automated scanners that continuously monitor GitHub for credentials. Even in private repositories, committed secrets persist in git history forever and are accessible to anyone with repository access, including future employees and compromised accounts.
GitHub's built-in secret scanning detects known secret patterns in your repository and alerts you before they cause damage. Combined with push protection, which blocks commits containing secrets before they reach the repository, you can prevent the most common credential leak vector. This guide covers enabling secret scanning, configuring push protection, setting up custom patterns for internal secrets, and building an incident response process for detected secrets.
Step-by-step guide
Enable secret scanning at the organization level
Navigate to your GitHub organization settings, then Code security and analysis. Enable 'Secret scanning' for all repositories. This activates scanning for over 200 known secret patterns from partners like AWS, Google Cloud, Stripe, Datadog, and more. When a known pattern is detected, GitHub alerts the repository admins and, for partner patterns, also notifies the secret provider (who may automatically revoke the credential). Enable scanning for all repositories, not just public ones.
- Go to Organization Settings > Code security and analysis
- Enable 'Secret scanning' and select 'Enable for all repositories'
- Enable 'Secret scanning for push protection' to block secrets at push time
- Choose whether to automatically enable for new repositories (recommended: yes)
Enable push protection to prevent new leaks
Push protection is the proactive layer: it scans every push before it reaches the repository and blocks commits that contain detected secrets. Enable push protection in the same organization settings page. When a developer tries to push a commit containing a secret, they will see an error message identifying the secret and requiring them to remove it before pushing. Developers can bypass push protection with a justification, but these bypasses are logged and visible to security admins.
- Enable 'Push protection' in the secret scanning settings
- Configure whether developers can bypass push protection (recommended: allow with justification for flexibility)
- Review bypass justification options: false positive, used in tests, will fix later
- Set up notifications for security admins when bypasses occur
Add custom secret patterns for internal credentials
GitHub's built-in patterns cover public providers, but your organization likely has internal secret formats that are not detected by default. Create custom patterns for: internal API keys (if they follow a predictable format like 'vntg_sk_[a-zA-Z0-9]{32}'), database connection strings, internal service tokens, and JWT signing keys. In organization settings under Secret scanning > Custom patterns, add regex patterns with a name, description, and test strings to validate the pattern.
- Audit your internal credential formats and document their patterns
- Create custom regex patterns for each internal secret type
- Test each pattern with real (rotated) examples to verify detection accuracy
- Start with high-confidence patterns and add more as you refine them
Review and triage existing secret alerts
After enabling scanning, GitHub will scan your entire repository history and generate alerts for any secrets found. This initial scan often surfaces historical credentials that were committed months or years ago. Navigate to the Security tab in each repository to review alerts. For each alert: verify it is a real secret (not a false positive), check if the credential is still active, and prioritize rotation. Secrets that are currently active and have broad permissions are the highest priority.
- Review all existing alerts in the organization's security overview
- Categorize each alert: active secret (rotate immediately), inactive/revoked (close as resolved), false positive (dismiss)
- Prioritize active secrets by scope: broad permissions first, then narrow permissions
- Track rotation progress in a spreadsheet or issue tracker
Establish a secret rotation process
For every detected secret, the response is the same: rotate it. Revoking is not enough if the secret was committed to a public or widely-accessible repository — it may have been captured by automated scanners. Rotation means: generate a new credential, update it in your secrets management system (environment variables, Vault, AWS Secrets Manager), verify the application works with the new credential, then revoke the old one. Document this process as a runbook so anyone can follow it.
- Write a rotation runbook for each secret type: API keys, database passwords, OAuth secrets, JWT signing keys
- Generate the new credential from the provider's console
- Update the credential in your secrets management system (not in code)
- Verify the application functions with the new credential before revoking the old one
Set up monitoring and reporting
Create a regular cadence for reviewing secret scanning health. GitHub's organization-level security overview shows: total open alerts by severity, alerts closed vs. opened over time, and push protection bypass frequency. Review this dashboard weekly as part of your security team standup. Set up webhook notifications to send new secret scanning alerts to a dedicated Slack channel so the team is aware immediately, not just when they check the dashboard.
- Configure GitHub webhooks to send secret scanning alerts to Slack
- Review the organization security overview weekly
- Track metrics: mean time to rotation, bypass frequency, false positive rate
- Report monthly on secret scanning health to engineering leadership
Common mistakes
Enabling scanning without a rotation process
Detecting secrets is useless if the team does not know how to respond. Before enabling scanning at scale, ensure you have a documented rotation process for each secret type. Otherwise, alerts pile up, nobody acts on them, and the scanning becomes another ignored security tool.
Only scanning public repositories
Private repositories are not safe from secret leaks. Employees leave, accounts get compromised, and repositories get accidentally made public. Enable secret scanning on all repositories, including private and internal ones. The cost of a leaked credential far exceeds the cost of scanning.
Deleting the commit instead of rotating the secret
Some teams try to fix a leaked secret by force-pushing to remove the commit from history. This does not work: the secret was already pushed to the remote, may be cached in forks and pull requests, and may have been captured by automated scanners. Always rotate the secret regardless of whether you clean up git history.
Tips
Add a pre-commit hook using a tool like detect-secrets or gitleaks to catch secrets locally before they ever reach GitHub — this is a defense-in-depth approach that complements GitHub's server-side scanning.
Create a .gitignore entry for common files that contain secrets: .env, .env.local, credentials.json, and service-account-key.json.
Run a quarterly 'secret audit' where you review all active credentials, verify they follow least-privilege principles, and rotate any that are older than 90 days.
Use GitHub's security overview API to build a custom dashboard that tracks your secret scanning metrics alongside other security KPIs.
How Vantage helps
Vantage connects to GitHub with security-conscious defaults. When querying your codebase through Vantage, the system respects repository access controls and never indexes or surfaces credential files, ensuring that security best practices extend to every tool in your product development workflow.