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.
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: 22 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
