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
| Area | Evidence you should request |
|---|---|
| Authentication | Role-specific scenarios and session lifecycle results |
| Storage | Locations inspected and sensitive-data examples, appropriately redacted |
| Network | Clients, endpoints and trust behaviors tested |
| Platform entry points | Exported components and link-handling observations |
| Dependencies | Resolved versions and vulnerability applicability review |
| Retesting | Clear closure criteria for remediated findings |
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.
Compare two proposals using the same account-export feature
Give each provider a concrete scenario: two controlled roles can view and export different private records. Ask how the proposed assessment would examine cross-account access, session expiry, local export files and the backend decision. This exposes differences in coverage more clearly than comparing the number of scanner tools or a broad mobile-security label.
Use MASVS as a shared control vocabulary. Ask the provider to identify which requirements the proposed access and time can support. A binary-only review without working test accounts may still provide useful package findings, but its report should not imply that authenticated workflows were exercised.
Look for reproducibility and useful limits in the sample
A redacted sample finding should name the tested version, required role, relevant operation, observed failure and practical impact. Look for an expected result and a retest condition. A screenshot of a tool warning without applicability analysis leaves the engineering team to perform much of the actual investigation after delivery.
Discuss the provider's handling of third-party services and production-only dependencies before access is granted. The statement of work should identify permitted environments and techniques, evidence storage, retention and escalation. Create scoped test identities with synthetic data instead of relying on an unrestricted production administrator account.
Clarify whether the quoted work includes source review, build configuration, native code, multiple device versions and backend authorization. These can be separate coverage decisions. A lower quote may reflect a narrower engagement rather than a more efficient version of the same assessment, so compare the written boundaries.
Ask how remediation questions and retesting are handled. Confirm which replacement artifact will be tested, how many retest rounds are included and whether newly introduced regressions are reported. Closure should be based on the original exploit condition and an intended valid flow, not only on a developer's explanation.
Finally, retain a coverage matrix with tested, failed, excluded and unavailable areas. Use it to plan follow-up work and to phrase any external assurance statement accurately. The useful purchase is evidence that supports decisions about your particular application, together with clear limits, rather than a generic badge detached from the assessed version.
Sources and further reading
- OWASP: Mobile Application Security Verification Standard
- OWASP: Mobile Application Security Testing Guide
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
