# GitHub can now make unresolved secret leaks a hard pull-request merge blocker

GitHub has added a repository-ruleset control that blocks pull requests from merging until secret scanning finishes and every newly introduced secret alert is resolved. The public-preview rule turns secret detection into an enforceable merge gate rather than relying only on push-time protection or reviewer discipline.

The useful change is where enforcement happens. Teams can now make unresolved leaked credentials a branch-policy failure, with organization and enterprise rollout plus API configuration for large repository fleets.

- Status: Active
- Published: 2026-09-10T22:27:43+12:00
- Updated: 2026-09-10T22:27:43+12:00
- Categories: Web Development, Cloud & Infrastructure, Deployment & DevOps, Developer Tools
- Tags: GitHub, pull requests, repository rulesets, secret scanning, supply chain security
- Canonical HTML: https://beyondthe.news/dossiers/github-rulesets-secret-scanning-alerts-merge-blocker

## What changed

On September 9, GitHub added a new repository ruleset rule, `require_secret_scanning_alert_resolution`, for customers with GitHub Secret Protection or GitHub Advanced Security. When enabled, a pull request cannot merge until a secret scan has completed on the head commit and no open secret-scanning alerts introduced by the pull request remain unresolved. Provider-pattern secrets are included by default, with optional blocking for custom or generic patterns. The rule can be configured at repository, organization or enterprise level and through REST or GraphQL APIs. It is currently in public preview.

## Why it matters

Secret scanning has traditionally warned or blocked earlier in the workflow, but real repositories still receive pull requests through paths where a secret can reach review. Making unresolved alerts a merge-policy condition gives security teams an enforceable final gate and lets large organizations roll that control across repositories centrally. It also changes CI/review expectations: a merge can now remain blocked because scanning has not completed, not only because a secret was confirmed.

## The merge gate checks both scan completion and alert state

GitHub requires the head commit to finish secret scanning before the rule passes. It then checks whether the pull request introduced any still-open secret alerts. Developers without bypass rights must resolve those alerts before merging.

## This complements rather than replaces push protection

Push protection tries to stop a secret before it enters the repository. The new ruleset acts later at pull-request merge time, covering a different workflow boundary and giving organizations a final enforcement point.

## Central rollout is part of the value

The rule can live in repository, organization or enterprise rulesets and can be managed through REST or GraphQL. That makes it suitable for policy-as-code and fleet-wide governance rather than one-off repository configuration.

## Key details

- GitHub announced the rule on September 9, 2026.
- The rule type is `require_secret_scanning_alert_resolution`.
- A pull request is blocked until secret scanning completes on its head commit.
- Open secret alerts introduced by the pull request must be resolved before merge.
- Provider patterns are covered by default; custom and generic patterns can also be selected.
- Repository, organization and enterprise rulesets are supported.
- REST and GraphQL configuration are supported.
- The feature is in public preview for GitHub Secret Protection or GitHub Advanced Security customers.

## Builder takeaways

- Use the merge rule as a backstop even if push protection is already enabled; the two controls operate at different points.
- Expect merge queues and automation to wait for secret scanning completion, and monitor scan latency as part of delivery health.
- Apply the rule centrally where possible so critical repositories do not depend on local administrator discipline.
- Keep bypass permissions narrow and auditable, because bypass rights become the escape hatch from the secret gate.
- Test custom/generic patterns carefully before enforcing them broadly to avoid noisy false-positive merge blocks.

## What to watch

- When the rule becomes generally available.
- Whether GitHub adds finer bypass/audit controls or merge-queue integrations.
- Operational evidence on secret-scan latency and false-positive impact at large repository fleets.
- Whether the rule expands to additional secret-detection providers or policy sources.

## Uncertainties

- The control is public preview and may change before GA.
- Blocking effectiveness depends on the secret patterns enabled and the quality of secret-scanning detection.
- The rule prevents merge while an alert remains open; it does not rotate or invalidate an exposed credential automatically.

## Sources

- [Block pull requests with exposed secrets from merging](https://github.blog/changelog/2026-09-09-block-pull-requests-with-exposed-secrets-from-merging/) — GitHub · primary changelog · 2026-09-09T00:00:00+12:00. Primary source for the new ruleset, merge conditions, availability and API configuration.