Build gate

A result can fail the build, on a number you set

The threshold is a severity, and it is yours. At or above it, the run fails the build and whatever was waiting on that build waits. Below it, the build passes — and the finding is reported in full either way.

Run a scan The four pipelines

The mechanics

What the gate decides, and what it leaves alone

Every finding B-52 reports carries a severity, with a CVSS v4.0 vector and the CWE behind it. The gate reads that one field. You name a severity, and the run compares what it found against the line you drew.

Where the finding sits	What the pipeline does	What is reported
At or above your threshold	The step ends in failure and the build fails with it. Whatever was waiting on that build — a deploy, a promotion, a tag — does not run.	The finding in full, with the request, the response and the steps to reproduce it.
One finding at or above the threshold is enough. Nothing is averaged, and a run full of lower-severity findings never adds up to a failure.
Below your threshold	The step ends in success and the build carries on. Nothing downstream is held, and no approval is needed to continue.	The same finding, in the same detail. What gets written down does not depend on the gate.

At or above your threshold

What the pipeline does: The step ends in failure and the build fails with it. Whatever was waiting on that build — a deploy, a promotion, a tag — does not run.
What is reported: The finding in full, with the request, the response and the steps to reproduce it.

One finding at or above the threshold is enough. Nothing is averaged, and a run full of lower-severity findings never adds up to a failure.

Below your threshold

What the pipeline does: The step ends in success and the build carries on. Nothing downstream is held, and no approval is needed to continue.
What is reported: The same finding, in the same detail. What gets written down does not depend on the gate.

The gate settles one question, which is whether this build continues. It never settles whether a finding is real — that is worked out inside the run, and the sixth phase is a quality review that happens on the finished report before it reaches you. The six phases set out where that review sits.

The number

Why the threshold is yours

There are two ordinary ways for a security step to die in a pipeline, and a threshold set by the vendor produces both of them. The number existing, and belonging to you, is the part that matters.

01 Failure mode one

A gate that fails on everything stops being a gate

What happens: Every low-severity finding turns the pipeline red. The release that was going out goes out anyway, after somebody comments the step out to unblock a Friday.
Why it happens: The threshold was set by whoever cared most about findings rather than by whoever answers for the release.
What follows: The step survives in the configuration and stops changing any decision. That is worse than never wiring it in, because it still reads as coverage on an architecture diagram.

02 Failure mode two

A gate that fails on nothing is a log line

What happens: The threshold sits above anything the run realistically returns, so the step always passes and the result is read by nobody.
Why it happens: A number picked to avoid an argument at wiring time, rather than one somebody would defend in a release meeting.
What follows: The findings are still there and still reported. What is missing is the moment where somebody has to decide, and that moment is the only thing a gate adds.

03 Why the number is yours

Stopping a release is a release decision

What the choice is: The severity at which a build should stop is a judgement about what you are willing to ship on a given day — the same judgement that governs a failing test or a missing approval.
Who makes it: Whoever answers for the release. A vendor default is us making that call on a codebase we do not ship and a calendar we do not keep.
What follows: B-52 supplies the severity, with the CVSS v4.0 vector and the CWE behind it. You supply the line. The only number we will not set is the one you have to defend.

In the pipeline

What a failing result looks like

Stated at the level it is true at, and no further. A failed step ends non-zero, which is what every one of the four systems reads as failure, and the build stops the way it stops for a failing test. There is no separate mechanism to learn and nothing for a release engineer to reason about differently.

What the step is given, and what it returns

step: Run a B-52 scan as part of this pipeline.
target: The application or target the scan runs against, as settled at scope sign-off.
threshold: The severity at or above which this build should stop.
result: A pass or fail status your pipeline already knows how to act on.
detail: The finding itself, in the dashboard rather than in the build log.

Written as meanings rather than as key names. Each of the four systems spells its configuration its own way, and what this step is called in yours is settled when it goes in.

The failure output has one job, which is to make a red build legible without trying to be the report. An engineer looking at a stopped pipeline needs to know that the stop was the gate and where to read the rest. The rest is not in the log: the request, the response, the steps to reproduce and the CVSS v4.0 vector sit in the dashboard, where the finding can be read, retested and closed. The dashboard is where that half lives.

Below the line

A finding under the threshold is still a finding

A threshold set high is not a filter on the report. Everything the run found is reported with the same evidence, and every finding moves along the same four states, closing on a retest rather than on anybody saying the work is done.

The four states a finding moves through, gate or no gate
State	What it means	What moves it on
Open	Reported with its exploit artefact — the request, the response and the steps to reproduce it.	A change on your side, then a retest.
Fixed	The change has been made and the finding is queued to be run again.	The retest itself. Saying it is fixed is not what closes it.
Retested	The finding has been run again against the changed target.	It closes if the retest cannot reproduce it, and stays open if it can.
Closed Terminal	A retest could not reproduce it.	Nothing further.

Key

Live against the target
Waiting on a retest
The retest has run
Closed on evidence, not on assertion
TerminalNo state follows this one

All four apply to a finding the gate let through. Raising or lowering the threshold changes which builds stop. It changes nothing about what was found, what evidence came with it, or what has to happen before it closes.

The four pipelines

The same decision in each of them

What differs between the four is where the step sits in the configuration and what that system calls things. The gate itself is the comparison described above, and it behaves the same way in all of them.

GitLab CI GitHub Actions Jenkins Azure DevOps

A scan inside a pipeline is the same unit as a scan anywhere else — one application or target. What a scan covers sets out the boundary, and continuous assessment covers the cadence question underneath it: testing the build that shipped rather than the one the audit calendar happened to land on.

Agree the number before the first red build

It is a short conversation with whoever owns the release, and it goes better before the step is wired in than after it has stopped something. Run a scan first if you would rather see what the threshold would have been set against.

Run a scan Request a scoping call