GitHub has introduced a repository-ruleset control that can stop a pull request from merging until selected secret-scanning alerts are resolved. The feature, now in public preview, gives security teams a merge-stage guard for credentials that reach the pull-request workflow.

The new rule is named Require secret scanning alerts are resolved. GitHub says it blocks a pull request when the scan has not completed for the head commit, or when a commit in the pull request introduced an open alert matching a secret type selected in the ruleset.

A second enforcement point for secret exposure

GitHub distinguishes this control from push protection. Push protection is designed to stop a detected secret before it reaches the repository. The ruleset adds a branch-protection check at merge time, which can cover cases where push protection is unavailable, not enabled for a pattern category, or where teams deliberately want a final control before protected branches are updated.

That distinction is operationally useful. A pull request can aggregate multiple commits, contributors and automation steps. A policy that requires scanning to complete and requires selected alerts to be resolved before merge creates a clear release gate for the repository branch that matters most: the branch used to ship or promote code.

What the rule can block

GitHub documents two blocking conditions: a missing completed secret-scanning scan for the pull request’s head commit, and an open alert introduced by the pull request that matches one of the secret types configured in the ruleset. Administrators can select provider patterns, custom patterns and generic patterns. GitHub notes that AI-detected secrets are not supported by this specific rule.

The feature is available in public preview for customers with GitHub Secret Protection or GitHub Advanced Security. As a preview feature, it may change; organizations should validate both licensing and behavior in a controlled repository before making it a universal production requirement.

Recommendations for security and platform teams

  1. Start with a protected production branch. Apply the rule first to the branch that represents a deployable baseline, rather than enabling it indiscriminately across every experimental branch.
  2. Use evaluation before enforcement where available. Review which pull requests would be blocked, whether scans complete reliably, and whether existing workflows introduce expected false positives.
  3. Select pattern categories deliberately. Provider patterns are often a sensible starting point. Add custom or generic patterns only after teams understand the alert volume and have a predictable review process.
  4. Define a narrow bypass policy. A bypass should be exceptional, attributable and reviewed. It should never replace revocation or investigation when a credential is genuinely exposed.
  5. Connect the gate to incident response. Resolving an alert in GitHub is not necessarily remediation. If a valid credential was committed, revoke or rotate it at the issuing service, assess access logs where appropriate, and document the outcome.

Why a merge gate matters

Secret detection only reduces risk when it changes the delivery decision. Without a required check, an alert can remain open while code continues toward a protected branch. This rule makes the state of selected alerts part of merge eligibility, allowing platform teams to make a security condition explicit in the same control plane they use for reviews, status checks and deployment policies.

It is not a substitute for least-privilege credentials, short-lived tokens, pre-commit controls or continuous secret scanning of repository history. It is a complementary control: push protection can catch many mistakes earliest, while a ruleset can prevent unresolved findings from being normalized at merge time. Teams should measure blocked pull requests and response times after rollout, then tune pattern selection and developer guidance based on real results.