B-52 maps the target, generates the test cases that target needs, works them through, proves what it finds, writes the report, and then puts that report through a quality gate that can send it back.
It can do that because of what it was built from. Security Brigade audits going back to 2006 sit inside it, and the harness runs the same practices our senior auditors run.
What it was built from
An autonomous tester is only as good as the practice it learned from. Ours learned from Security Brigade’s.
Where it starts
Security Brigade has been CERT-In empanelled since 2008, and every engagement the firm has run since it started in 2006 was worked inside Lemon, our own assessment platform, so the reasoning behind each finding stayed in one place instead of leaving with the auditor who wrote it.
What was trained on
That is the corpus behind our models: the checks our auditors ran, what those checks found, and the threat models they were derived from. Lemon holds the count.
What the harness does
Mindmap creation, test-case generation, comprehensive JavaScript analysis and functional flow analysis. These are the four practices a Security Brigade auditor works through on an application assessment, and the harness was written to run them rather than to run a check list.
What autonomy adds
The generated test set is worked through in full rather than sampled to fit a timebox. The same practices run the same way on every target. And a run can happen on the cadence your releases actually ship at.
These are not stages of a pipeline. They are the four things a Security Brigade auditor does on an application assessment, and each one produces something the next depends on.
| Auditor practice | What it produces on a run |
|---|---|
| Mindmap creation | A map of the target as it actually is: entry points, roles, the paths between them, and the places where one role can reach another role’s data. |
| Test-case generation | The checks this particular application needs, derived from what the application does, rather than a generic list applied to whatever is in front of it. |
| Comprehensive JavaScript analysis | The client-side routes, parameters and endpoints the interface itself never links to. Anything reachable but unlinked is where an assessment that only follows links stops. |
| Functional flow analysis | The business logic: multi-step flows, the state they carry, and what happens when the steps are taken out of order or by the wrong role. |
The auditor practices the B-52 harness reproduces
Mindmap creation
Test-case generation
Comprehensive JavaScript analysis
Functional flow analysis
What happens on a run
Discovery, planning, scanning, exploitation, reporting, QA. Read the middle two carefully: they are separate phases. Scanning produces candidates and exploitation either proves one or drops it, so nothing that reaches the report arrived on a scanner’s say-so.
| Phase | What enters it | What leaves it |
|---|---|---|
| Discovery | The scope you authorised, and nothing outside it. | The surface as it stands today: hosts, applications, endpoints and the roles that reach them. |
| Planning | That surface. | A mindmap of the target and the generated test cases this application needs. |
| Scanning | The planned test cases. | Candidates. Nothing that leaves this phase is a finding yet. |
| Exploitation | Those candidates. | Proof, or the candidate is dropped. What survives carries the request, the response and the steps that reproduce it. |
| Reporting | The proven findings. | The report, and the same findings in your dashboard with their evidence attached. |
| QA | The finished report. | A report that stands, or findings sent back to the phase that produced them. |
| QA is the sixth phase and it sits after reporting. A quality gate placed mid-pipeline can only stop work that is still in progress; one placed after reporting can return a report that has already been written. | ||
The six phases, with what enters and what leaves each one
Discovery
Planning
Scanning
Exploitation
Reporting
QA
QA is the sixth phase and it sits after reporting. A quality gate placed mid-pipeline can only stop work that is still in progress; one placed after reporting can return a report that has already been written.
Putting QA last is the unusual choice and it is the deliberate one. A gate that runs mid-pipeline can only hold work back; a gate that runs after reporting can pull the finished report apart and send the parts back to the phase that produced them.
Where the human is
Three delivery models. They differ only by where the human sits. All three test the same eleven classes, so the choice is about the assurance you need and who has to sign it, and never about what gets looked at.
| Delivery model | Where the human is | What you can file it as |
|---|---|---|
| Fully autonomous | A person authorises the scope and the targets. After that, nobody acts. B-52 tests, chains, validates and delivers the report. | Not signable under Security Brigade’s CERT-In empanelment. |
| Autonomous, expert verified | A senior auditor verifies every finding before anything reaches you. | Signable under Security Brigade’s CERT-In empanelment. |
| Human led | A senior auditor runs the engagement with B-52 underneath. | Signable under Security Brigade’s CERT-In empanelment. |
If the assessment is going to a regulator, take the expert-verified or human-led model. The empanelled auditor’s involvement is what makes the output signable, and CERT-In empanelment is a condition of the testing itself, not only of the vendor who sells it. That is worth settling before you scope.
Once persistence is approved for a scope, B-52 establishes it. There is no point in the run where a human operator takes over to do the part that needs a person, because that part is in the platform too.
Everything above the three gates runs without asking. Everything at them stops until you have said yes in writing.
What comes out
The request, the response, and the steps that reproduce it. In all three delivery models, without exception — a finding your engineers cannot reproduce still costs them a week to chase.
In the fully autonomous model, findings additionally pass an independent automated cross-check before they are reported. The exploit is what makes a finding verifiable; the cross-check is a second gate sitting on top of it.
The benchmark that mattered to us was not a public leaderboard. It was running B-52 in parallel with the Security Brigade assessors it was built from, on the same targets, and counting what each of them found.
Comparable coverage, different blind spots. That is also the honest case for the expert-verified model: the platform and the auditor together find more than either does alone.
Where you read it
Your team works in the same place the run reports into. There is no separate portal, and no PDF to wait for.
What it can be pointed at
A list of eleven names proves nothing. Each of these opens onto what B-52 does in that class, which methodology it works to, and what it needs from you to start.
Physical security, hardware and wireless testing are out of scope. That is the only exclusion, and it is stated here so you can price the gap rather than discover it.
The ladder starts at $500 and every tier on it is published. You can sign up and run the first scan with a card, or bring us a scope and we will size it with you.