Gates & Policies
Paths: /gates and /policies · Sidebar: CI/CD → Gates · Governance → Policies
A policy is a set of rules; a gate applies your policies to a pipeline run and returns pass / warn / fail with an exit code your pipeline honours. Together they stop risky code from shipping - on your terms, and fail-closed.
Enforcement mode: Monitor → Block
The single most important control is the enforcement mode, toggled from the top of the Gates page:
| Mode | Behaviour |
|---|---|
| Monitor (default) | The gate is fully evaluated and the decision is recorded, but the build is never broken (exit 0, passing commit status, a "monitor mode" banner on the PR). The onboarding / audit phase - you see exactly what would block while you close gaps. |
| Block | Enforce. A failing gate breaks the build (non-zero exit + failing commit status) so branch protection stops the merge. |
This is a server-side decision - flip Monitor → Block from the UI when you're
ready, with no edit to your pipeline YAML. (Set the hard-gate option if you
also want warn decisions to fail the build.)
Start in Monitor, watch the verdicts on real PRs for a sprint, fix the high-signal findings, then switch to Block. A gate that fails rarely but meaningfully is the one teams respect.
Fail-closed
A security gate must never pass silently when it could not run. If the gate cannot be evaluated (a database error, a rule-engine fault), apPosture fails closed - the build fails - and records an audit event. (Legacy fail-open is available behind a setting for teams that need it.) In Monitor mode the failure is still recorded but, by design, the build is not broken.
What the gate evaluates
Each run's verdict is the worst of several independent signals:
- Severity threshold - fail on new (or all) findings at/above a chosen severity. Computed from the run's findings.
- Rule engine - your deterministic rules (scope = gate), e.g. block on KEV, block on proven-exploitable, risk-score thresholds.
- Policies - environment- or app-scoped policies (strict for prod, lenient for dev).
- Threat-model blind spots - unverified critical/high threats raise a warn, nudging you to confirm them (see Threat Models).
Risk-accepted findings are excluded automatically.
New vs existing (per-branch baseline)
On a pull/merge request, the gate diffs against the default branch's latest run, so it can fail on new findings only - the risk this change introduces - without drowning the PR in pre-existing debt. Only default-branch runs write to the posture baseline, so a feature branch's findings never pollute production risk.
PR decoration
When a token is connected, apPosture posts back to the SCM:
- a commit status check on the head SHA (what branch protection blocks on),
- an update-or-create PR/MR comment summarising the decision, new findings, scanners that ran and compliance impact,
- optional inline review comments on the exact changed lines (GitHub), with a one-click Commit suggestion for single-line fixes.
In Monitor mode the commit status is always a pass and the comment shows a Monitor mode banner.
Policies
Path: /policies
Define the rules that express your risk appetite:
- Block on severity - fail if any Critical (or High) findings are present.
- Block on KEV / exploitable - fail on a KEV-listed or proven-exploitable finding.
- Thresholds - fail if total risk exceeds a score, or new findings exceed N.
- Scope - different rules per environment or per application/product.
How a gate runs
- The pipeline agent (or an inbound webhook) triggers a scan for the repo/branch.
- The gate evaluates the run against the threshold + rule engine + policies (+ threat blind spots), diffing new-vs-baseline.
- The verdict returns to CI - a failing gate in Block mode exits non-zero and stops the release; Monitor mode records it without breaking the build.
- The result is decorated on the PR and recorded on the pipeline run.
Every gate evaluation is written to the audit log.