GitHub Adds PR Merge Blocking Rules to Halt Leaked Secrets Before Mainline Integration

GitHub has rolled out a public preview capability within repository rulesets that blocks pull requests from merging when unresolved secret scanning alerts are present. The enforcement policy verifies two distinct criteria before merge permissions are granted: a secret scan must have completed successfully against the head commit, and no open alerts may exist for secrets introduced across the pull request's commits. Available to organizations using GitHub Secret Protection or GitHub Advanced Security (GHAS), the rule defaults to blocking provider-verified credentials but can be configured to cover generic and custom patterns via the management UI, REST API (`require_secret_scanning_alert_resolution`), and GraphQL. Secret leakage remains a primary entry point for software supply chain and cloud infrastructure breaches. While push protection acts at push time before commits reach the remote host, enterprises frequently struggle with configuration trade-offs. Push protection on broad or heuristic pattern sets can cause developer friction, leading organizations to restrict it to high-fidelity provider patterns. By introducing branch-level PR gating, security leaders establish an essential defense-in-depth layer. Developers without administrative bypass permissions must formally triage, revoke, or resolve exposed credentials before code enters core branches. This enhancement mirrors a wider industry trend in DevSecOps toward declarative, asynchronous policy gates embedded directly into platform engineering workflows. Rather than treating secret detection as an isolated developer-side check or an out-of-band post-merge triage exercise, platforms are standardizing on branch rulesets as the unified control plane for software governance. Much like required status checks for unit testing and static application security testing (SAST), integrating secrets resolution into pull request gates normalizes security hygiene as a prerequisite for peer review and automated delivery pipelines. For DevSecOps practitioners and platform teams, this update allows for a practical, tiered remediation architecture. Organizations can maintain low-friction push protection for high-confidence provider tokens while configuring this pull-request rule to catch and enforce remediation on broader custom and generic secret formats. Security architects should update centralized ruleset templates across their organization to activate `require_secret_scanning_alert_resolution` on protected branches, ensuring consistent baseline controls without creating roadblocks during local developer prototyping.