Why an old finding needs interpretation
The 2016 archive used categories including improper platform usage, code tampering, reverse engineering and extraneous functionality. The later release reorganizes risks rather than keeping a permanent one-to-one numbering system.
If a report says only “M9,” first find its edition. Renaming the ticket to the modern category with the same number can change its meaning entirely.
Map behavior, not category numbers
| Historical observation | Modern review question |
|---|---|
| A sensitive operation is exposed through a component | What authorization protects the entry point? |
| A debug menu ships in production | Can the capability be reached, and what access does it grant? |
| Code is easy to decompile | Which secrets or trust decisions were incorrectly placed in the client? |
| Local sensitive data is readable | Which storage and key-management controls are required? |
There is no universal automatic conversion table because one old finding may involve several current controls. Keep the original classification as provenance, then add a reasoned mapping.
Reproduce before carrying a finding forward
An issue against an APK from years ago may no longer exist, or it may survive in a different module. Record the old artifact if available, the current package hash, relevant configuration and the test used to compare behavior.
Do not close a finding merely because the current scanner uses a different label. Equally, do not reopen it solely because an old report contains a high-severity heading.
Use current Android behavior
Permissions, exported-component rules, storage access and target-SDK behavior have changed since 2016. A tutorial reproducing an old demonstration should say which device/API version it uses. Applying its exact remediation blindly can break a modern app or leave a different boundary unprotected.
Keep history and current assurance separate
Use the MASTG to design current tests, while retaining the old report for audit history. APKLint's OWASP checklist can help capture current static observations; it does not convert a historical report into a fresh security assessment by updating its date.
Read an old M9 finding before assigning a new label
The official 2016 archive labels M9 as Reverse Engineering. An old report under that heading might describe ordinary decompilation, discovery of a privileged embedded credential or modification of a client-side decision. Those observations have different consequences, despite sharing the historical category.
Preserve the original claim and test the current behavior
Suppose the old report found a service credential in a packaged resource. Keep its original artifact hash and classification as provenance. In the current authorized build, determine whether the value remains, whether it still grants authority and whether the service now requires appropriate account authorization. Do not expose or exercise a third-party credential while investigating an inherited report.
If the current APK no longer contains the value, establish what happened to the distributed credential. A packaging change can coexist with an unrevoked older credential. Close the relevant parts separately: source removal, replacement architecture and service-side revocation have different evidence and owners.
If the old finding only demonstrated that code could be decompiled, examine which actual protection requirement was at risk. Readable code is not equivalent to a bypassed backend authorization boundary. The remediation should address misplaced secrets or client-only trust decisions where those exist, rather than promising that obfuscation makes distributed code impossible to inspect.
Map the surviving behavior to current controls using the MASVS and select current procedures from the testing guide. A single historical finding may map to more than one control, so retain the reasoning instead of forcing a one-to-one category-number conversion.
Finally, record the device and target-SDK context for any reproduced platform behavior. An old exported-component default or storage assumption can differ on a current build. The report should explain which behavior was observed now, which historical issue was resolved and which part could not be retested. This preserves useful history without presenting a renamed archive as a fresh assessment.
Sources and further reading
- OWASP Mobile Top 10 — historical 2016 source
- OWASP Mobile Top 10 — official release source
- 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
