GitHub adds a ruleset that blocks pull requests from merging while a secret they introduce is still open

Why it mattersTeams that already run push protection get a second gate at the pull request layer, so an alert opened during a review must be resolved before the merge button will turn green.
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 lives 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 gate at the pull request layer. 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 widen it
By default the rule runs on open pull requests and blocks alerts found via provider patterns, the fingerprints GitHub maintains for known token types from named services. Administrators can widen 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 carry 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 surface may still change before general availability.
For a team on either subscription, the small operational shift 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 gate handle it, and the pull request stays red until someone rotates the key and closes the alert. Anyone who has watched a secret land in main because a fork skipped the local hook has a use for this.
Source
- GitHub Changelog: Block pull requests with exposed secrets from merging
Source: GitHub Changelog
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually shipping with them. Short, and only when there is something worth reading.
