The gap this closes
We already ship a quality gate. It grades one scan and decides whether the findings that run produced should fail that build. It has a blind spot: a repository can pass every individual scan for a year while its backlog grows, its runtimes go out of support, and the migration everyone agreed to in January stays exactly where it was. None of that is visible in a single run. It is visible in the accumulation, which is where the policies organisations actually write live.
What shipped
vulnetix jail assesses the repository against your organisation policy and sets the exit code, with explain, list and exempt subcommands that inspect and waive without gating. A policy editor in the console holds the ordered rules, read at run time so a change applies on the next pipeline run. Attestations are written on every run. A --jail flag on every scan command uploads and assesses in one invocation.
The part we care most about: exit code 3
Most gates have two outcomes. We added a third for the case where the gate ran and could not reach a verdict because the evidence a rule needs is stale or was never collected. That case is common and dangerous: a pipeline stage that quietly stopped running produces a repository with no recent findings, which looks exactly like a repository with no problems. Reporting it as a pass is the worst available answer, and reporting it as a failure sends a developer hunting for a vulnerability that does not exist. Exit 1 means a developer changes a dependency. Exit 3 means whoever owns the pipeline configuration has something to fix.
Decisions worth explaining
Several of these came from getting it wrong first.
When one rule breaches and another cannot be evaluated the run exits 1, not 3, because a violation we can prove is more actionable than an absence.
The default for stale or absent coverage is to refuse a verdict rather than grade whatever happens to be there.
We built it to gate on commit equality and reverted that: it jailed every pull request, because PR builds scan the merge commit.
A migration rule that fails the build the day it is written is a threshold with a date attached, and teams route around those.
There is no permanent waiver. A waiver that never ends is a policy change and belongs in the policy.
Campaign membership stays keyed on the identity that survives a rescan rather than on a foreign key that can be re-minted.
Adopting it without breaking a pipeline
Add the command: an organisation with no policy reports no policy and exits 0, so nothing changes until a rule exists. Write one rule, starting with the remediation window you already publish. Watch it for a sprint with --no-fail, which reports the full verdict while the exit code stays 0. Then enforce, and if it goes badly set enforcement to warn in the console so every rule downgrades at once without a CLI release.
Availability
Release Jails are available now in the Vulnetix CLI and the console. Existing quality gate configuration is untouched: the two are separate policies answering separate questions. If you already run vulnetix scan in CI, adding vulnetix jail after it is the whole integration.