apsa

# APSA

**Evidence-first security audits for Android and iOS.**

[English](https://github.com/ictechgy/apsa/blob/main/README.md) · [한국어](https://github.com/ictechgy/apsa/blob/main/README.ko.md)

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

<!-- mcp-name: io.github.ictechgy/apsa -->

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](docs/MODEL_WORKFLOWS.md) for the contract and [release sequence](docs/ROADMAP.md) 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](https://github.com/ictechgy/apsa/blob/main/docs/NEXT_ANALYSIS.md) and the
[independent holdout](https://github.com/ictechgy/apsa/blob/main/benchmarks/NEXT_RESULTS.md).

**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](https://github.com/ictechgy/apsa/blob/main/benchmarks/DEPENDENCY_RESULTS.md),
the [independent source pairs](https://github.com/ictechgy/apsa/blob/main/benchmarks/FPFN_RESULTS.md)
and [analysis scope and limits](https://github.com/ictechgy/apsa/blob/main/docs/NEXT_ANALYSIS.md).

**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 catalog aliases used in shipped configurations and the
  release-runtime lockfile coordinates of every module, transitive ones and
  private group IDs included, to OSV; there is no exclusion list. One run
  queries at most 100 packages: those without an OSV result from the last day
  first, and among them build-file declarations before lockfile coordinates in
  lockfile order. Measured application lockfiles hold 179–412 shipped
  coordinates, so a single run leaves the rest `not-run`: a required
  `DEPENDENCY-CVE` rule cannot pass, the online audit is incomplete and the
  default `fail_on_partial` policy exits 3. Repeated runs within a day advance
  through the remainder, and a package with an OSV result from the last day
  counts as checked. Unresolved catalog aliases and ecosystems OSV does not
  support are reported as online errors on every run, so they keep the online
  audit incomplete however many runs follow.
- 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](https://mas.owasp.org/MASWE/) 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](https://github.com/ictechgy/apsa/blob/main/docs/MCP_SECURITY.md).

**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 the target appear as logical locations on the target. Code
  scanning may therefore show re-keyed alerts once.
- New source checks (exported components, backup, `targetSdk`, privacy
  manifests, ATS exceptions, hard-coded secrets, insecure randomness, trust-all
  TLS, external storage, Java deserialization, more SQL sinks, mutable
  `PendingIntent`) add findings and coverage entries. A policy with
  `required_rules` or a severity gate can fail where 1.3 passed; review the first
  1.4 report before tightening gates.
- Rule metadata gains MASWE v1.0 identifiers; model context and `capabilities`
  gain a `maswe` section, and Markdown reports a MASWE coverage table. Reports
  derived by `reports ingest` add `external_inputs` and findings with
  `origin: external`; existing fields keep their meaning.
- The MCP server adds `verify_finding`, `specs_validate`,
  `reports_ingest_sarif`, `reports_checklist` and `reports_history`.
  `tool_manifest_sha256` now covers a normalized APSA-owned surface, so its
  value changes; update any pinned hash. Unmodified 1.3 skills upgrade with
  `apsa skill install`.

APSA 1.5 widens what a source scan looks for. New checks cover the OWASP
MASWE weaknesses behind most MASTG demo misses: broken ciphers and implicit
ECB, key material and IVs built from constants, short (512–1536-bit) RSA, DSA
and DH key sizes and CryptoKit `Insecure` digests; biometric results not bound to a key,
device-credential fallback and keys that survive new enrollment; TLS below
1.2, iOS connections outside App Transport Security, and user CAs or cleartext
in the network security configuration; unverified App Links, intent
redirection and implicit internal Intents; path traversal and keyed
unarchiving without secure coding; and Safe Browsing turned off, UIWebView and
WKWebView file access. On a blind holdout of 24 public vulnerable/fixed pairs
labeled by MASWE weakness, APSA 1.5.0 found 7 of the 21 scored in-scope pairs
at the labeled lines (Wilson 95% 17–55%). Two of the seven come from rules new
in 1.5 and five from rules 1.4 already had; the fixed-side FP upper bound is 4
of 21, and a 22nd in-scope pair failed to scan. See the
[blind pair results](https://github.com/ictechgy/apsa/blob/main/benchmarks/BLIND_PAIRS_RESULTS.md)
and [analysis scope and limits](https://github.com/ictechgy/apsa/blo