GitHub Rulesets Block Pull Requests with Exposed Secrets From Merging

What shipped

GitHub added a repository ruleset rule — require_secret_scanning_alert_resolution (REST) / REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION (GraphQL) — that blocks a pull request from merging while it has open secret scanning alerts. Public preview, Sep 9 at 17:14 UTC.

What changed

The rule runs two checks before a merge: a secret scan must have completed for the head commit, and no alerts can be open for secrets the PR's commits introduced. Default scope is provider patterns only — generic and custom patterns are opt-in, so you can keep push protection off for noisy generic patterns while still gating merges on them. Resolution, not a click-through, clears the block for developers without bypass permission.

That's the real delta over push protection: per GitHub's own docs, anyone with write access can bypass push protection by default. The bypass button is a per-push suggestion; this is an org-enforced merge gate that turns "oops, clicked bypass" into a merge-blocked alert someone must triage.

Why a builder cares

Follow the timestamps. The rule requires GitHub Secret Protection or Advanced Security — paid SKUs. Nineteen minutes after it shipped, GitHub expanded self-serve GHAS trial eligibility from 100 to 300 enterprise licenses. A security gate, then a 3× wider funnel to the trial. If your build pipeline or app emulates secret-gating merges on GitHub, your moat just became a native checkbox. Free-tier repos get push protection for users on public repos; the merge gate is paywalled — budget for the SKU or build the check in CI with gitleaks yourself.