GitHub push protection blocks a push that contains a detected secret. By default anyone with write access can bypass the block by giving a reason, and the reason decides what alert is created. Admins can restrict who may bypass using delegated bypass.
What push protection does
According to GitHub's documentation, push protection blocks hardcoded credentials before they reach a repository, rather than alerting after the fact. It applies to command line pushes, commits made in the web interface, file uploads, and REST API requests.
There are two kinds. Repository level protection needs GitHub Secret Protection and is off by default. User level protection is on by default on GitHub.com for public repositories and does not generate bypass alerts unless repository level protection is also enabled.
The bypass reasons
By default anyone with write access to a protected repository can bypass a block by giving a reason. The documentation says the reason determines the alert:
- "Used in tests" creates a closed alert.
- "False positive" creates a closed alert.
- "I'll fix it later" creates an open alert.
Each bypass is recorded in the audit log, and owners, security managers and watching administrators get an email.
Why the third reason is the useful one
An open alert is a to do item with an owner. It means a real secret was pushed knowingly, and it should be rotated. A closed alert from a test fixture is noise you can ignore.
Review the closed ones occasionally anyway. Test fixtures that look like real keys are a habit worth discouraging, because they teach people to click through the block.
Limiting who can bypass
Delegated bypass lets administrators limit bypass rights to specific people, who can approve other people's requests. It can also exempt trusted actors from protection entirely.
For a small team, a reasonable policy is that two named people can approve bypass, and everything else goes through them.
What to do after a real leak
Bypass or not, a pushed secret is exposed. The usual order is:
- Revoke or rotate the credential at the provider.
- Check provider logs for use.
- Then clean history if you need to.
Removing the commit does not undo exposure.
Gaps to remember
Push protection matches known patterns, so a custom internal token format may slip past. The documentation says organizations can add custom patterns for their own secret formats.
Safeguard's dependency scanning is a separate layer from secret detection. A free scan is available at gold.safeguard.sh/scan.
Setting a team policy
Write down three rules. First, test fixtures must use obviously fake values, so the block rarely fires on them. Second, the bypass reason must be honest, because it decides which alert exists. Third, anyone who picks the fix later reason owns the rotation, with a date.
Review the audit log of bypasses monthly for the first quarter. If one person bypasses far more than others, they probably hit a pattern that needs a custom rule or a better fixture, and a conversation will fix it faster than a restriction.
Quick check
Does user level push protection create bypass alerts?
Not by itself. The documentation says it does not generate bypass alerts unless repository level protection is also enabled.
Sources
Last reviewed: 19 October 2026.
