GitHub Adds PR Secret-Merge Blocking: A Proxy Credential Response Plan

GitHub announced on September 9, 2026 that repository rulesets can block a pull request from merging when the pull request introduces unresolved secret-scanning alerts. The new rule adds a review-stage control for organizations that store proxy clients, browser tests and data-collection automation in GitHub.

This is a GitHub public-preview capability, not a feature of 98IP. GitHub says it is available to customers with GitHub Secret Protection or GitHub Advanced Security. The rule reduces one path to accidental exposure, but it does not make a leaked proxy credential safe, erase it from history or replace immediate rotation.

Public source note: GitHub, “Block pull requests with exposed secrets from merging,” September 9, 2026.

What the rule checks

GitHub describes two merge conditions:

1. a secret scan has completed for the pull request’s head commit;
2. no secret alerts introduced by the pull request’s commits remain open.

By default, the rule applies to open pull requests and blocks secrets detected through provider patterns. Administrators can also select other categories, including custom or generic patterns.

The setting is called “Require secret scanning alerts are resolved.” It can be applied through repository, organization or enterprise rulesets. GitHub also documents REST and GraphQL representations for managed rollout.

How it differs from push protection

Push protection attempts to stop a secret before it reaches the repository. The new ruleset works at the pull-request merge boundary and can catch cases that push protection did not catch or was not configured to block.

Use them as layers:

• local prevention: keep secrets outside tracked files and scan before commit;
• push protection: block recognized secrets before repository ingestion;
• PR merge rule: prevent unresolved introduced alerts from reaching protected branches;
• post-exposure response: revoke, rotate, investigate and verify cleanup.

The PR rule should not be used as permission to disable earlier controls. A secret present in an unmerged branch, fork, log or artifact may already be exposed.

Identify every form of proxy credential

Proxy authentication material can appear as:

• username and password pairs;
• API tokens or account keys;
• session identifiers embedded in usernames;
• full proxy URLs containing credentials;
• environment files and shell history snippets;
• CI variables copied into test fixtures;
• screenshots, debug logs or uploaded artifacts;
• allowlist-management tokens and webhook secrets.

Do not build a public custom pattern from real credentials. Derive patterns from documented structure using synthetic examples. Avoid broad expressions that flag ordinary URLs or IP addresses without evidence; excessive false positives encourage unsafe bypasses.

The proxy credential rotation guide provides the operational sequence for replacing affected authentication material.

Configure the merge rule safely

1. Inventory repositories that contain proxy clients, scraping workers, CI templates and infrastructure definitions.
2. Confirm the applicable GitHub security entitlement and secret-scanning coverage.
3. Define protected branches and ruleset scope.
4. Enable “Require secret scanning alerts are resolved.”
5. Start with provider patterns, then add reviewed custom patterns for proxy-specific credential formats.
6. Restrict bypass permissions to a named emergency role.
7. Log and review every bypass with a ticket and expiration.
8. Test with synthetic credentials that have no production value.

Roll out to a small repository group first. Measure scan completion time, alert volume, false-positive rate, developer resolution time and bypass frequency. Do not weaken the rule simply because an unrelated generic pattern is noisy; tune scope and pattern design.

Treat every real alert as an exposure event

When an alert contains a genuine proxy credential, assume the value may have been copied even if the pull request never merged.

1. Stop propagation

Close or block the affected workflow, remove public artifacts and prevent the branch from being reused. Do not paste the value into chat, issue comments or incident tickets.

2. Revoke or rotate

Invalidate the credential at the provider or internal secret manager. Create a replacement with the narrowest product, region, destination, concurrency and expiration scope the workload needs.

3. Find the exposure surface

Check commit history, forks, workflow logs, caches, release artifacts, container layers, package registries and copied configuration bundles. The GitHub Actions cache access audit helps prevent low-trust jobs from saving reusable state.

4. Remove and verify

Remove the secret from the current tree and, when required by policy, rewrite affected history through an approved process. A clean latest file does not prove old objects, forks or artifacts are clean.

5. Restore through a managed secret path

Inject the replacement at runtime through the approved secret store. Avoid command-line arguments and verbose logs. Limit which jobs and environments can read it.

6. Monitor the old identity

Where provider telemetry permits, look for attempts using the revoked identity, unexpected regions, unfamiliar gateways, abnormal concurrency and unusual destination categories. Preserve only necessary, sanitized evidence.

Verify that the merge gate really blocks

Use a disposable repository and synthetic pattern:

1. enable the ruleset on a test branch;
2. open a pull request containing the harmless synthetic marker;
3. wait for the head-commit scan to complete;
4. confirm the merge is blocked while the alert is open;
5. resolve the alert by removing the marker;
6. push a new head commit and wait for scanning;
7. confirm the rule clears only after the introduced alert is resolved;
8. test that unauthorized users cannot bypass it;
9. verify the bypass audit trail for the emergency role.

Never use a real proxy password as a test marker. The test should remain harmless if the repository, log and screenshot become public.

Separate alert resolution from risk resolution

An alert can be marked resolved because it was revoked, false positive, used in tests or accepted through policy. That workflow state does not prove the operational risk is gone.

For a genuine credential, require a linked response record containing:

credential_alias
repository_alias
first_seen_utc
revoked_utc
replacement_issued_utc
history_review_status
artifact_review_status
old_identity_monitoring_status
incident_owner

Use aliases, not secret values. Keep the response record access-controlled and retention-limited.

Govern bypasses

GitHub rulesets can have bypass actors, so bypass governance determines the real strength of the control. Require a documented reason, incident or release ticket, named approver, narrow repository scope and automatic expiration. Review bypass use after the event.

An urgent production fix should not contain a live credential in source. If an alert is a false positive, improve the pattern or document the synthetic fixture. Do not normalize clicking through warnings.

Buyer and operator implications

Before selecting or renewing a proxy service, ask whether credentials can be independently rotated, scoped by sub-account, limited by region or destination, and audited without revealing the value. Shared permanent passwords make repository exposure more costly than short-lived, narrow credentials.

Also test that rotation does not leave old connections authorized indefinitely. The proxy pool quarantine and recovery guide can keep route-health decisions separate from credential incidents.

Checklist

• [ ] Push protection and PR merge blocking are layered.
• [ ] Protected branches and repository scope are explicit.
• [ ] Proxy-specific patterns use synthetic examples.
• [ ] Bypass permissions are narrow, logged and expiring.
• [ ] Genuine alerts trigger immediate revoke or rotation.
• [ ] History, forks, logs, caches and artifacts are reviewed.
• [ ] Replacement credentials use smaller scope and lifetime.
• [ ] Secrets are injected at runtime and never cached.
• [ ] Synthetic regression tests prove the merge gate.
• [ ] Old credential activity is monitored with sanitized evidence.

FAQ

Does blocking the merge mean the credential was never exposed?

No. The secret may already exist in a branch, fork, workflow log, cache or artifact. Rotate a genuine credential even when the pull request never merged.

Is the new rule available to every repository?

GitHub says the public preview is available to customers with GitHub Secret Protection or GitHub Advanced Security. Confirm current entitlement and repository coverage before relying on it.

Should a detected proxy URL be deleted without rotation?

No. Deletion reduces future exposure, but copies may remain. Revoke or rotate the credential, then remove and verify.

Can generic secret patterns replace provider patterns?

They complement them. Generic patterns can find undocumented formats but may create more false positives. Tune them with synthetic data and controlled governance.

Compliance note

Protect proxy credentials as sensitive authentication data. Use only authorized proxy resources and destinations, respect repository and provider policies, minimize collected logs, and follow applicable incident-notification and privacy requirements. Never publish secret values or use exposed credentials to test third-party access.