What reaches an attacker is the signed release build: obfuscated, certificate pinned and defended at runtime. That is what B-52 takes. It decompiles the APK and the IPA itself and runs static and dynamic analysis across both platforms, with no source supplied.
The build as published
No debug build, no unobfuscated build, and you do not have to turn off certificate pinning first. B-52 takes the binary exactly as your users download it.
B-52 decompiles and analyses the APK and the IPA itself. Static and dynamic analysis run across both platforms and neither needs source. Certificate pinning and the runtime protections around it are handled inside the run. Your engineering team is not asked to strip them first.
Hardening, one defence at a time
Three defences decide whether a mobile test produces findings or a list of things that could not be reached.
Class and boundary
What sits inside this class, and which class the work next to it belongs to.
This class is the mobile client as published: the Android and iOS binaries, what they hold, and how they behave at runtime on the device. The backend the application calls is the API class. The hosts that serve it are the external network class. B-52 covers all three, and they are separate scopes, because one scan is one application or target.
The boundary
The interface behind the app is the API class, worked against its own routes with a credential for each role. A mobile assessment reports what the client sends; the API assessment reports what the server accepts.
AdjacentThe addresses, names and services the application reaches over the internet are the external network class — including the ones the app talks to that never appeared on anybody’s asset list.
AdjacentThis class works the published build and needs no source. Reading the repository is a separate class with its own scope, and the two answer different halves of the same question.
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 is for
By phase
Discovery against a binary is not discovery against a domain. These are the platform phases with what enters and what leaves each one on this class.
| Phase | What enters | What leaves |
|---|---|---|
| Discovery | The release build as published: an APK on Android, an IPA on iOS. | A decompiled binary, analysed by the platform itself. |
| Planning | The scope: one application or target. | A scope authorised in writing. In the fully autonomous model this is the last human action of the engagement. |
| Scanning | The decompiled build, on both platforms. | Static and dynamic analysis, with no source supplied. |
| Exploitation | A hardened build: obfuscation, certificate pinning, runtime protections. | Pinning and runtime protections handled, RASP bypassed, and the behaviour underneath observed. |
| The block above sets out what happens to each of the three defences. | ||
| Reporting | A confirmed finding. | A reproducible exploit artefact: request, response and steps to reproduce. |
| QA | The delivered report. | QA sits after reporting, so the quality gate is the last phase and not a step in the middle. |
Discovery
Planning
Scanning
Exploitation
The block above sets out what happens to each of the three defences.
Reporting
QA
The autonomy boundary
The models differ by where the human sits, never by what is tested. So you choose a model for the level of assurance you need. Mobile is included in all three.
| State | What it means | What follows |
|---|---|---|
| Fully autonomous | A person authorises scope and targets. Nothing after that. | Findings pass an independent automated cross-check before they are reported. |
| Autonomous, expert verified | A senior auditor verifies every finding before anything reaches you. | Signable under the Security Brigade CERT-In empanelment. |
| Human led Terminal | A senior auditor runs the engagement with B-52 underneath. | Signable under the Security Brigade CERT-In empanelment. |
Written approval
Anything that alters production state waits for your written approval before the run performs it.
Persistence is performed by the platform itself, within authorised scope, and only once that authorisation exists.
On a mobile scope that includes a real account inside the application under test.
Methodology
A standard cited at a stale version is a dated-content signal, and this is the reader who checks.
| Standard | Version, read 2026-09-08 | What it carries here |
|---|---|---|
| OWASP MASVS | v2.1.0, eight categories, 24 controls | The verification requirements a mobile finding is mapped to. |
| v2.1.0 added MASVS-PRIVACY. Read 2026-09-08. | ||
| OWASP MASTG | v2.0.0 | The test procedures behind those requirements, cited as specific tests and not as a guide. |
| The first stable non-beta release of the v2 refactor. Read 2026-09-08. | ||
| OWASP MASWE | Current, mapped to both MASVS and MASTG | The weakness enumeration, and where the MAS Testing Profiles live. |
| Read 2026-09-08. | ||
OWASP MASVS
v2.1.0 added MASVS-PRIVACY. Read 2026-09-08.
OWASP MASTG
The first stable non-beta release of the v2 refactor. Read 2026-09-08.
OWASP MASWE
Read 2026-09-08.
Coverage in MASVS terms
What a finding carries
Request, response and the steps to reproduce, on every finding, in all three delivery models.
A separate validation pass confirms a finding before it is reported. It sits on top of the exploit artefact, not in place of it.
All three delivery models cover this class. What changes between them is where the human sits.
Against the alternatives
Read from each vendor platform page on 8 September 2026. Where a competitor does sell mobile, the row says how they deliver it.
| Platform | Mobile claim, read 2026-09-08 |
|---|---|
| Cobalt | Mobile is a scoped human-delivered asset type. The autonomous product is web only. |
| Conceded: they do sell mobile, with people. Read 2026-09-08. | |
| Astra | Mobile application scanning appears in the coverage list. |
| Conceded: mobile is in their range, as scanning and not autonomous binary analysis. Read 2026-09-08. | |
| Pentera | No mobile claim on the platform page. |
| Web application testing was announced 29 July 2026, in beta with general availability scheduled for Q4 2026. Mobile is not part of it. Read 2026-09-08. | |
| Horizon3 / NodeZero | No mobile claim on the platform page. |
| Read 2026-09-08. | |
| XBOW | Web applications and their APIs. |
| Read 2026-09-08. | |
| Ridge Security | No mobile claim on the RidgeBot page. |
| Read 2026-09-08. | |
| Vonahi | Network only. |
| Read 2026-09-08. | |
| B-52 | Decompiles and analyses the APK and the IPA itself. Static and dynamic, both platforms, no source. |
Cobalt
Conceded: they do sell mobile, with people. Read 2026-09-08.
Astra
Conceded: mobile is in their range, as scanning and not autonomous binary analysis. Read 2026-09-08.
Pentera
Web application testing was announced 29 July 2026, in beta with general availability scheduled for Q4 2026. Mobile is not part of it. Read 2026-09-08.
Horizon3 / NodeZero
Read 2026-09-08.
XBOW
Read 2026-09-08.
Ridge Security
Read 2026-09-08.
Vonahi
Read 2026-09-08.
B-52
Regulatory mapping
Findings are mapped to the controls your framework asks about. Certification is issued by a certification body, which is a separate exercise from testing.
Annexure L of the circular dated 20 August 2024 lists mobile applications alongside infrastructure, applications, APIs, operating systems, databases and cloud. Read 2026-09-08.
An engagement delivered in the expert-verified or human-led model is signable under the Security Brigade CERT-In empanelment, because an empanelled auditor is inside it.
If the report goes to a regulator, start with the expert-verified model.
Proof
Each step is unremarkable on its own. In sequence they are the difference between a finding and a note saying the application could not be instrumented.
| Link | Alone | In sequence |
|---|---|---|
| 1 The build as published | A signed, obfuscated release binary. | It is what an attacker has, so it is what is tested. |
| 2 Certificate pinning | Traffic that cannot be observed. | Pinning is handled, so dynamic analysis proceeds. |
| 3 Runtime protections | A session the application closes when it detects instrumentation. | RASP is bypassed, so the behaviour observed is the application. |
| 4 The finding | A claim about a binary. | A reproducible exploit artefact: request, response, steps to reproduce. |
One scan is one application or target. The ladder sets the number of targets, the cadence and the delivery model.