Search is unavailable right now. Try again in a moment.
B-52 runs as a step in the pipeline you already have (GitLab CI, GitHub Actions, Jenkins or Azure DevOps) against the release that step has just produced. A finding at or above a severity threshold you set fails the build; everything below it is recorded and the pipeline carries on.
Two triggers
The same six phases run either way, ending in the QA gate that reads the report before you do, and every finding carries the same reproducible exploit artefact. What changes is what the run is looking at and what its result is allowed to do next.
A report cannot stop a deployment. A failed step can. That is the whole distance between the two panels above, and it is why CI/CD security testing is bought as a different thing from the assessment that gets filed: one is read by a person, the other is read by the pipeline that asked for it.
Neither answer removes the need for the other. Continuous assessment sets out the standing cadence, which is the third trigger and the one that covers the interval between releases as well as the interval between engagements.
The pipelines
Each is in production with customers, and each has its own page: where the step sits in that system’s vocabulary, the parameter that carries the threshold, and what the engineer sees when a build goes red.
| CI system | What the step is, in that pipeline |
|---|---|
| GitLab CI | A job in the pipeline definition, in whichever stage you decide it belongs to: after the one that builds the artefact, or before the one that ships it. |
| GitHub Actions | A step in a workflow, on the events you already build from: a push, a pull request, a tagged release. |
| Jenkins | A stage in the Jenkinsfile, running on the agent and with the credentials the rest of that pipeline already uses. |
| Azure DevOps | A task in the pipeline definition, inside the stage whose result decides whether a release moves on to the next environment. |
The wiring differs because the systems differ. What does not differ is the run behind it: the same phases, the same evidence on every finding, and the same threshold parameter deciding what a result does to your build.
The gate
The severity at which a result stops a build is a parameter on the step, and the value in it is yours. A team wiring this for the first time can put the step where nothing waits on it and watch what it would have failed, then move it once the answer is boring.
| The result against your threshold | What the step does | What the pipeline does |
|---|---|---|
| Below your threshold | The finding is recorded against the run with its request, its response and the steps that reproduce it, its CVSS v4.0 vector and its CWE. | The pipeline carries on. |
| At or above your threshold | The step returns a failure to the pipeline. | The build fails at the point you placed the step, and what comes after it does not run. |
Where you place the step decides what is waiting on it. Before the deployment stage, a failure holds the release. After it, the same failure is a signal and not a stop. That placement is a decision about your own delivery process, and it is not one we make for you. The build gate goes through it in full.
Nothing is deployed inside your network for external and application testing, so a pipeline step needs no position on your estate to reach the target it was scoped against. Internal testing does need a deployed position, and it is scoped as its own engagement, not wired to a build. The coverage classes page says which is which.
The other direction
A build gate only ever sees the applications that go through a build you control. The estate also contains the subdomain a contractor stood up, the staging host that was never taken down, and the acquisition nobody has inventoried yet. ShadowMap discovers those, and B-52 tests what it finds.
That is one direction only, and the two are subscribed to separately: B-52 is not a ShadowMap module and does not sit inside a ShadowMap licence. How the two work together sets out the boundary and what crosses it.
Connect B-52 testing to your development workflow. Pricing depends on the assessment target, scope and frequency. B-52 accepts single-target assessment requests for web applications, mobile apps, APIs, thick clients and secure code review, and we’ll confirm the scope and authorisation before testing begins. Where the class sits outside those five, an estate is larger than one target, or the report has to carry a signature, a scoping call settles it faster than a form does.