A security finding should fail the build when it is new in this change, the tool is confident it is real, and the risk is concrete, such as a leaked secret, a known exploited dependency or a reachable critical flaw. Everything else should warn, ticket or wait. Blocking on noise teaches developers to bypass the gate.
What "fail the build" actually does
A failed check only matters if the branch rules enforce it. On GitHub, required status checks must report a successful, skipped or neutral result before a pull request can merge into a protected branch. By default, repository admins can bypass those rules unless the "Do not allow bypassing" setting is on. So the decision has two parts: which findings turn the check red, and who is allowed to merge anyway.
A red check is a cost. It stops a developer, forces a context switch and, if it is wrong, spends trust that is hard to earn back. Spend it on findings you would stop a release for.
A decision table
| Finding type | Fail the build? | Why |
|---|---|---|
| Hardcoded secret in the diff | Yes | Cheap to fix now, expensive after it is pushed and copied |
| Dependency listed in the CISA Known Exploited Vulnerabilities catalog | Yes | The catalog lists flaws seen exploited in the wild |
| New critical flaw, reachable from your code | Yes | Real exposure, and the change introduced it |
| New high severity, reachability unknown | Warn, ticket with a due date | Likely real, but evidence is thin |
| Existing finding, untouched by this change | No | Not this author's problem today; handle in the backlog |
| Low or informational | No | Report only |
| License policy violation on a new dependency | Yes, if policy is explicit | A policy decision, not a severity one |
Three rules that keep the gate credible
Gate on new findings. Compare against the base branch and block only what the change adds. Gating on the whole backlog makes every pull request fail for reasons the author did not cause.
Require evidence for the red check. A finding with a data flow, a reachable call path or an exploitation record can justify a stop. A pattern match with no context usually cannot.
Give every block an exit. A documented, logged override for the rare false positive is safer than developers inventing their own workaround. Review overrides weekly.
Start in report mode
New gates should run in report mode first. Collect two weeks of results, count how many would have blocked, and read a sample by hand. If more than a handful look wrong, fix the rule before you enforce it. The OWASP DevSecOps Guideline makes the same point about adding automation gradually and tuning it to the pipeline you have.
Try it yourself
Open the demo below and watch which pull request changes pass and which fail. Notice that the gate acts on what the change introduces.
Click through it at your own pace, or open it full screen.
Quick check
Should critical severity always block a merge?
No. Severity alone is a weak signal. A critical in a dependency function your code never calls is a ticket, not a stop. A critical that is reachable or on the exploited list is a stop.
Who should be able to override a failed security check?
A small named group, with a reason recorded on each override. Admin bypass should be switched off in branch protection so the rule applies to everyone.
Safeguard offers policies and gates, along with reachability analysis to separate reachable flaws from noise. You can try a free scan on a repository to see what a gate would have caught.
Sources
- GitHub Docs: About protected branches
- CISA Known Exploited Vulnerabilities Catalog
- OWASP DevSecOps Guideline
Last reviewed: 19 October 2026.
