Home / Knowledge hub / Gating a build
Knowledge hub
Gating a build
Stopping a release automatically when a security check fails.
What it means
A build gate is a rule in your release pipeline: a change does not ship until a named check passes. The check runs on every build, and a failure stops the build rather than letting it carry on to production. GitHub calls these required status checks.
The alternative is a report that becomes a ticket somebody reads next month, if at all. A gate moves the decision to the moment the change is made, while the author still remembers why they wrote it.
Why it matters
A gate is the only reliable way to stop a class of problem returning. Without one, a fix is a single event. With one, it becomes a standing rule, which is the difference between fixing a bug and closing a hole. NIST's secure software development framework treats automated checks in the pipeline as a core practice.
Trust is the catch. A gate that blocks a release over a finding that turns out to be nothing gets disabled in the second week. Nobody ever turns it back on.
How it shows up
In practice the gate sits beside your tests as one more required step. You pick the threshold: block on critical and high, warn on medium, log the rest. You also need a written override. There will be a Friday evening when the release has to go out anyway. An undocumented override quietly becomes a permanent one.
Watch the first time it fires on something real. When the team spends the afternoon arguing about whether the finding is genuine, the problem is the check rather than the gate. Our confirmed-only mode, which ships on 19 October 2026, exists for that reason. What it does and does not cover.
Questions people ask
Gating a build, answered
Should a security scan be allowed to fail the build?
Yes, for a narrow set of findings you are confident about. Blocking on everything a tool reports is how gates get removed.
Common practice is to block on confirmed critical and high issues and report the rest. The gate has to be right nearly every time to survive.
What threshold should we set?
Start stricter than feels comfortable on one small service, then widen it. Critical and high block, medium warns, everything else lands in the report.
Review the threshold after a month using the findings it actually caught. Setting it once and never looking again is how a gate turns into background noise.
What happens when a false positive blocks a release?
You need a documented override with a name, a reason and an expiry, available in under five minutes. Without one, somebody will disable the whole gate at eight on a Friday.
Then count the overrides. Frequent use is not an override problem. It is telling you the check is not good enough to gate on.
Will this slow the team down?
It adds the runtime of the check, and it removes the cost of finding the same bug in production weeks later.
The part that genuinely slows teams down is unreliable results. A quick check nobody trusts costs far more than a slow one that is right.
Our developers will just find a way round it. How do we stop that?
Treat the workaround as feedback rather than misconduct. People route around gates that block them on things they know are not real.
Make the finding easy to verify, give a real override path, and gate only on what you can prove. Enforcement with branch protection matters, but it only holds when the check has earned its place.
Related
Terms that sit next to this one
CI/CD
The pipeline that builds, tests and ships code on every merge.
Shift left
Doing security work while code is written, not as a check at the end.
False positive
A reported issue that turns out not to be real.
Severity
How bad a finding is, from critical down to informational.
Regression
A bug that was fixed and has come back, usually undone by a later change.
Would your gate survive a week?
Cyberlop runs on every build and reports each finding with the request, the response and the line of code, so a gate has something solid to fail on. Ask how teams set the threshold.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.