Skip to content
Contact us

Home / CybeRapid

How an engagement actually runs

Inside a test:
what the machine does, and what the engineer does.

The useful question about any security platform is not what it can find. It is where the tool stops and the judgement starts — because that line is where the findings that matter are either caught or missed. Here is ours, stated plainly enough to argue with.

See the catalogueBook a scoping call

The division of labour

The platform never has the last word

Read the right-hand column first. It is the part you are actually buying, and the left-hand column exists so that there is more of it.

What CybeRapid does

  • Maps the surface: routes, parameters, roles, tenants and the calls a client actually makes — so nothing is tested only because it was easy to find.
  • Runs the deterministic checks end to end, every time, against the published catalogue rather than against whatever the tester remembered that week.
  • Captures the evidence as it goes: the request, the response, the state before and after. Nothing is reconstructed from memory afterwards.
  • Keeps the state of the engagement — what is covered, what is open, what is waiting on a retest — so a second round starts where the first stopped.
  • Drafts. Every finding arrives as a draft with its evidence attached, which is not the same thing as a finding.

What the engineer does

  • Decides what the application is supposed to allow. No tool knows that, and almost every serious finding we report turns on it.
  • Confirms or discards every candidate. A draft becomes a finding only when a person has reproduced it and judged it exploitable in your system.
  • Chains. Two findings that are each unremarkable are frequently one that is not, and recognising that is judgement rather than coverage.
  • Rates it. Severity is an argument about your business, not a CVSS vector pasted from a database.
  • Writes it for the person who has to fix it, and stands behind it in the debrief.

Provenance

The trail behind a finding

A finding that cannot be traced back to the thing that produced it is an opinion. Each step below is recorded as it happens.

1

Surface

A route, parameter or object that exists and is reachable.

2

Hypothesis

A specific claim about how it could be abused, worth testing.

3

Attempt

The requests actually sent, with the responses actually returned.

4

Evidence

What proves it — captured at the moment, not rebuilt later.

5

Finding

Only after a person has reproduced it and judged it exploitable.

Every finding in your report can be walked back along this chain.

This matters for a reason that only shows up later: when your developer disagrees with a finding — and they should, sometimes — the argument is settled by the captured request and response, not by whose memory is better six weeks after the test.

Where the depth shows

The honest comparison

Vendors in this category tend to argue that tools find nothing. That is not true, and claiming it makes everything after it suspect.

What a scanner does find

  • Nearly all of the top of our own most-common list: content security policy, strict transport security, outdated components, information disclosure through errors and headers, TLS configuration.
  • These are real findings and they belong in the report. We are not going to pretend a tool cannot see them — it can, and it should.
  • If that is all you need, a scanner is cheaper than us and you should buy one.

What it structurally cannot

  • Authorization. Nothing about the request is malformed — it is a valid user asking a valid question about somebody else’s data. A scanner has no way to know that is wrong.
  • Among the high and critical findings we report, authorization is the largest single class: 173 against 128 for every variety of cross-site scripting combined.
  • Business logic, tenant isolation, and workflows abused in the order they were never meant to run in. All of it requires understanding what the application is for.

Broken authorization: the finding that matters mostWhat 890 engagements found

Coverage

You can read the test plan before you buy the test

The catalogue is public: 276 named test cases across web, API, Android, iOS, cloud and AI-backed systems, each stating what it proves and how it is carried out. It is what the engagement is run against, and it is the same document whether we are testing a two-page marketing site or a multi-tenant platform — the depth changes, the coverage question does not.

Open the catalogueCoverage matrix

The fastest way to judge this is to make us scope your system.

Tell us what it does and what worries you. If a scanner would answer your question, we will say so.

Book a scoping callSee the workspace