Push protection stops a credential at the moment of the push, so it never lands in the repository. Scanning after the fact finds credentials already committed, including old ones in history. Prevention reduces new leaks. Detection cleans up the past and catches what prevention misses. You want both.
What push protection does
GitHub describes push protection as blocking pushes that contain secrets before they reach the repository. It applies to command line pushes, commits in the web interface, file uploads and API requests. When it triggers, the push is stopped and the reason is shown, so the author can remove the secret and try again.
Some details matter for planning. Repository level protection is off by default and needs a paid GitHub feature, while user level protection covers pushes to public repositories. By default, people with write access can bypass a block by giving a reason, and each bypass creates an alert and an audit log entry. Custom patterns can be added.
What scanning after the fact does
GitHub's secret scanning covers the full history of all branches, plus issues, pull requests, discussions and wikis. It finds credentials that were pushed before protection was on, in places a push check does not see, or that matched a pattern added later.
Why one is not enough
- Prevention only covers the paths it watches. A secret pasted into a ticket or a wiki never passes through a push.
- Bypass is possible by design. Someone with a deadline may click through.
- Pattern lists grow, so yesterday's clean history can contain today's recognised key.
Detection alone is weak too, because by the time it fires the secret is already in clones, caches and possibly forks.
A workable setup
- Turn on prevention where your platform supports it.
- Review bypass reasons weekly at first.
- Run a full history scan once, then keep scanning continuously.
- Add custom patterns for internal token formats.
- Write a rotation runbook so a hit leads to action within hours.
When a secret does leak
Rotate first. GitHub's own guidance says rewriting history is time consuming and often unnecessary once the credential is revoked. Then check logs for use by anyone else.
Quick check
Can people bypass push protection?
On GitHub, by default users with write access can, with a reason. Bypasses are logged and notify administrators.
Why scan history if push protection is on?
Older commits predate the protection, and pattern lists change, so history can still hold recognisable secrets.
Sources
Last reviewed: 19 October 2026.
