[GHAS 101] Stop Secrets From Reaching Your Codebase: Secret Scanning & Push Protection

[ghostinhershell]

New to GitHub Advanced Security? This guide will take you from "we just bought GitHub Secret Protection" to "it's actively scanning our repositories and blocking exposed credentials" — with step-by-step instructions you can follow right now.

---

First: Enable Secret Protection the Fast Way

The quickest way to get GitHub Secret Protection running across your entire organization is to apply GitHub's recommended security configuration. This is a pre-built set of defaults that enables secret scanning and push protection across all your repos in a few clicks — no need to touch individual repository settings.

What applying it does to your environment:

• Secret scanning begins immediately on all enabled repositories, including a scan of your full commit history
• Push protection turns on, blocking new commits that contain detected secrets
• Open alerts begin populating in your Security Overview dashboard within minutes to hours (depending on repo count and size)
• Developers will start seeing secret scanning checks on pull requests going forward

Apply the GitHub-recommended security configuration →

Admin tip: When applying the configuration, choose to apply it to both current and future repositories so new repos are covered automatically.

Once enabled, your command center is the Security Overview — navigate to your org page and click the Security tab. This is where all secret scanning alerts across your organization will surface.

Learn about the Security Overview dashboard →

---

What Is Secret Scanning?

Secret scanning automatically searches your repositories for known credential formats — API keys, OAuth tokens, database passwords, service account credentials, and more. It scans:

• Your full commit history across all enabled repos (runs once, in the background, immediately after enabling)
• New commits and pull requests on an ongoing basis
• Issue and PR descriptions (if configured)

GitHub maintains a list of over 200 supported secret types from providers like AWS, Azure, Google Cloud, Stripe, Slack, and dozens more. When a matching pattern is found, GitHub alerts you — and for partner-supported secrets, it automatically notifies the provider, who may revoke the token on your behalf.

What changes in your environment when you turn it on

What happens	Detail
Historical scan runs	GitHub scans your entire commit history across all enabled repos. No developer action needed — this runs silently in the background.
Alerts appear in the Security tab	Discovered secrets surface as open alerts, typically within minutes for smaller repos and a few hours for larger ones.
Email notifications go out	Repository admins and the committing developer both receive email alerts for detected secrets (configurable).
Token providers are notified	For partner-supported secrets, the provider receives an automated notification and may independently revoke the credential.
PR checks begin	All new commits to pull requests are scanned automatically. Results appear as a status check on the PR.

⚠️ A high initial alert count is normal. Secret scanning surfaces secrets that already exist in your history — this is expected and valuable. It's GHAS doing its job, not a sign something is broken. See triage guidance below.

---

What Is Push Protection?

Push protection is secret scanning's preventive layer. Rather than alerting you after a secret reaches GitHub, it blocks the push before it lands - the moment a developer runs git push.

What the developer experiences:

1. Developer runs git push
2. GitHub scans the incoming commits for secrets
3. If a secret is detected, the push is blocked and the developer sees a message identifying the secret type and where it appears
4. The developer can remove the secret and re-push, or bypass the block with a documented reason

What you as an admin see:

• A full log of push protection bypasses, including the reason each developer provided
• This bypass log lives in your organization's security settings and is useful for audit and policy enforcement

Learn more about push protection →

---

Step-by-Step: Verify Your Setup

If you applied the recommended security configuration, secret scanning and push protection are already active. Confirm this:

1. Go to your organization → Settings → Code security and analysis
2. Confirm Secret scanning shows as enabled
3. Confirm Push protection shows as enabled

To enable for a specific repository without using the org-wide config:

1. Navigate to the repository → Settings → Code security and analysis
2. Click Enable next to Secret scanning
3. Click Enable next to Push protection

Full repository enablement guide →

---

Step-by-Step: Triage Your First Alerts

After enabling, you'll likely have a backlog of alerts to work through. Here's an efficient approach:

Step 1: Go to your alert list

Navigate to your org → Security tab → Secret scanning

Step 2: Understand alert states

State	Meaning
Open	Active — the secret may still be valid and in use
Resolved (revoked)	You've confirmed the credential has been rotated or revoked
Resolved (false positive)	The detected pattern isn't an actual secret
Resolved (used in tests)	The credential is a test value with no real access

Step 3: Prioritize by secret type

Start with provider-supported secrets — AWS keys, GitHub tokens, Stripe keys, GCP service account credentials. These have real access implications and may already have been used by an attacker. Custom patterns and generic high-entropy strings can wait.

Step 4: Rotate first, then clean up

Deleting a secret from your code does not invalidate it. Always rotate the credential with the provider before closing the alert. If you skip this step, the secret remains valid even after you've removed it from the repository.

Managing secret scanning alerts →

---

Tell Your Developers: A Comms Template

Before (or shortly after) enabling push protection, send a quick heads-up to your engineering team. Here's a template you can adapt:

---

Subject: New security tooling enabled — here's what you need to know

Hi team,

We've enabled GitHub Secret Protection across our organization. Starting now, two things will work differently:

Secret Scanning: GitHub automatically scans our repositories for exposed credentials — API keys, tokens, passwords, and more. If you receive an alert email, rotate the affected credential immediately with the provider. Do not just delete it from the code.

Push Protection: Pushes containing detected secrets will now be blocked. If your push is blocked, remove the secret from your commit, rotate the credential with the provider, and push again. Use environment variables or a secrets manager (like HashiCorp Vault or AWS Secrets Manager) for any credentials in your code.

If you hit a false positive or have a legitimate reason to bypass a block, you can do so — but your bypass reason will be logged for review.

Questions? Reach out to [your-security-contact].

---

Going Further: Custom Patterns

Out of the box, GitHub scans for 200+ supported secret types. If your organization uses internal credentials with custom formats — internal API tokens, proprietary service keys — you can define custom patterns using regular expressions to catch those too.

Define custom patterns for secret scanning →

---

✅ Checklist: You're Done When…

• Recommended security configuration applied (or secret scanning + push protection enabled manually)
• Security Overview dashboard checked — alerts are populating
• High-priority alerts triaged — provider-supported secrets rotated
• Engineering team notified about push protection
• (Optional) Custom patterns created for org-specific secret formats

---

Questions or Feedback?

Drop a comment below — we monitor this discussion and will do our best to help. For account or product issues, contact GitHub Support.

---

This discussion is maintained by the GitHub Customer Success team. Last updated: February 2026.