APSA mobile app security audit

APSA

APSA 1.7.0. See the release scope and upgrade notes. Release readiness separates local validation from the hosted publication and public installation gates.

CI semantics change in 1.7.0. Coverage now separates execution gaps (partial, exit 3) from precision limits of the bounded static model (limited, exit 0 unless --strict-coverage or policy strict_coverage is set), and a threshold failure (exit 4) now takes precedence over an incomplete audit (exit 3). Waivers can record the approved severity, dependency advisory findings keep matching across advisory alias changes, and detection is broader for Kotlin, Swift/SwiftUI, archives and platform configuration. Review the upgrade notes before reusing 1.6.x CI conditions or baselines.

Evidence-first security audits for Android and iOS.

English · 한국어

This English README is the source of truth. The Korean README follows it.

AI-assisted attack follow-up in 1.6.3. Packaged plaintext credentials now have a separate, masked candidate check; compiled source-flow coverage remains distinct. Model context retains the untrusted-evidence guidance on detailed and truncated pages. See scope and research. For easier use today, run apsa tui. A desktop app roadmap describes a future local wrapper around the same engine; no desktop installer is included in this release.

APSA 1.6.2 fixes Objective-C binding scope, incomplete OSV queries, precise claim verification, runtime cancellation and APK-set finding provenance. See patch scope and upgrade effects.

Upgrading to 1.6.3. Rescan before comparing reports or approving baselines: explicit synthetic evidence path kinds and deterministic CVE-alias selection can change finding IDs. Candidate-only SARIF descriptor IDs also migrate; APSA rule IDs and finding fingerprints remain unchanged by that SARIF change. Review baseline and waiver effects in the upgrade notes.

APSA 1.6 analysis extensions. This version adds bounded native cross-file flow and input-bound path guards, JS/TS/Dart candidates, recorded Gradle variant selection, OSV batching and transmission exclusions, authenticated runtime evidence, AAB scalar resources, detached CMS consistency and paired verification. See scope, options and remaining limits and the new labeled synthetic results. The remaining follow-up adds explicit .apks device selection, IPA sparse-page/resource seals and supplied-anchor chain checks, and a typed runtime recorder exercised with fresh synthetic app models. The synthetic bundletool selection checks pass; installed split merging, Apple signer identity and physical-device validation remain outside verified scope. Fresh comparator samples remain partial and do not establish accuracy rankings. iOS OS URL delivery is still under validation; callback dispatch alone is not proof of app acquisition or backend revocation. The five validation gates record new compiler, signature-mutation and installed iOS simulator evidence, along with the separate package, comparator, bundletool and backend measurement scopes. See 1.6 release validation for the original 1.6 validation gates and upgrade effects, including the changed MCP tool manifest.

APSA 1.6 large-input follow-up. Rule version: 2026.10.15.apsa.160. Input staging and AST analysis share code priorities and round-robin scheduling within inferred module groups. Lock inventories follow app code; ambiguous *Tests/ and plain Frameworks/ directories retain production priority. Reports record module omissions, comparisons expose input completeness, and the Action summary shows staging omissions. Partial fingerprints remain SBOM metadata instead of application hashes. See scope and validation.

APSA 1.6 review fixes. Bounded device-spec metadata, per-file partial reasons, text/compiled hybrid coverage, explicit signature binding scope, portable source comparisons and exact package-content checks are documented in strengthening scope and evidence limits. Synthetic acquisition adapters are source-test helpers and are excluded from the installed wheel.

APSA helps developers and security teams audit their own mobile apps. It inspects source code and APK/AAB/IPA builds, correlates public vulnerability information, and keeps evidence, coverage, and report history together. Use the CLI, terminal UI, or the same audit engine through MCP and reusable skills.

Pronounced “ap-sah”; Korean name 앱사. The name connects “app + audit” with App Security Audit. APSA combines the earlier Quaygate lint engine and Mobile Audit workflows in one package.

APSA 1.1 adds bounded model report pages, portable approved baselines, exported policy decisions, and explicit source module/configuration selection. See model and team workflows for the contract and release sequence for later analysis milestones.

Mixed unsupported source languages and truncated pattern results are incomplete. Declared Gradle versions remain candidates until resolved-build evidence is supplied. OS-CVE correlation reports a bounded recent window, so feed freshness alone cannot satisfy historical coverage.

APSA 1.2 adds AAB base-manifest/module DEX analysis, embedded IPA Mach-O metadata, bounded Objective-C .m candidates and parser OS isolation that is on by default where it can start. Every AAB audit stays partial, and embedded IPA metadata does not authenticate signatures. See analysis scope and limits and the independent holdout.

Upgrading from 1.1. With the default APSA_PARSER_SANDBOX=auto, the parser runs under macOS Seatbelt or Linux bubblewrap after an input-free activation probe succeeds. Without a backend, the report records parser_isolation.state: unavailable and parses with resource limits only. If the backend is present but cannot start (for example inside another sandbox or with blocked user namespaces), the report also records the attempted backend and probe reason and adds an inventory warning. required refuses such audits; off skips the backend. A parser failure after isolation has started aborts the audit without an unsandboxed retry. Dependencies declared only in a Gradle version catalog no longer receive CVE matches until build usage or resolved versions are supplied. New rules (AST-CRYPTO-ECB, AST-CRYPTO-WEAK-HASH, AST-SQL-CONCAT, OBJC-CRYPTO-WEAK-HASH, OBJC-WEBVIEW-UNTRUSTED-REQUEST) can add findings relative to existing 1.1 baselines.

APSA 1.3 links Gradle version-catalog aliases to the shipped dependency configurations that use them and reads application-module gradle.lockfile coordinates as resolved versions. It also decodes AAB feature-module manifests, recomputes Mach-O CodeDirectory page and entitlement hashes without authenticating the signature, adapts more Swift and Objective-C syntax, and can backfill an explicit range of Android security bulletins with SoC vendor and vendor patch-level context. See the dependency evidence results, the independent source pairs and analysis scope and limits.

Upgrading from 1.2.

• Catalog aliases referenced from shipped configurations become declared candidates and can receive CVE matches again; unreferenced, test-only and build-tooling aliases stay unresolved. Application-module lockfile coordinates are exact, so their matches are version-affected, and the default policy fails on high and critical ones; other modules' lockfile coordinates stay declared candidates. A declared candidate that every shipping application resolved is superseded and leaves CVE correlation. Partial inputs keep every candidate, and with unparsed project references only an application's own declarations can be superseded.
• Lockfile assumptions: APSA does not check that dependency locking is enabled or that the lockfile is current, and it merges the release runtime classpaths of every application module (flavors and wear, TV or automotive apps). --source-module scans only that module's directory, so a root version catalog and library-module declarations outside it are not read.
• Baselines and waivers: a lockfile-resolved finding has a new location (gradle.lockfile) and status, so only_new treats it as new and waivers for the old finding ID no longer match. Re-approve baselines after upgrading.
• --online sends dependency names and versions to OSV, including shipped catalog aliases, transitive lockfile coordinates and private group IDs unless excluded. The default auto mode uses legacy queries for at most 100 eligible unique package-version coordinates and batch queries for larger inventories. Default online budgets are 1000 packages, 100 packages per batch and 2000 OSV requests, including pagination and vulnerability-record lookups. scan --online --osv-query-mode legacy retains the 100-package limit; --osv-query-mode batch explicitly selects batching with the default budgets. Use scan's --osv-exclude-ecosystem, --osv-exclude-name or --osv-exclude-coordinate for local transmission exclusions. Excluded dependencies are never sent or marked checked, even with a prior cached result. Unchecked, unresolved, unsupported or excluded dependencies keep online coverage incomplete; a fresh result for one package does not complete the rest.
• IPA reports gain BINARY-IOS-CODE-INTEGRITY. Consistent hashes do not prove authenticity, because a modified binary that was re-signed is consistent. A mismatch adds a warning, not a finding; App Store encrypted and unsigned executables stay not-run.
• intel sync refreshes only the recent Android bulletin window; use intel backfill for older months. Records cached by 1.2 derive their vendor scope from the component name; entries outside chipset and kernel sections use the platform patch level only. AAB feature-module installation stays unknown.
• Adapted Swift and Objective-C files stay partial, and an Objective-C function overlapping a normalized preprocessor conditional is skipped as uncertain. Unmodified 1.2 skills upgrade with apsa skill install.

APSA 1.4 is easier to put in front of developers and coding agents. A GitHub Action uploads SARIF to code scanning with stable fingerprints, security severity, MASWE tags and evidence status; every report carries an OWASP MASWE v1.0 coverage matrix that names the weaknesses APSA did not assess; and the MCP server is packaged for the MCP Registry and as a Claude Code plugin, with a documented MCP security model.

Upgrading from 1.3.

• SARIF exports now list a descriptor for every rule with results (help, security-severity, precision, MASVS/MASWE tags), add partialFingerprints from the finding identity, and report not-run and partial coverage as tool execution notifications. Candidate findings are warning rather than error and their rules are tagged candidate. --sarif-root makes locations repository-relative; URIs are percent-encoded, and APK/AAB/IPA members and files outside th