Secure Mobile App Testing Tracker
A record of security test coverage, findings, and remediation status for iOS and Android application releases.
I. Overview
%%{init: { 'theme': 'base', 'themeVariables': { 'edgeLabelBackground': '#fff' }}}%%
flowchart LR
A["Mobile releases shipped with\nfunctional QA, not security testing"] -- "Need for platform-specific\nsecurity validation" --> B["Formal Secure Mobile\nApp Testing Tracker"]
style A fill:#f9f9f9,stroke:#333,stroke-width:3px
style B fill:#e1f5fe,stroke:#01579b,stroke-width:3px
Definition: A Secure Mobile App Testing Tracker records which security tests have been run against a mobile application build — insecure storage checks, transport security validation, reverse-engineering resistance, and platform-specific permission review — and the status of any findings.
Features:
( Ownership ) Maintained jointly by the AppSec team and the mobile engineering team.
( Mobile-Specific Risk ) Exists because mobile apps carry risks web apps do not — client-side binaries can be decompiled, and local storage and keychains can be inspected on a jailbroken or rooted device.
( Beyond Store Review ) App-store review does not substitute for a security assessment.
( Prevents False Confidence ) Without a tracker, mobile releases ship on the assumption that “it works” is the same as “it is safe.”
II. Structure & Process
sequenceDiagram
participant Mobile as "Mobile Engineering"
participant AppSec as "AppSec / Mobile Tester"
participant QA as "Release QA"
participant Lead as "AppSec Lead"
Mobile->>AppSec: "Submit release candidate build for testing"
AppSec->>AppSec: "Run static and dynamic security tests"
AppSec->>Mobile: "Log findings in tracker"
Mobile->>Mobile: "Remediate flagged issues"
Mobile->>AppSec: "Request retest"
AppSec->>Lead: "Confirm closure or escalate blockers"
Lead->>QA: "Approve build for store submission"
| Field | Description |
|---|---|
| App Version / Build | Identifier of the build under test |
| Platform | iOS or Android, with minimum OS version tested |
| Test Category | e.g. Insecure Data Storage, Transport Layer Security, Reverse Engineering / Tampering, Authentication, Permission Scope |
| Test Method | Static binary analysis, dynamic instrumentation (e.g. on a rooted/jailbroken device), or manual review |
| Finding | Description of the weakness identified, if any |
| Severity | Risk rating of the finding |
| Status | Open, In Remediation, Retested, or Closed |
| Tester | Individual or vendor who performed the assessment |
Testing runs on every major release and on any build introducing new storage, networking, or authentication logic; the tracker is reviewed by the AppSec lead before store submission.
III. Best Practices & Comparison
| Document | Primary Purpose | Update Cadence | Owner |
|---|---|---|---|
| Secure Mobile App Testing Tracker | Validate mobile-specific security controls per release | Per release | AppSec + Mobile Engineering |
| Web Application Vulnerability Tracker | Equivalent tracking for web application findings | Per scan / pentest cycle | AppSec |
| Static Code Analysis Log | Source-level scanning, complementary to binary-level mobile testing | Per build / commit | AppSec + Engineering |
- Test on both a clean device and a rooted/jailbroken device — some controls only fail once platform protections are bypassed.
- Verify that sensitive data (tokens, credentials, PII) is never written to logs, backups, or unencrypted local storage.
- Confirm certificate pinning and TLS configuration independently of the backend API’s own transport security.
- Review requested platform permissions against actual feature usage and flag any over-broad scope.
- Retest every finding after remediation before approving the build for store submission.
Related: Web Application Vulnerability Tracker, Static Code Analysis Log
Last updated 18 Aug 2026, 00:00 UTC.