Apsa MCP Server

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 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 and analysis scope and limits.

Upgrading from 1.4.

• New rules add findings and coverage entries: AST-CRYPTO-WEAK-CIPHER, IOS-CRYPTO-WEAK-CIPHER, AST-CRYPTO-HARDCODED-KEY, AST-CRYPTO-STATIC-IV, SOURCE-WEAK-KEY-SIZE, SOURCE-BIOMETRIC-EVENT-BOUND, SOURCE-BIOMETRIC-FALLBACK, SOURCE-BIOMETRIC-ENROLLMENT, SOURCE-WEAK-TLS-VERSION, IOS-ATS-BYPASS-API, ANDROID-NSC-USER-CA, ANDROID-DEEPLINK-AUTOVERIFY, AST-INTENT-REDIRECTION, AST-IMPLICIT-INTENT, IOS-WEBVIEW-FILE-ACCESS, WEBVIEW-SAFE-BROWSING-OFF, IOS-UIWEBVIEW, AST-PATH-TRAVERSAL and IOS-INSECURE-UNARCHIVE. Candidates are not gated by default. The new configuration-confirmed findings (ANDROID-NSC-USER-CA, and ANDROID-CLEARTEXT from the network security configuration) count under the default allowed_statuses, but medium and low thresholds are off by default. Policies that gate candidates or medium/low findings, and only_new baselines, will see them.
• The MASWE matrix changes: MASWE-0003, 0013, 0020, 0021 and 0022 leave not-assessed (they are not-run for APK and IPA, which these source checks do not read), and ANDROID-NSC-CONFIG adds coverage to MASWE-0026 and 0027.
• Existing rules find more: AST-CRYPTO-ECB also reports a bare "AES" transformation (its title is now "AES in ECB mode is selected"; fingerprints are unchanged), AST-CRYPTO-WEAK-HASH reports CryptoKit Insecure.MD5 and Insecure.SHA1, AST-SQL-CONCAT reads SQLiteQueryBuilder.query, the groupBy/having/orderBy/limit arguments and nested exported providers, and SOURCE-INSECURE-RANDOM runs on Swift and Objective-C (its coverage on iOS-only trees changes from not-applicable to checked).
• The AST engine now follows Kotlin let, also, use, apply, run and with lambdas, so every structural rule can report code inside them. A ?.let lambda, or one with return@, merges like a branch that may not run; a reassignment inside a lambda that always runs can now also remove a 1.4 finding. Other lambdas and Swift closures are still not analyzed.
• ANDROID-CLEARTEXT also comes from the referenced network security configuration (configuration-confirmed, so code scanning rates it). The manifest's usesCleartextTraffic candidate is dropped when that configuration was parsed, minSdk is 24 or higher, and the configuration states cleartextTrafficPermitted or targetSdk is 28 or higher. Findings from a configuration that several source sets define are candidates.
• New coverage states can make an audit incomplete: ANDROID-NSC-USER-CA and ANDROID-NSC-CONFIG are partial when a referenced configuration cannot be parsed, is missing from the scanned sources or is a build placeholder, and checks that stop at their match budget report partial. With the default fail_on_partial, such a scan fails the gate and cannot be exported as a baseline. Compiled AAB configurations are not-run.
• Text rules no longer count binary XML from packages as checked, so WEBVIEW-SAFE-BROWSING-OFF is not-run on APKs. The rules resource may carry case_sensitive and once_per_file; inventory gains deep_links[].browsable and network_security_parsed. Unmodified 1.4 skills upgrade with apsa skill install; the MCP tool manifest hash is unchanged.

Upgrading from 1.5.0. 1.5.1 audits large source trees partially instead of refusing them and fixes a slowdown on Android translations.

• A source tree over the text staging budgets (64 MiB, 12,000 files) no longer fails with an input-budget error (exit 1). Files are staged by kind: app code and configuration, other shipped text, localized or qualified Android res/values-* files, then tests. inventory.input_snapshot.omitted counts what was left out, and the audit is incomplete (exit 3). With the default fail_on_partial the gate still fails, and a partial report cannot become a baseline. The 100,000-entry and 64-level budgets also stop reading instead of refusing.
• If app code, configuration or other shipped text is left out (app_scope_complete: false), not-applicable coverage becomes partial too and DEPENDENCY-CVE gains a partial entry (unless --sbom supplies the dependencies), so required rules cannot pass even with fail_on_partial = false.
• SARIF from such an audit carries a warning notification and run.properties.inputSnapshot. A workflow with fail-on-incomplete: "false" now passes with a warning and uploads partial results where 1.5.0 failed; code scanning sees no results for omitted files. Scan a narrower path (one module per job, with its own category) for complete results. MCP report context gains input.input_snapshot.
• In 1.5.0, strings.xml files with many escaped apostrophes (\'), common in French and Italian translations, made WEBVIEW-SAFE-BROWSING-OFF slow enough to hit the parser timeout (about 150 s for a 694 KiB file). XML files are now cleaned of `` comments only, so // in XML text no longer hides a match. Comment cleaning also stays linear on unterminated strings and comments; a /* with no closing */ after it is read as text.
• Unmodified 1.5.0 skills upgrade with apsa skill install; the MCP tool manifest hash is unchanged.

What it checks

Findings distinguish candidate, configuration-confirmed, version-affected, and runtime-confirmed evidence. coverage and warnings show what actually ran. A signing block does not prove signature authenticity, and an affected dependency version does not prove exploitability. A scan with no findings does not establish that the whole app is secure.

OWASP mappings describe relevant checks; APSA does not certify MASVS compliance or implement every MASTG test. Public advisories cannot reveal undisclosed zero-days. App files alone cannot establish a device's OS patch state. See OWASP coverage and the support matrix, both currently in Korean, for tested scope and limits.

Install and run

Install uv on macOS or Linux. APSA targets CPython 3.11 and 3.12; not every host/Python combination has been tested (see the support matrix). The examples select Python 3.12, which uv can download if needed. Initial installation can use the network; scans can then use local inputs and cached intelligence.

After the 1.7.0 publication gates pass, install it from PyPI. Check release readiness for publication status:

uv tool install --python 3.12 apsa==1.7.0
apsa --version
apsa doctor --json
apsa demo --out ./apsa-demo

The package provides apsa and the compatibility aliases quaygate and mobile-audit. If the command is not found, run uv tool update-shell and open a new terminal. GitHub Releases provides the wheel, source distribution, checksums, and a verified bundle with locked requirements, attribution, and the build manifest.

For development or installation with the repository's locked dependencies, use a checkout:

git clone https://github.com/ictechgy/apsa.git
cd apsa
uv sync --locked --python 3.12
uv run --locked apsa doctor --json
uv run --locked apsa demo --out ./apsa-demo

doctor checks parsers, optional device tools, and offline readiness. demo writes an intentionally vulnerable example and scans it; choose a new output directory.

To register the checkout's commands on your PATH:

uv tool install --editable . --force --python 3.12 --constraints requirements-release.txt
apsa --version

This registers apsa and the compatibility aliases quaygate and mobile-audit. --force replaces existing tools with those command names. An editable installation depends on this checkout; keep it in place. If the command is not found, run uv tool update-shell and open a new terminal. The examples below assume apsa is on PATH. Without a global installation, prefix them with uv run --locked from the checkout.

apsa scan /path/to/owned/mobile-project
apsa scan /path/to/owned/app.apk
apsa scan /path/to/owned/app.ipa --sbom /path/to/build.cdx.json
apsa tui

Use a CycloneDX JSON SBOM from the actual build to improve dependency correlation. tui, or apsa without arguments, opens the terminal interface. Run apsa COMMAND --help for options.

Public intelligence and network use

A default scan reads local files and cached intelligence without uploading source code or builds. Public-feed collection and OSV queries use the network:

apsa intel sync
apsa intel status
apsa intel watch --interval 900
apsa scan /path/to/owned/app --online
apsa scan /path/to/owned/app --online --osv-query-mode legacy
apsa scan /path/to/owned/app --online --osv-exclude-coordinate 'Maven:com.private:*'

Scan supports repeatable --osv-exclude-ecosystem, --osv-exclude-name and --osv-exclude-coordinate flags. Patterns are case-sensitive shell globs; coordinates use ecosystem:name. MCP dependency_check accepts query_mode and the corresponding exclude_ecosystems, exclude_names, exclude_coordinates lists. Exclusions are applied locally before transmission and do not count as checked from old cache. Each MCP call uses only its supplied lists; a report's recorded scan exclusions are not inherited. Pass the required exclusions on every dependency_check call. SwiftURL name and coordinate exclusions match both the stored repository name and its canonical OSV transmission name (for example github.com/owner/repo). An unsupported repository identity stays untransmitted when such a policy is active. Use scan or MCP when an exclusion policy is required: intel watch --online neither accepts these controls nor carries over a scan's exclusions. No source code or builds are sent to OSV. The request budget counts OSV operations, including pagination and record lookups, rather than individual HTTP redirect hops.

Watch polls every 900 seconds by default, with a 60-second minimum; it is not a push stream. It runs until interrupted unless --cycles sets a finite number of polls. Reassessment saves a new snapshot when findings, coverage, or intelligence state changes. Inspect feed freshness, failures, and pending CVE processing with intel status. Fetching a CVE document and completing its processing are separate states. The default pending-item policy allows no backlog; use intel_max_pending to set an explicit allowance.

apsa reports reassess latest
apsa reports compare audit_BEFORE audit_AFTER
apsa reports export latest --format sarif --out audit.sarif
apsa reports verify

Reassessment applies current intelligence to a saved inventory; run scan again for changed files or new static checks. If connected to an AI client, that client may send report metadata to its model provider. APSA's MCP context excludes source excerpts, full source files, and screenshot bytes; client-side data handling still depends on the client.

Finding follow-up in 1.6.3: inspect one finding after a change with apsa reports followup audit_BEFORE audit_AFTER --finding F-ID --out followup.json, or MCP reports_followup. It preserves report hashes, identifies possible continuations after line changes, and separates observations from missing coverage or changed scope. It never calls disappearance proof of remediation. See follow-up usage and limits and competitive research and decisions.

CI and background jobs

apsa policy init --out apsa.toml
apsa scan /path/to/owned/app --policy apsa.toml --out audit.json
apsa scan /path/to/owned/app --fail-on high --include-candidates
apsa scan /path/to/owned/app --strict-coverage
apsa scan /path/to/owned/app --background --json
apsa jobs status JOB_ID --json

Severity gates exclude candidate findings by default. Opt in with --include-candidates or the policy's allowed_statuses. Required rules accept checked, limited or not-applicable coverage (limited only while strict_coverage is false); partial execution and missing required checks do not pass. Waivers need a finding ID, a reason, and an expiry date. A background job being completed means it finished; check its audit_incomplete flag and report before treating the audit as complete.

A waiver can record the state that was approved with an optional severity, plus known_exploited = true when a known-exploited finding was approved. If the finding later rises above that severity or becomes known exploited, the waiver stops suppressing it: the finding goes through the thresholds again, the active waiver gets an escalated record, and the gate adds a waiver-severity-escalated notice. A waiver without severity keeps suppressing as before and adds a waiver-severity-unrecorded notice. Notices are in the gate's notices list, separate from reasons, and never change the gate state or exit code by themselves. Dependency advisory findings keep their finding IDs and list equivalent advisory IDs in advisory_ids (the display ID, grouped OSV IDs and aliases, at most 32). Waivers, only_new baselines and report comparisons written before a GHSA advisory gained a CVE alias, or before a lower CVE alias appeared, still match the renamed finding at the same dependency location, including reports from 1.6.4. Alias matching goes only through a display ID (the earlier display ID is among the finding's advisory_ids, or the reverse) and is one-to-one: a finding that matches under its own ID gains no alias match, and an alias shared with several earlier findings or waivers matches nothing, so the finding is reopened. When several active waivers match one finding, any escalated one reopens it.

Unreadable source directories and files leave warnings and incomplete coverage; a source tree with no readable supported files fails explicitly. A source tree over the text staging budgets (64 MiB, 12,000 files) is audited partially rather than refused. Files are staged by kind in this order: app code and configuration (configuration first, then the app's code, then headers and vendored code such as .build/ or vendor/), other shipped text (base resources, JSON, YAML), localized or qualified Android res/values-* files, then tests. inventory.input_snapshot.omitted counts the files and bytes left out by kind (code_and_config, other_text, localized_values, tests), including files over the 8 MiB file limit and files that could not be read or staged. Unreadable directories, and directories past the tree-wide budgets of 100,000 entries (read in name order) or 64 levels, are reported as warnings instead. When app code, configuration or other shipped text is left out, app_scope_complete is false and not-applicable coverage also becomes partial. For a complete audit, scan a narrower folder such as the app module. Storage capture failures remain not-run and cannot establish that a canary was deleted.

Coverage separates execution gaps from precision limits. partial means part of the stated scope was not examined: a budget was reached, a file was skipped or had parse errors or a lossy adaptation, input was truncated, an online query failed, or the latest runtime run was partial. A partial entry makes the audit incomplete (exit 3). limited means every input in scope was examined, but the bounded static model abstained on some paths, for example unresolved native-flow call targets, Objective-C seen only through its reduced model (OBJC-* rules; AST-* rules never examine Objective-C, so beside other languages they are partial), rules without a Swift model beside Kotlin or Java sources, or token-level JS/TS/Dart flow. A limited audit stays complete for the stated scope; reports show the limitation (summary.limited, SARIF notifications, the MASWE matrix and checklists). Across entries, partial outranks limited, which outranks checked. scan --strict-coverage, policy evaluate --strict-coverage or policy strict_coverage = true also treat limited as incomplete; without strict coverage, limited also satisfies policy required_rules. Neither checked nor limited means safe.

--json emits an envelope containing ok, data or error, and exit_code; watch emits one JSON envelope per cycle (NDJSON). ok is true for codes 0 and 4; code 4 means evaluation succeeded but the CI threshold was exceeded. An audit that is both incomplete and over a threshold exits 4 with ok true; the report's summary.incomplete and the policy's partial-audit reason still record the incompleteness. CI must check exit_code and the policy result. Reports may still be produced for codes 3 and 4.

GitHub code scanning

permissions:
  contents: read
  security-events: write
  actions: read            # private repositories: lets the upload read the workflow run
steps:
  - uses: actions/checkout@v7
    with:
      persist-credentials: false
  - uses: ictechgy/apsa@<commit-sha> # v1.7.0; pin the full release commit SHA
    with:
      path: android            # source folder, or a built APK/AAB/IPA in the workspace
      fail-on-incomplete: "true"

The action installs apsa from PyPI at the matching version with the release's hash-locked dependencies, runs scan with --format sarif --sarif-root, writes a job summary, uploads the SARIF file to code scanning and then applies the result. A policy failure or a fail-on threshold fails the job even when the audit is also incomplete (APSA exits 4 then, and the action also reads the report rather than the exit code alone). With a policy, every unmet policy condition (required rules, required intelligence, expired waivers, baseline checks) fails the job; only a partial audit is left to fail-on-incomplete, which fails on exit 3 unless set to "false". Limited coverage does not fail the job unless strict-coverage: "true" (which passes --strict-coverage) or the policy sets strict_coverage = true; either counts limited coverage as incomplete. The incomplete output reports the same decision, including a partial-audit reason behind exit 4. Use policy (with baseline-file and baseline-sha256) for team gates, or fail-on for a severity threshold that excludes candidates.

By default the action is offline: it does no CVE or dependency-advisory correlation, and dependency findings need intel-sync (fetch public advisories first; a partial sync is a warning) and online (send dependency names and versions to OSV, see network use). Private repositories need GitHub Code Security to upload SARIF; set upload-sarif: "false" to keep only the file. Pull requests from forks and every Dependabot-triggered run get a read-only token, so the action skips the upload there and still writes the file and summary.

Each alert's fingerprint is APSA's finding identity: the rule plus the evidence location (file, line, function or archive member). Editing the flagged line or moving the file can therefore close one alert and open another. Candidate findings are uploaded at warning level and tagged candidate, and a rule whose results are all candidates carries no security-severity, so it does not trip code scanning's default check for High or Critical alerts. A rule with confirmed results takes its security-severity from those, and its candidate alerts share that rating. Code scanning tracks alerts per category (default apsa); if you uploaded APSA SARIF before under another category, keep that value, because a new category starts new alerts and leaves the old category's alerts open until you delete its analyses. GitHub may offer Copilot Autofix suggestions on third-party alerts where your plan enables it; this has not been tested with APSA alerts, and APSA's evidence status stays in each alert's properties.

Without the action:

apsa scan android --format sarif --out apsa.sarif --sarif-root android
apsa reports export latest --format maswe --out maswe.json
apsa reports export latest --format cyclonedx --out apsa.cdx.json

reports ingest REPORT --sarif FILE --tool NAME (MCP reports_ingest_sarif) imports another tool's SARIF 2.1.0 results, such as Android Lint, CodeQL or Semgrep, into a new report. Imported results stay candidates with origin: external, add no APSA coverage, and are cross-linked with APSA findings of a related weakness at the same location. Their text is sanitized and treated as untrusted.

--format checklist --checklist masvs-v2 (or a TOML file mapping your own inspection items to MASWE identifiers and APSA rules) lists, per item, the related checks' states and findings; statuses never claim an item passed. reports history TARGET lists when each finding was first and last observed and when a later report stopped observing it, as inspection and remediation records. See using APSA with Korean inspection standards (Korean).

--format cyclonedx writes a CycloneDX 1.6 SBOM of the dependencies APSA discovered, with package URLs and the evidence behind each version, and embeds APSA's dependency matches as VEX entries. Each entry carries the evidence status, the CISA KEV flag and when APSA first observed it for that target, which helps run vulnerability-handling clocks such as the EU Cyber Resilience Act's. Every analysis state is in_triage: APSA never marks a vulnerability not_affected; record that decision yourself with a justification. The SBOM is not a complete build inventory and does not make an app compliant with any regulation.

See the CI example and operations guide (Korean) for policies, backup, limits, and troubleshooting.

MCP and skills

Documentation truncated — see the full README on GitHub.