The job is configuration you add to .gitlab-ci.yml: a stage, a script step, and a variable holding the severity that fails it. What runs behind that job is a penetration test that proves what it reports — and the threshold deciding whether your deploy stage starts is a line in your own file, not a setting we hold.
The job definition
Five keys. The values below are illustrative — the job name is yours, and every value in the middle column is a decision rather than a default.
| Key | Illustrative value | What it decides |
|---|---|---|
| stage: | security | Which stage the job belongs to, declared in the top-level stages list like any other. Where you put it in that list is the whole design decision: it fixes what has already run when the scan starts, and what is downstream of the result. |
| script: | An authenticated call to the B-52 API | Starts the run against the target this job names, and executes on whichever runner the stage already uses. How the job then relates to the result — whether it waits, or hands off to something later in the pipeline — is settled when the integration is set up, against how long your runs take and what your runner timeouts allow. |
| variables: | B52_FAIL_ON: high | The severity threshold — the one line here that can stop a pipeline. It is read against the finished run, so a finding at or above it fails the job and a finding below it is reported without gating anything. |
| The variable name is illustrative. What is not illustrative is where it lives: in the file you commit, so changing the bar is a merge request rather than a support ticket. | ||
| rules: | if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH | Which pipelines carry the job at all — every push, the default branch only, merge requests, or a schedule. A scheduled pipeline is a pipeline, so the cadence question is answered here too. |
| allow_failure: | false | Whether a failed job stops the pipeline or is recorded and stepped over. This is the line that decides whether the gate bites or advises, and it is a one-word change in either direction. |
stage:
script:
variables:
The variable name is illustrative. What is not illustrative is where it lives: in the file you commit, so changing the bar is a merge request rather than a support ticket.
rules:
allow_failure:
Where it sits
The job definition does not change between these. What changes is what a failure costs, and that is decided by where the job sits rather than by anything we control.
What it takes from you
Three things, and two of them are already GitLab’s. The target is the application or host this job is testing, named in the job. The credential is a project CI/CD variable, masked and protected the way the rest of your pipeline secrets are, so it never appears in the file you commit. The job itself is the block above, reviewed in a merge request like any other change to the pipeline. Nothing is required inside your network for external and application testing — the runner calls out, and the run happens on our side, in the data residency region you choose. Internal network testing is the one case that does need something deployed on the inside, and on-premise and customer-VPC deployments both exist for that.
The gate
Four outcomes. Which one you get is settled by two lines you already wrote — the threshold, and allow_failure.
| State | What it means | What follows |
|---|---|---|
| Nothing at or above your threshold | The run finished and everything it returned sits below the severity you set. | Job passes. The next stage starts. |
| A finding below your threshold | Reported, and not a gate decision. It lands with the same evidence as anything else — the threshold governs the pipeline, not what gets found or written up. | Job passes. The finding is still there to work. |
| At or above your threshold, with allow_failure false Terminal | The gate bites, and GitLab treats it as it treats any failed job in the stage. | Job fails. Nothing in a later stage starts, and the pipeline ends failed. |
| At or above your threshold, with allow_failure true | The same result, recorded instead of enforced. This is the setting to run while you are deciding where the bar belongs. | Job fails and is marked. The pipeline carries on to the next stage. |
The threshold
The severity that fails the build is a variable in the file you commit, and that placement does three things a console setting cannot. It changes through a merge request, so raising or lowering the bar is reviewed by the people who own the pipeline. It is versioned, so the history of what you gated on sits in git beside the history of what shipped. And it can differ between branches, or between projects, without anybody asking us. One case is worth writing down because it is not a severity decision at all: if the run ends without a result — a target that never answered, a credential that expired — there is nothing to compare against the threshold, and the job fails the way any job fails. That is an infrastructure failure, the job output says so, and it should be read as one.
Per finding
The job output names what crossed the line. Everything beneath it is already in the dashboard while the pipeline is still going red.
Its severity, the target it was found on, and why the job exited as it did — so the engineer looking at a red pipeline does not have to open anything else to know what happened.
The request as sent and the response as returned, with the part that proves the defect marked. Findings are reached rather than inferred from a version banner, which is what makes the gate safe to enforce.
Written for the engineers who own the code, to be followed without a call back to us first. A finding nobody can reproduce is a ticket that stays open.
A CVSS v4.0 vector and the CWE travel with every finding, so the score the threshold is read against can be recomputed under your own environmental metrics rather than inherited from us — which matters most while you are still settling where the bar belongs.
Open, fixed, retested, closed. It closes on a retest that cannot reproduce it, so a pipeline that stopped once has a documented reason it stops no longer.
Where it lands
| Where | What is there | Who reads it |
|---|---|---|
| The job output | The finding that crossed the threshold, its severity, and the target it was found on. | The engineer whose pipeline just went red. |
| The pipeline view | A failed stage, with everything behind it showing as never started. On a merge request pipeline it sits against the change that caused it. | Whoever is reviewing the merge request. |
| The dashboard | Every finding from the run — proved, classified, and carrying its state — including the ones below the threshold that stopped nothing. | The team that has to fix them. |
| The delivery models | The written report, and whose signature it carries. That is decided by the delivery model you chose, not by which pipeline the run started from. | Whoever has to file it. |
The job output
The pipeline view
The boundary
Deliberately excluded
Getting it running
One scan is one application or target, and the entry price is $500. A pipeline that builds one application needs one job. A pipeline that builds several needs a job for each, named and scoped before the first run. Where the target is a web application, a mobile app, an API, a thick client, or a secure code review, the whole thing can be set up on the card flow without speaking to anyone. Everything else — a perimeter, an internal network, a cloud estate, an Active Directory, an LLM application — starts with a scoping call, because what is in scope gets signed rather than typed into a form. Beyond a single target the arrangement is settled on three axes — how many targets, how often they run, and which delivery model signs the report — and those are a conversation.
One scan is one application or target. A $299 trial is one scan on one target through the card flow — open to web applications, mobile apps, APIs, thick clients and secure code review — enough to see exactly what the job hands back before you wire it into the branch that matters.