GitHub's New Security Feature Catches Secrets Before You Commit Them

GitHub expanded their secret scanning push protection to all public repositories this week. Previously, you had to explicitly enable it. Now it is automatic. When you try to push code containing a detected secret, GitHub blocks the push and tells you what it found.

How It Works

GitHub maintains a database of secret patterns. API keys from AWS, Azure, and GCP. GitHub tokens. Slack webhooks. Stripe keys. Twilio credentials. Over 100 different patterns covering the most commonly leaked secret types.

When you attempt to push code, GitHub scans the changes for these patterns. If it finds a match, the push is blocked. You get a message telling you what was found and where. You can then remove the secret, rotate it if necessary, and retry the push.

The detection happens before the secret reaches GitHub's servers. Your push is rejected. The secret is not stored in your repository history. This is the key difference from post-commit scanning. Once a secret is in git history, it is there forever. Even if you delete it, it remains in the history. Push protection prevents it from ever getting there.

The Limitations

The protection only applies to public repositories on GitHub.com. Private repositories need to manually enable push protection in their security settings. Enterprise Cloud and Enterprise Server have their own configuration options.

Pattern matching is not perfect. GitHub errs on the side of caution, which means false positives happen. A string that looks like an API key but is not will trigger a block. You can bypass the protection if you are certain it is a false positive, but this requires explicit action.

GitHub cannot detect all secrets. Custom internal secrets, passwords for services not in their database, and novel secret formats will slip through. Push protection catches the common cases, not everything.

Most importantly, push protection does not fix existing secrets. It only prevents new ones from being added. If you already have secrets in your repository history, they are still there, still accessible to anyone with read access.

What You Should Do

Enable push protection on private repositories. It is not automatic for private repos. Go to Settings → Security → Secret scanning and enable push protection. Do this for every repository you care about.

Scan your existing history. GitHub can scan existing commits for secrets. Do this for all your repositories. If you find secrets, rotate them immediately. Assume they are compromised.

Do not bypass protection lightly. If GitHub flags something, investigate. Do not just click "push anyway" because you are in a hurry. That is how secrets leak.

Use secret management tools. The best way to avoid leaking secrets is to not hardcode them. Use environment variables, secret management services like AWS Secrets Manager or HashiCorp Vault, or GitHub's own encrypted secrets.

The Bottom Line

Push protection is a valuable safety net. It will not catch everything, but it catches the most common and dangerous mistakes. For teams without dedicated security resources, this is a significant improvement.

Think of it like a seatbelt. It does not prevent accidents, but it makes them less catastrophic. Enable it everywhere you can.