Severity thresholds
"No criticals" blocks a library nobody calls and passes a medium on the login route.
Make security part
of every release.
Evaluate your security policy in the deployment path. Keep signed decisions, supporting evidence and human-reviewed exceptions together.
Release candidate
Scan evidence
Policy evaluation
Decision record
Investigation context
01 / Gather evidence
Start with the release being evaluated.
- Release reference
- Evidence freshness
Connect the artifact and scan results to the policy input.
02 / Evaluate policy
A missing answer must stay visible.
- Policy result
- Failure reason
Inspect the rules and failures behind the decision; uncertainty is not a silent pass.
03 / Record decision
Keep the outcome reviewable.
- Decision record
- Exception reason
Retain the gate decision and any accountable exception for later review.
OPA
Rego evaluation
Hand-written or built visually; every error is a deny.
PR · CI · K8s
Gate points
Pull request, pipeline and cluster admission.
Exit codes
Pipeline-ready
Policy failure and API error are never confused.
Signed
Control decisions
Independently verifiable by your auditors.
The problem
Why do most CI security gates get bypassed?
A gate that blocks every critical blocks nothing for long, because teams route around it. The gates that last are the ones developers trust.
01
02
Fail-open by default
When the scanner is down the build goes green, so the gate is only as reliable as the least reliable tool.
03
Overrides without a trail
A retry with the check disabled leaves no record of who decided what.
04
Comment storms
Every push re-posts every finding until developers mute the bot.
05
One rule per pipeline
Policy lives in a YAML file per pipeline and drifts between them.
06
No exception model
Risk acceptance happens in chat and never expires.
How SecurityVault does it
How do SecurityVault deployment gates decide?
Policy over the graph, with every decision on the record.
Inputs
The gate input carries the findings on the change, their reachability hints, the subject's exposure and any active exceptions. A gate can fire at three points on the same chain: the pull request (source), the build (image, SBOM, provenance) and admission (the cluster refusing an unsigned or non-compliant image). One policy, three stages.
Evaluation
Open Policy Agent evaluates the policy over a structured input. An evaluator error is a deny with a recorded reason, and no configuration turns that into an allow.
Pull requests
A new push supersedes the earlier scan on the same pull request. Results go up as SARIF and as annotated comments through a per-organisation rate limit, with every attempt recorded.
Pipelines
esos ci scan --fail-on high or the gate evaluation API. Exit codes separate allow, deny and error, so a pipeline can tell a policy denial from an outage. See the CLI reference.Overrides
Break-glass on a scan requires an authorised principal and is written as an audited event; it never rewrites the original decision.
Exceptions
Owner, expiry, approver chain and optional dual control. An expired exception stops satisfying the policy.
Outcomes
What do teams get from a fail-closed gate?
01
Blocks that hold
Reachable, exposed issues stop the change; unreachable noise does not.
02
No silent passes
An outage is an error, never a green build.
03
One policy everywhere
GitHub, GitLab, Bitbucket, Azure DevOps and Jenkins evaluate the same Rego.
04
Quiet pull requests
Rate-limited, superseding comments that developers keep reading.
05
A decision record
Every decision and override lands in a hash-chained audit log.
FAQ
Deployment gate questions
- What is a policy-as-code deployment gate?
- A deployment gate is an automated check in a pull request or pipeline that decides whether a change may proceed. Policy as code means the rule is written as versioned code, here Open Policy Agent Rego, so it is reviewed, tested and applied the same way everywhere. See policy as code.
- What happens when the gate cannot reach a decision?
- It denies. A policy evaluation error is a denial, and no configuration turns it into an allow. The CLI returns a distinct exit code for an API error, so a pipeline can tell a policy failure from an outage.
- Can a gate use reachability and exposure instead of severity counts?
- Yes. The gate input carries the findings on the change, their reachability hints, the subject's exposure and any active exceptions, so your policy can consider available context. Explicitly define the outcome for unknown or missing signals; absence of a reachability result must not imply safety. Read why severity counts make weak gates.
- Which CI/CD systems are supported?
- GitHub, GitLab, Bitbucket, Azure DevOps and Jenkins, through webhooks, SARIF upload, annotated pull-request comments and the esos command line.
- How are overrides and exceptions controlled?
- Break-glass overrides require an authorised principal and are written as audited events that never rewrite the original decision. Exceptions carry an owner, an expiry and an approver chain, with optional dual control, and stop applying the moment they expire.
Related: risk-based vulnerability management · container image security · IaC security · policy as code for deployment gates with OPA and Rego · SecurityVault for platform engineering · SecurityVault for developers.
From the blog
Further reading on deployment gates
- Rollback security: reassess the release you restoreReview rollback security with exact artefact identity, current evidence and dependency checks so an older release does not inherit an outdated approval.
- Policy-as-code testing: verify release decisionsTest policy-as-code release decisions with explicit inputs, negative fixtures and failure cases before promoting a gate into the delivery workflow.
- Fail-closed deployment gates: why severity counts failFail-closed gates built on severity counts get routed around. Use reachability, exposure, ownership and recorded overrides to keep them trusted.
- Policy as code for deployment gates with OPA and RegoPolicy as code with OPA and Rego turns deployment gates into testable rules that explain every decision at pull request, pipeline and admission.
See it on your stack
Put a real gate on one pipeline.
We wire one repository, one policy and one pipeline, then show you the decision record.