Run the scan as a named job on every pull request, then open your branch protection rule and require that job's status check before merging. Test it with a deliberately failing change. Also confirm the job cannot be skipped, because on GitHub a skipped check counts as passing.
What "required" means
A scan that runs but is not required is advice. Anyone with merge rights can ignore a red result. A required check turns the result into a condition of merging.
GitHub's documentation lists the relevant protection settings, including requiring pull request reviews, requiring status checks, requiring a merge queue, and a setting that blocks bypassing the rules. It says required status checks must have a successful, skipped, or neutral status before collaborators can change a protected branch.
Steps
- Create a workflow that runs the scan on the pull request event. Give the job a stable, specific name such as security-scan.
- Open the repository settings and add a branch protection rule for your main branch.
- Enable the option that requires status checks before merging.
- Search for your job name and add it to the required list.
- Open a test pull request with a known failing condition and confirm the merge button is blocked.
- Open a second test pull request that changes only documentation and confirm the check still reports a result.
Step 6 matters. If your workflow uses path filters and the scan does not run for some changes, a required check can hang as pending or, in other setups, be treated as skipped.
Common pitfalls
| Pitfall | Effect | Fix |
|---|---|---|
| Job renamed later | Required name no longer matches, check never reports | Keep job names stable and update the rule when renaming |
| Path filters skip the job | Merge blocked or check bypassed | Run the job always, and filter inside it |
| Admins can bypass | Rule does not bind everyone | Enable the setting that prevents bypass where your policy requires it |
| Scan errors exit zero | A broken scanner looks like a pass | Fail the job on tool errors |
| Forks lack secrets | Scan cannot reach its data | Design a safe fork path, see the fork post linked below |
Skipped is not the same as passed
The documented behavior is that skipped satisfies a required check. That is convenient for conditional workflows and risky for security. Review any condition on the job, such as an if expression on the actor or the changed files, and ask whether it could cause the scan to be skipped on a change that matters.
Related reading
Pull requests from forks need special care. See scanning pull requests from forks without exposing secrets.
Where Safeguard fits
Safeguard provides policies and gates that report a pass or fail status on pull requests, which you can then mark as required in branch protection. You can see the kind of results it returns with the free scan at https://gold.safeguard.sh/scan.
Quick check
Does a required check stop administrators too?
Only if the rule is set to apply to them. GitHub lists a setting that prevents bypassing the protection settings. Decide deliberately whether admins are included.
What if the scan is slow?
Scope the pull request scan to changes and move full scans to a scheduled job. A required check that takes too long gets disabled by frustrated teams.
Sources
Last reviewed: 19 October 2026.
