Pick the resource by the job
| Job | Starting resource | Expected output |
|---|---|---|
| Set security requirements | MASVS | Applicable controls and acceptance criteria |
| Design technical tests | MASTG | Procedures, prerequisites and evidence |
| Explain risk themes | Mobile Top 10 | Shared language for prioritization discussions |
| Approve a release | Your documented review process | Evidence-based decision with residual risks |
The MASVS, MASTG and Mobile Top 10 are complementary. None independently inspects your application simply because you cite it in documentation.
Follow one feature through the resources
Consider a note-taking app that synchronizes private notes. Begin with the requirement to protect sensitive stored and transmitted data. Then identify tests covering the local database, backups, network clients, session expiry and cross-account access.
The risk-awareness language helps explain why these tests matter. The control framework defines expectations. The test guide suggests evidence collection. The release decision still belongs to the team reviewing the actual results.
Record versions and exceptions
Store the source revision or review date used for each mapping. Frameworks evolve and older assessment templates may include superseded names or organizational structures. Do not claim a current assessment based solely on a copied spreadsheet with an old title replaced.
Document an exception with its rationale, owner and expiry or reassessment trigger. “Not applicable because the app has no authenticated network feature” is meaningful; “not applicable because the scanner did not report it” is not.
Avoid meaningless compliance statements
A public claim should match the work performed. “Reviewed selected storage and network controls against these references” is narrower and more defensible than “OWASP certified.” Include scope and limitations in internal reports, especially when source code, devices or backend access were unavailable.
Put static tools in the right place
APKLint can provide observations about manifests, packages and configured SDK indicators. Use those observations as inputs to the control review. Runtime behavior, backend authorization and organizational handling of sensitive data require evidence beyond an uploaded APK.
Map one private-note export across three layers
Suppose a note app lets users export their own documents. Begin with the security expectation: the current user can export an authorized note, while another user's private note remains inaccessible. Express that requirement independently of which scanner or test device will be used. This is the role of a control-oriented review.
The MASVS supplies a structured control vocabulary. The MASTG supplies practical investigation material. Neither should replace the product's concrete definition of whose note may be exported and under what session conditions.
Attach procedures and evidence to the requirement
Create two synthetic accounts with one note each. Test an authorized export, a cross-account identifier and an expired session. Inspect the actual server decision and the resulting file contents. A client screen refusing to open the wrong note is useful, but the export endpoint must independently enforce the same ownership boundary.
Review local handling after a successful export. Determine where the file is written, which application can receive it and whether the user deliberately chose that destination. The authorization test and the file-sharing test can support different controls even though they belong to one visible feature.
Use risk-awareness language to explain the consequence of a failure, such as disclosure of another account's private content. Avoid substituting a category number for the actual impact. A developer should understand the problem from the evidence even without memorizing an OWASP edition's headings.
Retain the chosen control version, test reference, artifact identity and result together. If the guide reorganizes its test identifiers later, the saved evidence still explains what was examined. Update the mapping deliberately rather than renaming an old report and implying the application was retested.
For release approval, summarize the applicable controls with supported, failed and untested outcomes. One successful note-export scenario does not prove every authentication, storage and privacy control across the application. The distinction between requirement, procedure and observed result makes that limit understandable without reducing the usefulness of the test.
Sources and further reading
- OWASP: Mobile Application Security Verification Standard
- OWASP: Mobile Application Security Testing Guide
- OWASP Mobile Top 10 — official release source
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
