GitHub blocks a merge while a pull request's secret alert is open

GitHub said on 2026-09-09 that a new repository ruleset will block a pull request from merging if any secret scanning alert introduced by that pull request is still open. The rule is available in public preview to repositories on GitHub Secret Protection or GitHub Advanced Security.

The rule is called "require secret scanning alerts are resolved" and is under Repository settings, Rulesets, alongside the existing branch and tag rules. Before the head commit can be merged, secret scanning must have finished on it, and every alert opened by the commits in that pull request must be closed. A developer without a bypass permission cannot get past the check by asking a reviewer.

Where the gap was

Push protection has stopped a secret from reaching a branch since it was first pushed, but the writeup makes the case for a second check at the pull request stage. Push protection catches the secret at the moment of the push from the machine that authored it, and every path that skips that push, a change coming in from a fork, a rewritten branch history, a commit that pre-dated the protection being turned on, could still reach the base branch through a merge.

The new rule reads the alerts the scanner has already opened for the commits in the pull request. If any alert introduced by the pull request is unresolved, the check fails and the pull request cannot merge.

What it covers, and how to extend it

By default the rule runs on open pull requests and blocks alerts found via provider patterns, the patterns GitHub maintains for known token types from named services. Administrators can extend the rule to also block on custom patterns defined by the organisation, and on generic pattern alerts flagged by the scanner.

The setting is also reachable through the REST API as require_secret_scanning_alert_resolution, with a secret_types parameter to choose which alert categories block a merge, and through GraphQL under the same name in upper case. Rulesets apply across the selected repositories, the organisation, or the enterprise, so the policy can be set in one place rather than repository by repository.

The rule is billed under Secret Protection or Advanced Security, and it is in public preview, so behaviour and configuration options may still change before general availability.

For a team on either subscription, the practical change is that a secret an author does not notice at commit time no longer waits until a reviewer catches it. The scanner and the merge check handle it, and the pull request stays red until someone rotates the key and closes the alert. Anyone who has seen a secret reach main because a fork skipped the local hook has a use for this.

Source

• GitHub Changelog: Block pull requests with exposed secrets from merging