Baselines and release gates

Two ideas do most of the work here. A baseline says which findings you have already accepted. A release gate turns findings, coverage and policy into one decision somebody can act on.

What a baseline is

A saved set of findings you have reviewed and decided to carry for now. Comparing a scan against it separates what this change introduced from the backlog that was already there.

This is the difference between a gate a team adopts and one they switch off in week one. Turning a scanner on for the first time against an established codebase produces a wall of findings; without a baseline, every build fails and nobody can ship.

New, existing and resolved

Class	Meaning	What to do with it
New	In this scan, not in the baseline	This is what a new-findings gate blocks on. It is also the only part a code reviewer needs to read.
Existing	In both the scan and the baseline	Reported, not blocking. Work it down deliberately rather than under release pressure.
Resolved	In the baseline, absent from this scan	The only positive feedback a scanner ever gives. Worth showing the team.

A worked example: a baseline holds SEC-001 andDEP-004. Today’s scan finds SEC-001 andREL-002. That is one existing finding, one new finding, and one resolved finding — and with a new-findings gate, only REL-002 stops the build.

The flags

Terminal

# Compare against an accepted set.
guardian scan . --baseline guardian-baseline.json

# Block only on what this change introduced.
guardian scan . --baseline guardian-baseline.json --fail-on-new

# The release decision itself.
guardian release check

Both flags appear in the bundled CLI’s help output forguardian scan. --fail-on-new is only meaningful alongside a baseline: without one there is nothing to be new relative to.

How a decision is formed

Findings

Severity, category, location and remediation context.

Coverage

Which analyzers completed, which were incomplete, which did not run.

Policy

The conditions you configured for whether a release may proceed.

Severity and the release decision are different things. A high-severity finding in a component you do not ship may not block; a medium one in the release configuration might. Policy decides, and the decision reports which rule applied.

When analysis is incomplete

Missing evidence is reported as missing. A check that could not run appears in the coverage list as incomplete or not run, and is never folded into a pass.

This is deliberate, and it is the single most important property of the gate. Confusing “we did not check” with “it passed” is how a known defect reaches production, and a tool that hides the difference is worse than no tool.

What a gate cannot prove

A passing gate does not mean the release is safe. It means the analyzers that ran, over the evidence available, found nothing your policy treats as blocking.
No numeric readiness score is produced, deliberately. A number invites the reading “87% safe”, which nothing here supports.
A gate does not replace review, testing or judgement. It makes the repeatable part cheap so the expert part gets the attention.

Wire this into a pipeline