APSA mobile app security audit

What APSA mobile app security audit does

APSA mobile app security audit is designed for developers and security teams reviewing their own Android and iOS applications. It accepts source code and packaged artifacts, including APK, AAB, and IPA files, then produces findings with associated evidence and coverage information. The same audit engine is available through the command-line interface, terminal UI, MCP server, and reusable skills.

The project combines source checks, binary and package inspection, public vulnerability correlation, report history, and policy-oriented workflows. Its reports can include OWASP MASWE v1.0 coverage, including weaknesses that were not assessed. Findings can also be exported as SARIF for GitHub code scanning, with stable fingerprints, security severity, precision, and MASVS/MASWE metadata.

How it works

APSA mobile app security audit keeps analysis local while examining the supplied project or build artifact. Android analysis covers source and package formats, including AAB base and feature-module manifests, DEX content, dependency declarations, version catalogs, and relevant lockfile coordinates. iOS analysis includes IPA contents, embedded Mach-O metadata, and bounded Objective-C and Swift candidates.

Dependency analysis can correlate candidates with OSV data when online operation is used. Android security bulletin data can be refreshed for a recent window or backfilled for an explicit range. Reports distinguish declared, resolved, partial, not-run, and candidate results rather than presenting incomplete analysis as complete.

Parser isolation is controlled by APSA_PARSER_SANDBOX. With the default auto setting, APSA attempts macOS Seatbelt or Linux bubblewrap after an input-free probe. required refuses an audit when an isolation backend cannot start, while off disables the backend. If isolation starts and parsing later fails, APSA does not retry unsandboxed.

Tools and capabilities

The MCP package adds tools for validating findings and specifications, ingesting SARIF, producing checklists, and reviewing report history. The README specifically names verify_finding, specs_validate, reports_ingest_sarif, reports_checklist, and reports_history.

The audit rules cover mobile-specific source weaknesses such as exported components, backup settings, target SDK values, privacy manifests, ATS exceptions, hard-coded secrets, insecure randomness, trust-all TLS, external storage, Java deserialization, SQL sinks, and mutable PendingIntent usage. Additional Android and iOS crypto, web-view, binary-integrity, and dependency checks are available, although several analyses remain bounded or partial.

Limitations and notes

APSA mobile app security audit does not treat every result as definitive evidence. Mixed unsupported source languages, truncated pattern results, adapted Swift or Objective-C files, and some uncertain preprocessor overlaps can produce incomplete coverage. Every AAB audit remains partial. Embedded IPA metadata can be inspected, but its hashes do not authenticate the code signature; a mismatch is a warning rather than a finding.

Online dependency checks are bounded to at most 100 packages per run. Larger applications may therefore retain not-run packages and remain incomplete across a single audit. Unresolved catalog aliases and unsupported OSV ecosystems also keep online analysis incomplete. Lockfile assumptions are not independently verified, and --source-module limits scanning to the selected module directory.

A GitHub Action can upload SARIF to code scanning, and the MCP server is packaged for the MCP Registry and as a Claude Code plugin. The supplied material does not specify a license or a complete list of MCP client compatibility requirements.