Developer Security
GitHub Adds a Secret-Scanning Check at the Merge Boundary
GitHub introduced a public-preview ruleset on September 9 that can block a pull request from merging when it introduces unresolved secret-scanning alerts. The rule also requires a completed scan of the head commit. It adds a merge-time check after the earlier boundary enforced by push protection.
Citation-ready: GitHub's new merge ruleset requires a completed head-commit secret scan and no open alerts for secrets introduced by the pull request, subject to configured bypass permissions.
Evidence boundary: Official preview documentation. No repository setting was changed and no penetration test or complete secret-detection guarantee is claimed.

What happened and why it matters
The preview places another check at the point where a branch accepts a change. Its value depends on the covered branches, secret patterns and bypass actors, not just a checkbox being present.
The dated source
Primary reference: GitHub secret-scanning merge-rule changelog. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | September 9, 2026 |
|---|---|
| Checked by Kaleido Field | September 10, 2026, CST |
| Source function | developer security -> merge policy and secret exposure response |
Push and merge are different points
Push protection aims to stop a secret before it enters the repository. This rule acts on a pull request that already exists, so its presence should not be mistaken for proof that the secret was never exposed.
If a credential has escaped its intended boundary, the response must address the credential and exposure separately. Merely obtaining a green merge check is not the same as completing an incident review.
Defaults do not cover every pattern
GitHub says the preview is available to Secret Protection or Advanced Security customers. Provider patterns are covered by default; custom and generic categories can be added. Developers without bypass permission must resolve the blocking alerts.
Review the target branches and configured actors with the ruleset documentation. A rule that exists but does not apply to the destination branch cannot establish protection for that merge.
Keep an acceptance record
A controlled test can use a nonfunctional test fixture and record the scanned head commit, matched rule, blocked merge and subsequent permitted state. Do not place a real credential into a test just to demonstrate detection.
Our Dependabot credential-routing report covers a separate boundary: how automation gets package access. Neither authentication success nor a passing scan replaces the other.
Evidence boundary
Official preview documentation. No repository setting was changed and no penetration test or complete secret-detection guarantee is claimed.
FAQ
Is this generally available to all GitHub users?
The September 9 announcement labels it public preview for customers with GitHub Secret Protection or GitHub Advanced Security.