Secret Scanning Is Becoming a Merge Gate. That’s a Better Place to Stop Leaks.

That distinction matters, and GitHub's latest secret scanning update is a good example of security moving closer to the point where engineering decisions actually happen.

On September 9, GitHub introduced a repository ruleset that can block a pull request from merging when the PR introduces an unresolved secret scanning alert. The rule also blocks the merge if secret scanning has not completed for the PR's head commit.

At first glance, this sounds like another CI/CD check. I think it is more interesting than that.

Most teams already understand the basic advice: don't put credentials in source control. The harder problem is enforcing that rule consistently across hundreds of repositories, different development teams, automation accounts, generated code, Terraform, Kubernetes manifests, CI/CD workflows, and now AI coding agents.

A developer might accidentally commit an AWS key into a Terraform variable file. A Kubernetes manifest might contain a token copied from a test environment. A workflow could include a PAT while someone is debugging an API call. An AI coding assistant can also generate configuration that looks correct while quietly embedding a credential provided earlier in its context.

Training helps, but training is not a control.

This is why I like security controls that sit directly in the engineering path.

GitHub's new rule checks whether secret scanning finished and whether the pull request introduced an unresolved alert before allowing the merge. Provider patterns are covered by default, and teams can configure custom and generic patterns as well. The feature is currently in public preview for customers using GitHub Secret Protection or GitHub Advanced Security.

There is an important difference between this and push protection.

Push protection tries to stop a secret before it is pushed. That is still the best outcome because the credential never enters repository history in the first place.

Merge protection is another boundary.

Maybe push protection was bypassed. Maybe a pattern was introduced through another workflow. Maybe several commits were added to a pull request and the secret became visible later. The merge rule gives the organization another opportunity to say: this cannot enter the protected branch until the alert is dealt with.

From a DevSecOps perspective, this is how I prefer to think about pipeline security: not as one scanner, but as several independent control points.

For example:

Developer workstation → pre-commit checks → push protection → pull request scanning → merge policy → CI/CD scanning → deployment policy → runtime detection.

No individual layer is perfect. The value comes from making it difficult for one mistake to travel all the way to production.

There are a few practical things I would look at before enabling a rule like this across an enterprise.

First, start with visibility. Understand which repositories generate secret alerts today and which patterns cause them. A security gate that suddenly blocks dozens of teams without context will quickly create pressure for broad bypass permissions.

Second, treat bypass as an exception path, not the normal workflow. If developers can bypass the control easily, log who did it, why they did it, and what happened to the credential afterward. A secret marked as a false positive is very different from a real cloud key that needs immediate revocation.

Third, include organization-specific secrets. Provider patterns are useful, but many companies have internal API tokens, service credentials, database connection formats, or legacy keys that a generic scanner will not understand. Custom patterns can close part of that gap.

Fourth, connect detection with response. Finding a credential is only half the job. If it is valid, the useful question is how quickly it can be revoked or rotated. For cloud environments, that might mean disabling an IAM access key, rotating a service credential, or replacing a long-lived secret entirely with workload identity or OIDC.

That last point is especially important.

Secret scanning should not become an excuse to keep creating more secrets.

For CI/CD pipelines, I would rather see GitHub Actions authenticate to AWS, Azure, or GCP using short-lived federated identity than store permanent cloud credentials in repository secrets. In Kubernetes, workload identity and external secret-management patterns can reduce the number of credentials developers ever need to handle directly.

And AI-assisted development makes this even more relevant.

As coding agents gain the ability to modify repositories, create pull requests, update infrastructure code, and trigger workflows, the assumption that every change was carefully typed and reviewed by a human becomes weaker.

That means deterministic controls become more valuable, not less.

An AI agent can suggest code. It can even open the pull request. But whether that pull request is allowed to merge should still depend on clear policies that the agent cannot simply reason its way around.

This is one of the broader changes I see happening in DevSecOps. We are moving from security tools that only report problems to controls that participate directly in delivery decisions.

That has to be done carefully because poorly designed gates can slow teams down. But when the signal is strong and the remediation path is clear, preventing a known credential leak before merge is exactly the kind of friction I am comfortable adding.

The goal is not to make developers think about security every minute of the day. It is to build the delivery system so that common mistakes are difficult to turn into incidents.

How are you handling secret detection today: mostly alerts and developer education, or are you already enforcing it as part of your pull request and CI/CD policies?

SOURCES: https://github.blog/changelog/2026-09-09-block-pull-requests-with-exposed-secrets-from-merging/ https://docs.github.com/en/code-security/how-tos/secure-your-secrets/prevent-future-leaks/block-merges-with-secrets https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets