Eleven coverage classes and one exclusion
Every class below has its own page, with its own defect classes, its own standards at their current versions, and its own worked example. That is deliberate: an unsupported class in a long list weakens every class beside it.
The classes
Each one, and what it is actually about
Not a list of things we say yes to. Each line is the argument that class's own page is built on, and no two of them are the same argument.
| Coverage class | Where the defects concentrate |
|---|---|
| Web applications | Access control and business logic, worked with a credential for each role. A signature catalogue cannot reach these classes, because every response is well formed. |
| Mobile apps | We take the signed release build exactly as you publish it, obfuscated and certificate pinned, and decompile it without source. |
| APIs | An authorisation matrix written before anything is tested against it, then every route checked against it with a second credential in hand. |
| Thick client | The package you distribute, and the question underneath it: not whether a check inside the client can be removed, but whether the server relied on it. |
| External network | The perimeter worked out from what actually answers, not from the asset list, and handed back as a scope proposal before anything is tested. |
| Internal network | How far a foothold travels, inside a movement boundary you write into the scope before the run starts. |
| Cloud | The identity and permission layer, where cloud findings concentrate. A permission is proved by making the call, not by reading the policy. |
| Active Directory | Privilege paths walked end to end. We report the edges that failed alongside the ones that held. |
| Social engineering | A foothold, obtained under a written authorisation naming the population and the window. The measure is whether it got in. |
| Secure code review | A file, a line, the path that reaches that line, and the change that closes it, written against the idiom your repository already uses. |
| LLM applications | What the application does with the model, not what the model says. Which retrievals it trusts, what it renders, and which tools it can be made to invoke. |
- Where the defects concentrate
- Access control and business logic, worked with a credential for each role. A signature catalogue cannot reach these classes, because every response is well formed.
- Where the defects concentrate
- We take the signed release build exactly as you publish it, obfuscated and certificate pinned, and decompile it without source.
- Where the defects concentrate
- An authorisation matrix written before anything is tested against it, then every route checked against it with a second credential in hand.
- Where the defects concentrate
- The package you distribute, and the question underneath it: not whether a check inside the client can be removed, but whether the server relied on it.
- Where the defects concentrate
- The perimeter worked out from what actually answers, not from the asset list, and handed back as a scope proposal before anything is tested.
- Where the defects concentrate
- How far a foothold travels, inside a movement boundary you write into the scope before the run starts.
- Where the defects concentrate
- The identity and permission layer, where cloud findings concentrate. A permission is proved by making the call, not by reading the policy.
- Where the defects concentrate
- Privilege paths walked end to end. We report the edges that failed alongside the ones that held.
- Where the defects concentrate
- A foothold, obtained under a written authorisation naming the population and the window. The measure is whether it got in.
- Where the defects concentrate
- A file, a line, the path that reaches that line, and the change that closes it, written against the idiom your repository already uses.
- Where the defects concentrate
- What the application does with the model, not what the model says. Which retrievals it trusts, what it renders, and which tools it can be made to invoke.
The exclusion
Physical, hardware and wireless
Out of scope for the platform entirely, in every class, and stated in the same words on every one of the pages above. It is worth saying once in a place a buyer can find it, because a coverage list with no boundary is a coverage list nobody should believe.
Everything else is a scoping question, not a capability one. Where a class needs something from you before it can start (a credential for each role, a deployed position inside the network, a written authorisation naming a population), that requirement is on the class page, in the block that sets out what is fixed before a run begins.
Delivery
All three models cover all of them
The models differ by where the human sits, never by what is tested. What you are choosing is the level of assurance and whose signature the report carries.
| Delivery model | Where the human is | Coverage |
|---|---|---|
| Fully autonomous | A person authorises scope and targets. Nothing after that. | All eleven classes. |
| Autonomous, expert verified | A senior auditor verifies every finding before anything reaches you. | All eleven classes. |
| Human led Terminal | A senior auditor runs the engagement with B-52 underneath. | All eleven classes. |
- No human action after scope sign-off
- An empanelled auditor is inside the engagement
- TerminalNo state follows this one
Where the report has to go into a regulated filing, the choice narrows: Security Brigade signs under its CERT-In empanelment, and the auditor who signs has to have been inside the engagement. The delivery models page sets out which one answers which need.
One scan is one application or target, from $500
Request a $299 trial or a $500 single-target scan. We’ll confirm the scope and authorisation before testing begins. Where the estate is larger than one target, or the report has to carry a signature, a scoping call settles it faster than a form.