Repository rulesets allow you to easily add scalable protections across your repositories. Starting today, you can use repository rulesets to block pull requests from merging when the pull request introduces secret scanning alerts.

What’s new

You can enable the new rule require secret scanning alerts are resolved on pull requests for selected repositories. Developers without bypass permissions must clear the block by resolving each alert.

The rule checks two things before a pull request can merge:

  • A secret scan has completed for the head commit
  • No alerts are open for secrets introduced by the pull request’s commits

By default, the rule runs on open pull requests and blocks secrets found via provider patterns. You can additionally configure the rule to block other categories (e.g., custom or generic patterns).

This rule is available today in public preview for customers with GitHub Secret Protection or GitHub Advanced Security.

How this rule differs from push protection

Push protection stops a secret at the push, before it ever reaches the repository. This rule adds an additional layer of protection at the pull request layer, catching cases that push protection isn’t able to or configured to catch. For example, you may keep push protection disabled for generic pattern secret types, while keeping a ruleset to block pull requests for those secret types.

How to configure the rule

  1. In your repository, organization, or enterprise settings, go to the Repository > Rulesets tab.
  2. Create or edit a ruleset targeting the branches you want to protect.
  3. Select Require secret scanning alerts are resolved.

You can also configure the rule through the REST API using the require_secret_scanning_alert_resolution rule type with a secret_types parameter, or through GraphQL as REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION.

Learn more

Learn more about secret scanning and push protection in our documentation.

See the rulesets documentation for how rules are applied and bypassed.