Evaluate Mobile Security Testing Services with a Verifiable Scope

Define the deliverable before requesting quotes

Specify Android package identifiers, release channels, supported OS versions, environments, backend domains, user roles and source availability. State whether the assessment includes SDKs, build pipelines and cloud configuration or only the distributed binary.

Use OWASP MASVS controls to describe desired coverage and MASTG testing approaches to discuss how that coverage will be investigated. Neither a logo on a proposal nor a generic “OWASP compliant” phrase establishes the work performed.

Ask for a coverage matrix

Require explicit “not tested” entries. An empty cell is not the same as a passed control.

Compare access and assumptions

A black-box test with no accounts cannot answer the same authorization questions as a test with multiple controlled roles and backend documentation. Discuss device capabilities, rooted-device testing, source review and instrumentation in advance. These affect coverage, cost and what conclusions are defensible.

Do not send an unrestricted production administrator account to simplify onboarding. Create scoped test identities and agree on data handling, retention and incident escalation.

Evaluate the report, not the badge

Ask for a redacted sample report showing reproducible steps, affected versions, evidence, impact and actionable remediation. A useful finding explains the boundary that failed, not just the tool that generated an alert. Confirm whether remediation support and a retest are included.

Prepare with APKLint

APKLint's security-testing resources can help inventory manifest risks and organize an initial checklist. They do not constitute a contracted penetration test, certification or professional attestation. Use the preliminary findings to improve the assessment brief, not to replace the independent testing your risk profile requires.