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.

See pricing for your application 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; it is not 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 question	The 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 and not 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 instead of 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 and not 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 instead of 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.

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.
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.
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.
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 instead of inventing one.

The values the step carries, and the condition around it

Five decisions, and what each one changes

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

The value	What 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 and not a service level, and it describes an engagement, not 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 and not a service level, and it describes an engagement, not 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
State	What it means	What 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. The threshold did not decide 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, not 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, not 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 instead of 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 and not a side effect.

03 On a schedule

The nightly or weekly pipeline

What the stage is for here: Running against what is deployed instead of 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 and not 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 instead of 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, not 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, not a pipeline one, and it is taken once.

FAQ

Common questions

Still deciding whether this is the right test? Ask us directly.

Talk to an engineer

Does anything have to run inside our network?+

Not for external testing, and not for the application classes: web application, mobile app, API, thick client and secure code review. A deployment inside your estate is needed for internal network testing, and for that both on-premise and customer-VPC deployments are available.

Our controller has no inbound route from the internet. Does the stage still work?+

Yes. Nothing calls in to your Jenkins. The stage opens the conversation from your side, against a target and a scope authorised beforehand, and reads the result back the same way.

Can a result actually fail a Jenkins build?+

Yes, on a severity threshold you set. At or above it the stage sets FAILURE and the stages behind it do not run. Below it the findings still arrive; they simply do not stop the pipeline.

Will the build wait for the run to finish?+

That 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 never a service level, and it is measured across an engagement, not a stage.

Is a report from a pipeline run different from one we commission directly?+

No. The same six phases run: discovery, planning, scanning, exploitation, reporting, and QA on the finished report before it reaches you. The delivery model decides whose signature the report carries. The pipeline only decides when the run starts.

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, not on the audit calendar.

GitLab CI GitHub Actions Azure DevOps

Wire one stage, against one target

Connect B-52 testing to your development workflow. Pricing depends on the assessment target, scope and frequency.