You grant access to the repository and B-52 reads it directly, across the languages that are in it. What comes back is a file, a line, the path an attacker would take to reach that line, and the change that closes it — written against the framework your codebase already uses. The code is deleted after thirty days of inactivity.
What lands in the ticket
The reason a code review gets ignored is almost never that it found nothing. It is that what it found arrived in a shape nobody could act on.
Where the defect is, in the branch you nominated, at the commit you nominated it at. Not a rule identifier and a list of candidate locations to go and check.
How something an attacker controls reaches that line: which parameter, through which functions, past which checks. The path is what tells your engineer whether this is reachable at all.
Written against the framework and the idiom the repository already uses, rather than a generic remediation paragraph that has to be translated before it can be applied.
When the deployed system is inside the same engagement, the finding carries the request and the response that reach the line as well as the line itself. Where it is not, the path is established in the code and the finding says so.
Severity with its CVSS v4.0 vector, the CWE, and the ASVS requirement the defect fails.
Why the path is carried
A defect on a line that nothing can reach is a code-quality note. The same defect on a line that a request parameter reaches is the reason the review was commissioned — and nothing about the line itself tells the two apart. Establishing which of the two you are looking at is the judgement that turns a static result into a security finding, and it is the judgement a rule set cannot make, because it needs to know what the application is for. That is why every finding here carries the path, and why one whose path could not be established is reported as what it is rather than at the severity a path would have justified.
Class and boundary
Access to the repository is granted by you. Language coverage is broad, and the review is worked against a named branch or tag rather than against whatever moved since.
Application source across the languages present in it, the dependency manifests and what they resolve to, the configuration, and the build and deployment definitions that sit alongside them.
What the code does when it is deployed and reachable is the web application class, or the API class where the interface is the product. The two answer different questions and are strongest in one engagement: the review says why, the assessment says whether.
A build already holds the source at the commit that matters. B-52 runs in the pipeline and a result can fail a build against a severity threshold you set, which is the same work at the moment it is cheapest to act on.
Out of scope for the platform entirely, in every class. It is the only exclusion, and it is stated the same way everywhere on this site.
Who this page is for
Both are answered here. Where they should start is not the same.
By phase
The phase names are the platform’s. What enters and leaves each of them on this class is what makes a review different from a scan of the same repository.
| Phase | What enters | What leaves |
|---|---|---|
| Discovery | Read access to the repository, and the branch or tag you nominate. | The languages, frameworks, entry points and dependency surface actually present — read from the repository rather than from a description of it that may be a release behind. |
| Planning | The surface discovery found. | A review plan written for this codebase: which entry points, which trust boundaries, which flows. A payments service and a content service are never handed the same list. |
| Scanning | The source, in full. | Candidates. Nothing leaves this phase as a finding, and nothing is reported from it. |
| Exploitation | A candidate, and the path that would have to reach it. | A finding where the path holds, a drop where it does not. Where the deployed system is in the same engagement, the path is walked rather than argued. |
| Reporting | Confirmed findings. | File, line, path and the change that closes it, landing in your dashboard as each is confirmed. |
| QA | The finished report. | A gate that can send it back to reporting before you see it. It is where a code-quality note is separated from a security finding. |
Discovery
Planning
Scanning
Exploitation
Reporting
QA
On the code itself
Access is granted by you, to the repository and the branch you nominate. The code is held while the engagement is active and deleted after thirty days of inactivity — a rule tied to the work stopping rather than to a calendar, so a review that pauses while a fix is written does not lose the material it was working from partway through. Where the review runs inside your own pipeline the source never leaves it at all, which is why this class pairs with the pipeline integration rather than sitting beside it: the code is already there, at the commit that matters, at the moment acting on a finding is cheapest.
The boundary
Three actions need written approval on every coverage class. On this one the interesting row is the third, because a repository hands you things that are tempting to test.
| State | What it means | What follows |
|---|---|---|
| Writing anything to your repository | Nothing is committed, branched, or opened as a pull request. A review reads. Where you want fixes proposed as changes, that is asked for in writing and scoped as its own thing. | Stops and waits, in writing. |
| Using a credential found in the code | A key, token or connection string committed to the repository is reported as a finding on the evidence of the commit. Establishing whether it still works means using it somewhere. | Stops and waits, in writing. |
| Walking a path against the running system | Where the deployed system is inside the same engagement, the path from input to line is proved rather than argued — bound by that system’s own authorised scope, not by this one. | Runs inside the assessment scope you authorised. |
| Everything else inside the access you granted Terminal | Reading and analysing the source, the manifests, the configuration and the build definitions; generating the review plan; working it through; reporting. | Runs without asking. |
Why the second row matters
A credential committed to a repository is a finding you can quote: it is in the file, and the file is in the history. Establishing whether it still works is a different act — it means using it against a live system, and that carries a different authorisation. B-52 reports the credential and where it was committed, and goes no further unless you have said in writing that it may. The distinction matters because the two look like one step from a distance, and the second one is the step that puts somebody else’s data in the report.
What the review reaches
Every row below is something visible in the code and difficult or impossible to provoke from outside it. That is the argument for reading the source at all.
| Class | Why the source is where it is visible |
|---|---|
| Authorisation logic, as written | Whether the check exists at all, on each path, rather than whether one role reached one record during a timeboxed test. Source is the only place the absence of a check is visible as an absence. |
| Cryptographic use | Mode, key derivation, initialisation vectors, and whether the key is in the repository. A running system presents a ciphertext; the source presents the decision that produced it. |
| Injection at the point of construction | Every place a query, a command, a path or a template is assembled — including the ones behind a code path no external test ever triggered. |
| Secrets committed to the repository | Keys, tokens and connection strings in source, configuration and build definitions. Nothing has to be exploited for these to be facts. |
| The dependency surface, as resolved | What the manifests actually pull in at the versions they resolve to, including the transitive ones nobody chose and nobody has looked at. |
| Error and exception handling | What a failure discloses, and what it leaves half-finished. Both are far easier to read in source than to provoke reliably from outside. |
| Order of operations in a flow | Whether the sequence the code enforces is the sequence the flow requires, and what the code does when a step arrives out of it. |
Authorisation logic, as written
Cryptographic use
Injection at the point of construction
Secrets committed to the repository
The dependency surface, as resolved
Error and exception handling
Order of operations in a flow
Three of them, read twice
Each of these is either invisible or ambiguous from a running system, and unambiguous in the code.
Methodology
Each cited at the version current on the date beside it. On this class the reader is frequently an engineer who already knows these documents, which is the reason the versions are printed.
| Standard | Version | What it carries here |
|---|---|---|
| OWASP ASVS | 5.0.0, May 2025. 17 categories | The verification requirement a finding fails, and the level the review is agreed against at scoping. |
| The first major release in six years; 4.0.3 is superseded. | ||
| OWASP Top 10 | 2025 edition | The category each finding is reported under, so a report reads the same way as the assessment of the running system. |
| Superseded the 2021 edition in January 2026. | ||
| CWE | Current | The weakness identifier on every finding, so one defect can be followed across tools that otherwise agree about nothing. |
| CVSS | v4.0, November 2023. Read 2026-09-13 | The severity vector, so your team can recompute the score against its own environmental metrics instead of taking ours. |
OWASP ASVS
The first major release in six years; 4.0.3 is superseded.
OWASP Top 10
Superseded the 2021 edition in January 2026.
CWE
CVSS
Before a review starts
Deliberately excluded
Where this sits
No vendor is named here — these are categories of work. Two of the four run on every push already, and this class is not a replacement for either.
| Static analysis on commit | Dependency scanning | A human code audit | B-52 | |
|---|---|---|---|---|
| What it works from | A rule set, applied to every path it can see. | A manifest and a vulnerability database. | An auditor reading, for the days that were bought. | A review plan written from what this repository turns out to be. |
| Coverage of the repository | Complete, against its own rules. | Complete, against what is declared. | Sampled to fit the timebox. | The generated plan worked through in full. |
| Reachability of a finding | Partial, and it is where the noise comes from. | Not attempted; the version is the claim. | Yes, by judgement. | Established per finding, and walked where the running system is in scope. |
| What a finding costs you to confirm | Triage, which is why the queue stopped being opened. | Little. The resolved version is the fact. | Usually nothing; it was read and understood. | Nothing. File, line, path and the change that closes it. |
| Cadence | Every commit. | Every commit. | When it is scheduled and staffed. | Every build, or the interval you set. |
| Whose signature it carries | None. | None. | The firm that ran it. | Security Brigade’s, in the two models with an empanelled auditor in them. |
What it works from
Coverage of the repository
Reachability of a finding
What a finding costs you to confirm
Cadence
Whose signature it carries
On the analyser you already run
A static analyser on every commit is the right instrument for catching a regression in the minute somebody writes it, and nothing here replaces that. What it cannot do is decide which of its own results matter, because that decision needs to know what the application is for and what an attacker can actually reach. Making that decision is the work that produces the queue nobody opens — and it is exactly the work this class exists to do properly, once, against a named commit.
Filing
Coverage is identical across the three delivery models. What changes between them is whose signature the report carries.
Bespoke and custom software is reviewed prior to release into production, to identify and correct potential coding vulnerabilities. A review tied to a named commit inside the pipeline is the shape that requirement is written around. Requirement text read 2026-09-13.
Where an obligation asks for review before release, the evidence is stronger when the review is the gate rather than a document filed beside it. B-52 runs in the pipeline and can fail a build on a severity threshold you set.
Each finding carries through open, fixed, retested and closed, and closes on a retest against the commit that claims to fix it.
Where the report goes to a regulator or an assessor, start with the expert-verified model.
Worked example
Four steps. The first is a line a reviewer might mark as a code-quality issue; the fourth is why the review was worth commissioning.
| Link | Alone | In sequence |
|---|---|---|
| 1 A constant in a file | A key, written into the configuration. | It is the key the application encrypts with. |
| 2 The same constant in what ships | A string inside a built artefact. | Everyone who downloads the client already holds it. |
| 3 What the key was protecting | A field the application treats as opaque. | Readable, and writable, by anybody holding the key. |
| 4 The request that follows | A well-formed request. | Composed rather than intercepted, and the server has nothing to tell it apart by. |
Measured
B-52 and Security Brigade’s expert assessment team were run against the same targets in parallel, and their findings pooled into one set with each item counted once. B-52 reached 90–95% of that set. Part of what it reached the team had not, which is why the pooled set is larger than either side’s own output — and why the expert-verified model is the honest recommendation wherever the stakes justify paying for both.
One scan is one application or target, and the entry tier is $500. Where the repository holds more than one application, or the report has to carry a signature, a scoping call settles it faster than a form.