What teams use release jails for
Every one of these is a policy somebody already has and nothing currently enforces. A release jail rule is that sentence written down and evaluated on every pipeline run.
Count findings past the day counts your triage policy already publishes, and fail when too many are.
Filter on KEV listing, published fix, reachability and direct dependencies, so one finding can jail a repository and two hundred need not.
Gate on lifecycle proximity: already retired, within thirty days, this quarter, next quarter.
Name what you are moving off and the date it must be gone. Reports until the date, blocks after it.
Break the build when a tracked count rises, so a legacy backlog can be frozen without pretending it can be cleared.
Secrets, licence, infrastructure as code, containers and malware, on the same terms as everything else.
A repository that quietly stopped being scanned is reported as such, not as clean.
Exemptions carry a reason, an approver and an expiry, and never rewrite the count they suppress.
Four kinds of rule, one shape
Every rule selects a population, aggregates it, and compares the result to a threshold, so learning one teaches you all of them. VULN covers open findings filtered by what makes them urgent. EOL covers dependencies at or approaching end of support, graded with the same proximity buckets the scanner uses. GOAL covers a migration or refactor with a deadline and an optional ratchet. HYGIENE covers secrets, licence, infrastructure as code, containers and malware.
Four exit codes, because there are four answers
0 clear. 1 jailed, meaning at least one rule breached on evidence we hold. 2 a local argument or configuration problem. 3 indeterminate, meaning the gate ran but the evidence a rule needs is stale or missing. When a run both breaches a rule and cannot evaluate another the exit code is 1, because a violation you can prove is more actionable than an unknown.
How the verdict is reached
Only the newest result of each tool counts, resolved per category, so a nightly pipeline does not make every threshold breach permanently. Each rule has a staleness window and refuses to grade old evidence by default. Goals warn until their deadline and block after it. Exemptions suppress a failure and nothing else: the verdict still carries the real observed count, the threshold, and which exemption changed the outcome.
Evidence on every run
Artefacts are written before the exit code is decided, because a red gate is when evidence is needed most. The vulnerability half becomes OpenVEX or CycloneDX; end-of-life, goals and hygiene become SARIF, since VEX has no vocabulary for a runtime past support or a migration that missed its date. Assessment history is recorded per rule and per branch.
Turning it on
An organisation with no policy reports no policy and exits 0. Run with --no-fail to see the verdict without enforcing it, and set enforcement to warn in the console to disarm every rule at once without waiting for a CLI release. Passing --jail to any scan command uploads and assesses in one step.
Compare with the per-scan Quality Gate, or read the release announcement.