Skip to main content
B‑52
Run a scan
Integration · Jenkins

Security testing in your Jenkinsfile, with nothing to run inside your network

A stage, a step, a threshold and a build result Jenkins already understands. Your controller stays where it is, on the network it is on — for external and application testing nothing is required inside your estate. What the stage carries is the decision: at or above the severity you set, the build fails.

Take the $299 trial Scope it with us

Deployment

Nothing has to run inside your network

If your Jenkins sits on your own infrastructure behind a firewall, the first question is not what the stage does. It is what has to be let in. So that is where this page starts.

For external testing, and for the application classes — web application, mobile app, API, thick client and secure code review — nothing is required inside your estate. The targets are reached from where anybody else reaches them, and the pipeline stage is the thing that starts a run rather than the thing that performs it. There is one case that is different, and it is different by design: internal network testing, where being on the inside is the entire point of the exercise. For that a deployment is needed, and on-premise and customer-VPC deployments are both available today. Everything else on this page assumes the first case, because that is the case a build pipeline is asking about when it asks this question.

The questions a self-hosted estate asks first

Where each part of this actually sits

Read down the right-hand column. One row puts something inside your network, and it is the row about internal testing.

The questionThe answer for a self-hosted Jenkins
Does anything have to run on the controller? No. The stage is configuration in your Jenkinsfile, running wherever the rest of that pipeline runs. It starts a run against an authorised scope and reads the result back.
Does Jenkins have to be reachable from outside? No inbound route to your controller is required. The stage opens the conversation from your side, which is why a controller nobody outside can reach behaves the same as one they can.
Where does the testing itself run from? From B-52, against the target named in the scope you authorised. On an external or application assessment that is the same position any stranger on the internet occupies, which is the position the assessment is supposed to be taken from.
When is something needed inside the network? For internal network testing, and for that alone. On-premise and customer-VPC deployments are both available today.
This is the one row where the answer changes with the coverage class rather than with the pipeline.
Where do the findings and the evidence sit? In the region you choose: India, the European Union, the United States, or Singapore and the wider Asia-Pacific.
Does any of this test Jenkins itself? A build system a stranger can reach is a perimeter host like any other, and an external assessment works it as one. That is a scoping conversation rather than a stage in a pipeline, because the thing being tested would be the thing running the test.

Does anything have to run on the controller?

The answer for a self-hosted Jenkins
No. The stage is configuration in your Jenkinsfile, running wherever the rest of that pipeline runs. It starts a run against an authorised scope and reads the result back.

Does Jenkins have to be reachable from outside?

The answer for a self-hosted Jenkins
No inbound route to your controller is required. The stage opens the conversation from your side, which is why a controller nobody outside can reach behaves the same as one they can.

Where does the testing itself run from?

The answer for a self-hosted Jenkins
From B-52, against the target named in the scope you authorised. On an external or application assessment that is the same position any stranger on the internet occupies, which is the position the assessment is supposed to be taken from.

When is something needed inside the network?

The answer for a self-hosted Jenkins
For internal network testing, and for that alone. On-premise and customer-VPC deployments are both available today.

This is the one row where the answer changes with the coverage class rather than with the pipeline.

Where do the findings and the evidence sit?

The answer for a self-hosted Jenkins
In the region you choose: India, the European Union, the United States, or Singapore and the wider Asia-Pacific.

Does any of this test Jenkins itself?

The answer for a self-hosted Jenkins
A build system a stranger can reach is a perimeter host like any other, and an external assessment works it as one. That is a scoping conversation rather than a stage in a pipeline, because the thing being tested would be the thing running the test.

Before the first run

What is settled once, and what a stage never decides

A pipeline can start a run. It cannot widen a scope, and it was never given the authority to.

The standing agreement a pipeline run draws on As of 2026-09-14
  • The target, in writing. A stage starts a run inside a scope that was authorised before the stage existed, and nothing outside that scope is touched.
  • The severity threshold that decides a failed build. You set it. It is the one value here that changes what your pipeline does.
  • The delivery model, which decides whose signature the report carries and is a separate question from what gets tested. Coverage is identical across all three.
  • The credential the stage authenticates with, held wherever your organisation already holds its pipeline credentials.
  • One scan is one application or one target. A pipeline that builds three applications is carrying three, and how often each of them runs is one of the three axes a plan is scoped on — the others being the number of targets and the delivery model.

Deliberately excluded

  • Physical, hardware and wireless testing, which are out of scope for the platform in every coverage class.
  • Denial of service, which is not performed against a production system.
  • Anything the scope does not name. A branch that builds a target nobody signed off produces no run.

The shape of it

A stage, a step, a threshold, a result

Four things, in that order. Everything else on this page is a consequence of one of them.

  1. One

    A stage in the Jenkinsfile

    It goes where you want the decision taken — after the artefact is built and reachable at a target the scope names, and before whatever you would rather not run against an application carrying an unfixed critical. In the file it reads like the stages already around it.

  2. Two

    A step that starts the run

    The step carries the target, the credential and the threshold. It starts a run inside the scope that was already authorised, and there is no value it could be given that would widen one.

  3. Three

    A threshold you set

    A severity, backed by the CVSS v4.0 vector every finding carries. At or above it the build fails. Below it the findings still arrive — they simply do not stop the pipeline.

  4. Four

    A build result Jenkins already understands

    The stage sets the result and Jenkins does what it has always done with it. Nothing downstream has to learn a new vocabulary, which is the reason for doing it this way round rather than inventing one.

The values the step carries, and the condition around it

Five decisions, and what each one changes

Named in English rather than as identifiers, because what matters to the decision you are taking is which choices exist, not how they are spelled.

The valueWhat it decides
The target Which application or host the run works. One scan is one application or one target, so a pipeline that builds three of them carries three of these.
The credential How the stage authenticates. It sits where the rest of your pipeline credentials already sit, and it is managed the way they are managed.
The threshold The severity at or above which the build fails. Yours to set, yours to change, and the only value here whose effect the rest of your team will notice.
Whether the build waits Whether the pipeline holds for the result, or starts the run and leaves the decision to a later pipeline reading it. This one is settled at scoping, because a result cannot fail a build it arrives after.
The one turnaround figure we state is an observed median of one to three business days, from scope sign-off to the finished report, in the fully autonomous model. It is an observed median rather than a service level, and it describes an engagement rather than a stage.
The condition it sits behind Ordinary Jenkins conditions — a branch, a tag, a schedule. Cadence is one of the three axes a plan is scoped on, so this condition is a commercial decision as much as a pipeline one.

The target

What it decides
Which application or host the run works. One scan is one application or one target, so a pipeline that builds three of them carries three of these.

The credential

What it decides
How the stage authenticates. It sits where the rest of your pipeline credentials already sit, and it is managed the way they are managed.

The threshold

What it decides
The severity at or above which the build fails. Yours to set, yours to change, and the only value here whose effect the rest of your team will notice.

Whether the build waits

What it decides
Whether the pipeline holds for the result, or starts the run and leaves the decision to a later pipeline reading it. This one is settled at scoping, because a result cannot fail a build it arrives after.

The one turnaround figure we state is an observed median of one to three business days, from scope sign-off to the finished report, in the fully autonomous model. It is an observed median rather than a service level, and it describes an engagement rather than a stage.

The condition it sits behind

What it decides
Ordinary Jenkins conditions — a branch, a tag, a schedule. Cadence is one of the three axes a plan is scoped on, so this condition is a commercial decision as much as a pipeline one.

The result

Where the decision lands in Jenkins’ own vocabulary

Five results, and the stage sets two of them. Your threshold decides which. The rest is Jenkins doing what it does with a failed stage.

Where the decision lands in Jenkins’ own vocabulary
StateWhat it meansWhat follows
SUCCESS Terminal Nothing at or above the threshold you set. Findings below it, where there are any, are reported without stopping anything. The pipeline carries on.
UNSTABLE Findings arrived, none of them at or above your threshold, and you would rather the build page said so. That is your Jenkinsfile deciding what to do with a result it has already been handed, rather than the threshold deciding it. The pipeline carries on, marked.
FAILURE Terminal At least one finding at or above the threshold. This is the reason the stage is in the file at all, and everything else here is arrangement around it. The build stops at this stage.
NOT_BUILT Not something the stage sets. It is what Jenkins shows for the stages behind one that failed, and it is the visible half of a gate having done its job. Nothing downstream runs.
ABORTED The build was stopped from outside it — by a person, a timeout, or a newer run superseding this one. The result the stage would have set is never reached. Decided outside the stage.
Key
  • The threshold was not reached
  • Reported, not stopped
  • The gate fired
  • Set by Jenkins rather than by the stage
  • TerminalNo state follows this one

Where to put it

The same stage, read from three pipelines

The threshold that is right on a release pipeline is the wrong one on a pipeline that runs at every merge, and the reason is cadence rather than risk appetite.

01 At every merge

The pipeline that runs on the change

What the stage is for here
Catching the change that introduced the defect while the person who made it still remembers why they made it.
What the threshold does here
Set high, it stops the pipeline only for the findings nobody would argue about. Set low on a pipeline this frequent, it stops work rather than preventing it.
What it costs to sit here
One scan is one application or one target, so a stage on a high-frequency pipeline is a cadence decision before it is a technical one. Cadence is one of the three axes a plan is scoped on.
02 At release

The pipeline that ships

What the stage is for here
Being the last thing in the file that can say no before an artefact reaches production.
What the threshold does here
This is where a threshold earns its stop. A build that fails here has cost you a deployment window; a build that passed and should not have has cost you something you will be asked about later.
Which result matters here
FAILURE, and the NOT_BUILT stages behind it. A release pipeline is the one place where the downstream stages not running is the whole point rather than a side effect.
03 On a schedule

The nightly or weekly pipeline

What the stage is for here
Running against what is deployed rather than against what was committed — the form a scheduled job has always taken, and the one that fits a Jenkins estate already running work on a timer.
What the threshold does here
Nothing is waiting on this build, so the threshold becomes a reporting decision rather than a stop. A scheduled pipeline can carry no threshold at all and let the findings arrive on their own.
What this pairs with
Continuous assessment, which is the same argument made without a pipeline in it: testing on the cadence the estate changes at rather than on the cadence the audit calendar runs at.

What the engineer sees

Two places, carrying two different things

The build page carries the decision. The finding, and the exchange that proves it, live where a finding can be assigned, argued with and closed.

In Jenkins

The result, and what it was set on

The build result the gate set, and console output saying what produced it: how many findings came back at or above your threshold, and where to read them. That is the half a build page is good at carrying.

In the dashboard

The exchange that proved it

Every finding carries a reproducible exploit artefact — the request as sent, the response as returned, and steps your team can follow without coming back to us to ask what was meant.

In the dashboard

A severity you can recompute

The CVSS v4.0 vector rather than only a label, plus the CWE. Your team can recompute the score against its own environmental metrics, which matters rather a lot when that score is what failed the build.

Across runs

Open, fixed, retested, closed

A finding that failed a build closes on a retest that cannot reproduce it. That is what lets the next run of the same pipeline pass for a reason instead of passing by coincidence.

Before any of it

The sixth phase

Discovery, planning, scanning, exploitation, reporting, then QA — which runs on the finished report before it reaches you. A gate is only worth wiring if what reaches it has already been through that.

The split, and why it is drawn there

A build log is not a report, and should not try to be

The console output is deliberately the smaller half.

A build log is read once, by whoever is waiting on the deployment, and it goes away with the workspace. A finding needs an owner, a status that survives the next build, and the request-and-response exchange that settles the argument about whether it is real — none of which a log can hold. So the stage tells your pipeline exactly what it needs in order to decide, which is the result and what it was set on, and the finding itself stays somewhere it can be assigned, retested and closed. The report at the end of it is produced from the same six phases whichever delivery model you are on; coverage is identical across all three, and what changes between them is whose signature the report carries. That is a scoping decision rather than a pipeline one, and it is taken once rather than on every build.

Where the rest of this is set out

The build gate

What a failing result does to a pipeline, and the threshold you set to decide it.

Continuous assessment

Running on the build that shipped rather than on the audit calendar.

Other pipelines

GitLab CI GitHub Actions Azure DevOps

Wire one stage, against one target, from $500

The entry price is $500, for one scan against one application or one target. A paid trial is $299 — one scan, one target, on the card flow, which covers the application classes: web application, mobile app, API, thick client and secure code review. Anything wider, including the network and cloud classes, is scoped on a call.

Take the $299 trial Scope it with us