Home / Knowledge hub / Security gate
Knowledge hub
Security gate
A pipeline check that must pass before a build is allowed to move on.
What it means
A security gate is a point in a delivery pipeline where a build has to meet a defined security condition before it can go to the next stage. For example, no confirmed critical finding, no exposed secret, or no known-vulnerable dependency above an agreed level.
It turns a policy into something enforced by the system. A gate can sit at a pull request, at the build, before deployment to staging, or before production. It either lets the build through or stops it, and records the reason, which gives you both control and evidence.
Why it matters
A check that only warns changes little, because under deadline pressure warnings are ignored. A gate makes the condition real, because the build simply does not proceed. It also gives you a record that no release shipped with a known serious problem, which customers and auditors value.
The risk is a bad gate. One that blocks on false positives or flaky results is bypassed or switched off, and then you have neither safety nor trust. See gating a build for the mechanics, and keep an owner for every exception.
How it shows up
You meet it in CI/CD configuration as a required status check, a failed job, or an approval step. Repeated mistakes are thresholds so strict that everything fails, no way to record a justified exception, gates that run only after the code has already been deployed, and results nobody can reproduce.
Gate on severity and confidence together, so only serious, confirmed problems stop a build. Allow time-limited exceptions with an owner. Start in report-only mode, tune, then enforce. Make failures explain what to fix. Keep the gate fast enough that people do not route around it.
Questions people ask
Security gate, answered
What should a security gate block on?
Serious findings that are confirmed and fixable, such as a proven critical flaw, an exposed secret, or a known-exploited dependency. Blocking on every low-severity or uncertain result makes the gate too noisy to keep.
What is the difference between a gate and a scan?
A scan produces findings. A gate decides what to do with them: pass the build or stop it. Without a gate, scan results are advice. With one, they are a condition for release.
How do we handle exceptions?
Allow them, but record who approved, why, and when the exception expires. An exception that never expires becomes a permanent hole in the gate, and nobody remembers why. Review open exceptions on a schedule.
Should we start with enforcement on?
Usually not. Run in report-only mode first to see how often it would fail and tune out noise. Then enforce on a narrow set of serious conditions, and widen it as trust grows.
Where in the pipeline should gates go?
Quick checks, such as secret detection, early at the pull request. Slower tests against a running build before release to production. Putting each check where it gives the fastest useful answer keeps developers on side.
Sources
Where this comes from
Related
Terms that sit next to this one
Gating a build
Stopping a release automatically when a security check fails.
CI/CD
The pipeline that builds, tests and ships code on every merge.
DevSecOps
Making security a shared, automated part of development and operations.
Severity vs confidence
How bad a finding is, kept apart from how sure the tester is that it is real.
False positive rate
How often a tool reports issues that turn out not to be real.
Would you trust the gate?
A gate is only as good as the findings behind it. Ours carry proof and keep severity and confidence apart, so a build stops for something real. It can run in CI/CD. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.