A security gate is a policy-controlled decision point in software delivery. It evaluates security evidence—such as SAST, SCA, secrets, container, or IaC findings—and decides whether a pull request may merge, a build may pass, or a release may continue.
The scanner produces evidence; the gate produces the decision. Keeping those responsibilities separate makes it possible to change scanners without rewriting the organization's risk policy.
PR gates, build gates, and release gates
- PR gate: gives developers feedback before code reaches a protected branch.
- Build gate: blocks a build artifact when the current result violates policy.
- Release gate: protects an environment or deployment stage using broader operational checks.
What should trigger a failure?
A gate should not block simply because any finding exists. Effective policies define which severities, project classes, finding states, and exception rules are blocking. Many teams begin in monitor-only mode, measure the result, then tighten thresholds with a controlled rollout.
Avoid pipeline-local policy
If each YAML file computes its own threshold, the gate is easy to fork and hard to audit. A backend-authoritative gate evaluates one policy consistently, returns an explicit verdict, and records the policy version and reason behind it.
