A task in azure-pipelines.yml, pointed at the deployment the stage before it produced. It returns a result the pipeline understands — succeed, or fail the step on a severity threshold you set — and every finding it proved is written up with the request and response that proved it before anyone opens the failed run.
The first question
Asked before anything about task inputs, so it is answered before anything about task inputs.
A run started from a pipeline leaves its output in three places, and they are not interchangeable. The pipeline run carries the decision: the task compares what was proved against the severity threshold you set, and returns a pass or a failure — which is the only part Azure DevOps itself acts on. The run also carries the summary: what the step found, counted by severity, written into the step log and kept with the run so it is still readable long after the agent is gone. And the finding itself lives in the B-52 dashboard — the request as sent, the response as returned, the steps that reproduce it, the severity with its CVSS v4.0 vector and the CWE — where it moves through open, fixed, retested and closed. Raising the work item is your side of the line. Everything a Boards item needs is already written; which project, which area path and which iteration it belongs to is a decision about your backlog rather than ours, and we would be guessing at it.
After the run
Three outputs from one run. Each has a different reader and a different shelf life.
| Output | Where it sits | Who reads it |
|---|---|---|
| The step result | The pipeline run. It is a pass or a failure and nothing else, because that is the whole vocabulary a pipeline has for acting on something. | The engineer whose commit started the run. |
| This is also what a branch policy reads, where the pipeline is set as build validation on the branch. | ||
| The summary in the log | The step log inside the run — what was proved, counted by severity, and the threshold that was applied to it. | Whoever opens the failed run first. |
| The finding record | The B-52 dashboard | The person who has to fix it. |
| The exchange that proved it travels with the record, so the fix does not start with a reproduction attempt. | ||
The step result
This is also what a branch policy reads, where the pipeline is set as build validation on the branch.
The summary in the log
The finding record
The exchange that proved it travels with the record, so the fix does not start with a reproduction attempt.
Finding states
The same vocabulary whether the run was started by a pipeline, by a schedule, or by hand. A pipeline does not get its own status words.
| State | What it means | What follows |
|---|---|---|
| Open | Proved during the run and written up. It arrives in this state, with the request, the response and the reproduction steps already attached. | Counts against the threshold on the run that found it. |
| Fixed | Your team has changed something and marked it done. Nothing has been re-run against the change yet, so nothing has been established. | Waits for a retest. |
| Retested | The reproduction steps have been run again against the changed target. This is the state a finding sits in while that is being settled. | Goes to closed, or back to open. |
| Closed Terminal | The retest could not reproduce it. A finding closes on that and on nothing else — not on an assertion, not on a sprint ending. | Terminal. It is the evidence that remediation held. |
Placement
The placement decides what gets tested. B-52 works a running deployment, so the step has to sit after one exists.
Stage one
Your existing build stage runs exactly as it does today. Nothing here changes, and the task has no opinion about how the artefact was produced.
Stage two
A review environment, a staging slot, or the environment the release is heading for. The target is a deployment rather than a repository — source is its own coverage class, scoped separately.
Stage three
One task, in its own job or beside the smoke tests. It is told what to test, what to test it as, the severity that fails the step, and what the pipeline should do while the run is open.
Stage three, continued
The task holds no view about which severity should stop a release. It compares what the run proved against the value you set and returns the corresponding result.
Stage four
A failed step fails its job, the job fails the stage, and the stage does not hand over to what comes after it. Approvals and checks you already have on the next environment are untouched.
Task inputs
Named here for what they decide rather than by their spelling in the file, because what they decide is the part that survives.
| Input | What it decides | Where the value comes from |
|---|---|---|
| The target | The address the run works against — the deployment the previous stage produced, resolved at run time so a review environment can be tested at the address it was given this time. | The pipeline, usually as an output variable from the deploy stage. |
| The credential set | What the run authenticates as, so it reaches what a signed-in user reaches rather than only the surface a stranger sees. One credential per role where the scope names roles. | A variable group or a secret variable. It is never written into the file. |
| The severity threshold | The severity at or above which a proved finding fails the step. Below it, the finding is still reported and the step still succeeds. | You. It lives on the task, so changing it is a commit with an author and a date. |
| The threshold and the failure behaviour work identically in all four pipelines — the build gate page sets that out once. | ||
| What the pipeline does while the run is open | Whether the stage holds until the run returns a result, or records the run and lets a later stage read it. A run against one application can hold a stage; a full assessment of a large target is not a thing to keep an agent waiting on. | Agreed with the scope, because it depends on what is being tested. |
| In the fully autonomous model the observed median from scope sign-off to report is one to three business days. That is an observed median, not a service level. | ||
The target
The credential set
The severity threshold
The threshold and the failure behaviour work identically in all four pipelines — the build gate page sets that out once.
What the pipeline does while the run is open
In the fully autonomous model the observed median from scope sign-off to report is one to three business days. That is an observed median, not a service level.
The gate
The same result, as each of the three people who meet it experiences it.
The threshold
A gate that somebody else calibrated is a gate that gets switched off in its second week. So the threshold is a task input and the task does exactly one thing with it: it compares. Set it so that only a proved critical stops a release and the step will fail rarely and mean something when it does. Set it at medium and the pipeline becomes the place your severity policy is actually enforced. The value can also differ by stage — strict on the review environment, looser on the release stage, or the reverse — because each stage carries its own task with its own input. What the threshold never does is change the test. Everything the run proved is reported at every severity; the threshold decides only which of it is allowed to stop a pipeline, and a finding below the line is a finding in your dashboard rather than a finding you were not told about.
Before the first run
A pipeline can start a run. It cannot widen one, and the scope it runs inside was settled before the first commit that triggered it.
Deliberately excluded
Next to this
The run reaches the target the way anyone else on the internet would, so external and application scopes need no deployment on your side. Internal network testing is the single exception.
Where the pipeline ends at an Azure subscription, the subscription is a different coverage class from the application inside it — identity and role assignments, storage exposure, and the services the deployment sits on.
What decides the signatureAll three models cover all eleven coverage classes and test the same way. What differs is whose signature the report carries, and that is chosen at scoping rather than in a YAML file.
One scan is one application or target. The card flow covers web applications, mobile apps, APIs, thick clients and secure code review, with a paid trial at $299 for one scan on one target. Cloud, network and Active Directory scopes start with a scoping call.