Create an organization ruleset that targets all repositories (or a pattern) and add rules such as require a pull request, require status checks to pass, and require code scanning results. Run it in evaluate mode first if your plan offers it, then enforce.
Rules worth knowing
The GitHub documentation lists the rules available in a ruleset. The ones relevant to security checks:
| Rule | Use it for |
|---|---|
| Require a pull request before merging | Force review of every change |
| Require status checks to pass before merging | Make your scan job a hard requirement |
| Require code scanning results | Block merges that fail code scanning thresholds |
| Require secret scanning alerts are resolved (public preview) | Stop merging with open secret alerts |
| Require license compliance results before merging | Gate on license policy |
| Restrict file paths | Protect paths such as workflow files |
| Block force pushes | Keep history intact |
Availability can vary by plan and some rules are in preview, so confirm in your own settings.
A rollout in five steps
- Decide the target. Start with a repository name pattern or a custom property that marks production services.
- Pick one rule to start with, usually require status checks, naming the check your shared workflow produces.
- Add a bypass list that is short and named, such as the platform team and an emergency role.
- Evaluate before enforcing, if available, and read which repos would have failed.
- Enforce, and publish how to request an exception.
The check name trap
A required status check matches by name. If your shared workflow produces a job called "security-scan" and one team renames it, the rule waits forever for a check that never reports. Keep the job name stable, version it with the template, and test with a pilot repo. You can also choose a specific GitHub App as the expected source of a check.
What rulesets do not do
They enforce what happens at merge. They do not scan, triage or fix anything, and they cannot tell if a scan is meaningful. A scan that returns success because it is misconfigured satisfies the rule. Add coverage reporting so you can see which repos run the scan and with what settings.
Layering with branch protection
Rulesets can layer with existing branch protection, and the most restrictive result applies for overlapping rules. Review both when a developer reports being blocked. See also rulesets versus branch protection and bypass lists.
Quick check
Do rulesets replace CI gates?
No. The ruleset requires that a check passes. The check itself still comes from your pipeline or scanner.
Who should be on the bypass list?
Keep it small and named, with every bypass logged and reviewed. An empty list with a documented emergency role is better than a broad team.
Safeguard policies and gates can supply the check that a ruleset requires, and the free scan at gold.safeguard.sh/scan shows what a result looks like.
Sources
- GitHub Docs: Available rules for rulesets, fetched 19 October 2026
Last reviewed: 19 October 2026.
