AIエージェント向けに、ソースコード、APK、AAB、およびIPAファイルに対してエビデンスに基づいたAndroidとiOSのセキュリティ監査を実行します。
別名 ictechgy/apsa, apsa
- スター
- 0
- ツール
- —
- ダウンロード数(30日間)
- —
- 最新バージョン
- 1.7.0
- 最終コミット
- 2026年11月6日
- ライセンス
- MIT
APSA MCPとは
APSAはMCPサーバーです。 AIエージェント向けに、ソースコード、APK、AAB、およびIPAファイルに対してエビデンスに基づいたAndroidとiOSのセキュリティ監査を実行します。.
プロジェクトのREADMEから生成された概要
APSA MCP server について
APSAは、モバイルアプリケーション、特にAndroidおよびiOSプラットフォームを対象とした、エビデンスに基づいたセキュリティ監査を提供します。開発者やセキュリティチームが、ソースコードとともにAPK、AAB、IPAなどのコンパイル済みファイルを検査できるように設計されています。このツールは、検出結果を公開されている脆弱性情報と照合し、レポート、カバレッジ、およびエビデンスの履歴を保持します。
ユーザーは、コマンドラインインターフェース、apsa tuiコマンドによるターミナルユーザーインターフェース、またはAIエージェント用のMCP serverを通じてエンジンを操作できます。システムは、依存関係の脆弱性を確認するためのオンラインOSVクエリや、macOS SeatbeltまたはLinux bubblewrapを使用したサンドボックス分離によるローカル解析など、さまざまな解析モードをサポートしています。Gradleのバージョンカタログ、Androidセキュリティ速報、Mach-Oメタデータなどの複雑なモバイル構造を処理し、アプリケーションの詳細なセキュリティ状況を提供します。
できること
- 1依存関係の脆弱性の特定開発者は、OSVにクエリを送信することで、同梱されている依存関係に既知の脆弱性があるかどうかを確認できます。
- 2CIセキュリティチェックの自動化GitHub Actionsを使用して、モバイルセキュリティ監査を継続的インテグレーション(CI)パイプラインに統合できます。
プロジェクトの README から作成されています。すべてのユースケースは、その引用と照らし合わせて確認されています。
APSA MCPのインストール方法
フォーマット検証日 2026年11月10日Cursor に追加Gooseに追加Claude CodeにAPSA MCPをインストール
$ claude mcp add apsa -- uvx apsaCursorにAPSA MCPをインストール
~/.cursor/mcp.json
{
"mcpServers": {
"apsa": {
"command": "uvx",
"args": [
"apsa"
]
}
}
}VS CodeにAPSA MCPをインストール
.vscode/mcp.json
{
"servers": {
"apsa": {
"type": "stdio",
"command": "uvx",
"args": [
"apsa"
]
}
}
}VS Code CLIにAPSA MCPをインストール
$ code --add-mcp '{"name":"apsa","type":"stdio","command":"uvx","args":["apsa"]}'Claude DesktopにAPSA MCPをインストール
claude_desktop_config.json
{
"mcpServers": {
"apsa": {
"command": "uvx",
"args": [
"apsa"
]
}
}
}CodexにAPSA MCPをインストール
$ codex mcp add apsa -- uvx apsaCodex config.tomlにAPSA MCPをインストール
~/.codex/config.toml
[mcp_servers.apsa] command = "uvx" args = ["apsa"]
Gemini CLIにAPSA MCPをインストール
$ gemini mcp add -s user apsa uvx -- apsaGemini settings.jsonにAPSA MCPをインストール
~/.gemini/settings.json
{
"mcpServers": {
"apsa": {
"command": "uvx",
"args": [
"apsa"
]
}
}
}自動チェック
実行日 2026年11月14日完全なレポート →自動チェックに合格しました。これはセキュリティ監査ではありません。コードを読み、サーバーに必要最小限のアクセス権を与えてください。 チェックの仕組み
- ソースリポジトリがリンクされており、アクセス可能ictechgy/apsa is public and reachablegithub.com/ictechgy/apsa ↗合格
- パッケージがこのリポジトリをソースとして指定apsa names ictechgy/apsa as sourcepypi.org/project/apsa/ ↗合格
- ビルドの来歴 (Sigstore 証明)Sigstore attestation for apsapypi.org/project/apsa/ ↗合格
- オープンソースライセンス (OSI)MITspdx.org/licenses/MIT.html ↗合格
- 過去1年以内にコミットまたはリリースありLast commit or release 2026-11-06github.com/ictechgy/apsa ↗合格
- OpenSSF Scorecard未チェック
- パッケージ名が有名なパッケージに酷似していないNo popular package one edit away from apsa合格
- パッケージおよびその依存関係に重大な勧告なし82 resolved dependencies checked; no critical advisoryosv.dev ↗合格
- モデルへの隠れた指示がない0 tool descriptions and the README read; no override phrases, credential paths or hidden characters合格
- 破壊的なツールがラベル付けされている未チェック
- リモートエンドポイントが MCP ハンドシェイクに応答未チェック
README
GitHubで見る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.
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
declaredcandidates and can receive CVE matches again; unreferenced, test-only and build-tooling aliases stay unresolved. Application-module lockfile coordinates are exact, so their matches areversion-affected, and the default policy fails on high and critical ones; other modules' lockfile coordinates staydeclaredcandidates. 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-modulescans 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, soonly_newtreats it as new and waivers for the old finding ID no longer match. Re-approve baselines after upgrading. --onlinesends dependency names and versions to OSV, including shipped catalog aliases, transitive lockfile coordinates and private group IDs unless excluded. The defaultautomode 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 legacyretains the 100-package limit;--osv-query-mode batchexplicitly selects batching with the default budgets. Use scan's--osv-exclude-ecosystem,--osv-exclude-nameor--osv-exclude-coordinatefor 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 staynot-run. intel syncrefreshes only the recent Android bulletin window; useintel backfillfor 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), addpartialFingerprintsfrom the finding identity, and report not-run and partial coverage as tool execution notifications. Candidate findings arewarningrather thanerrorand their rules are taggedcandidate.--sarif-rootmakes 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, mutablePendingIntent) add findings and coverage entries. A policy withrequired_rulesor 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
capabilitiesgain amaswesection, and Markdown reports a MASWE coverage table. Reports derived byreports ingestaddexternal_inputsand findings withorigin: external; existing fields keep their meaning. - The MCP server adds
verify_finding,specs_validate,reports_ingest_sarif,reports_checklistandreports_history.tool_manifest_sha256now covers a normalized APSA-owned surface, so its value changes; update any pinned hash. Unmodified 1.3 skills upgrade withapsa 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-TRAVERSALandIOS-INSECURE-UNARCHIVE. Candidates are not gated by default. The new configuration-confirmed findings (ANDROID-NSC-USER-CA, andANDROID-CLEARTEXTfrom the network security configuration) count under the defaultallowed_statuses, but medium and low thresholds are off by default. Policies that gate candidates or medium/low findings, andonly_newbaselines, 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-CONFIGadds coverage to MASWE-0026 and 0027. - Existing rules find more:
AST-CRYPTO-ECBalso reports a bare"AES"transformation (its title is now "AES in ECB mode is selected"; fingerprints are unchanged),AST-CRYPTO-WEAK-HASHreports CryptoKitInsecure.MD5andInsecure.SHA1,AST-SQL-CONCATreadsSQLiteQueryBuilder.query, the groupBy/having/orderBy/limit arguments and nested exported providers, andSOURCE-INSECURE-RANDOMruns 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,runandwithlambdas, so every structural rule can report code inside them. A?.letlambda, or one withreturn@, 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-CLEARTEXTalso comes from the referenced network security configuration (configuration-confirmed, so code scanning rates it). The manifest'susesCleartextTrafficcandidate is dropped when that configuration was parsed, minSdk is 24 or higher, and the configuration statescleartextTrafficPermittedor 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-CAandANDROID-NSC-CONFIGare 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 defaultfail_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-OFFis not-run on APKs. The rules resource may carrycase_sensitiveandonce_per_file; inventory gainsdeep_links[].browsableandnetwork_security_parsed. Unmodified 1.4 skills upgrade withapsa 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.omittedcounts what was left out, and the audit is incomplete (exit 3). With the defaultfail_on_partialthe 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 andDEPENDENCY-CVEgains a partial entry (unless--sbomsupplies the dependencies), so required rules cannot pass even withfail_on_partial = false. - SARIF from such an audit carries a warning notification and
run.properties.inputSnapshot. A workflow withfail-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 narrowerpath(one module per job, with its owncategory) for complete results. MCP report context gainsinput.input_snapshot. - In 1.5.0,
strings.xmlfiles with many escaped apostrophes (\'), common in French and Italian translations, madeWEBVIEW-SAFE-BROWSING-OFFslow 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
| Area | Available checks |
|---|---|
| Source code | Java/Kotlin/Swift AST analysis; bounded Objective-C .m candidates; WebView and deep-link patterns; Manifest, Info.plist, storage, and dependency inspection, including Gradle catalog usage and application lockfiles; exported components, backup and targetSdk; Apple required-reason APIs against privacy manifests; known credential formats (masked); weak random for security values; mutable implicit PendingIntents; trust-all TrustManagers and hostname verifiers, unevaluated iOS server trust and weakened ATS exception domains; external storage writes; Java deserialization; (1.5) broken ciphers, constant keys and IVs, short RSA keys, biometric binding and fallback, TLS versions, iOS APIs outside ATS, network security configuration, App Links, intent redirection and implicit Intents, path traversal, keyed unarchiving, Safe Browsing, UIWebView and WKWebView file access |
| Android builds | DEX calls and constant flow; AAB base and feature-module manifests and module DEX (always partial); resources and network configuration; exported components/providers; signing-block and v1 certificate evidence; ELF hardening |
| iOS builds | Mach-O headers, including embedded framework/extension metadata; CodeDirectory page and entitlement hash integrity (not signature authentication); limited entitlement/configuration checks (embedded XML entitlements, ATS exceptions, provisioning indicators); PIE, canary, and string evidence |
| Public intelligence | Apple/Android advisories with bounded Android bulletin backfill, CVE, CISA KEV, OWASP guidance, and OSV dependency correlation |
| Reports and CI | SQLite history, comparison and reassessment, JSON/Markdown/SARIF export, coverage requirements, and expiring waivers |
| Runtime | Prepared scenarios for owned Android test apps and iOS simulator apps; physical iOS devices are unsupported |
| Model integration | stdio MCP tools/resources and packaged skills, without a required model provider or LLM API key |
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.
APSA MCPのよくある質問
APSA MCPをClaude Codeに追加するには
ターミナルでclaude mcp add apsa -- uvx apsaを実行します。すべてのプロジェクトで利用するには--scope userを追加します。
APSA MCPをCursorに追加するには
~/.cursor/mcp.jsonを開き、上記のインストールセクションに示すCursor設定を使ってmcpServersの下にサーバーを追加します。
APSAがサポートしているプラットフォームは何ですか?
APSAは、AndroidとiOSの両方のモバイルアプリケーションに対してセキュリティ監査を提供します。
APSAはコンパイル済みのモバイルバイナリを監査できますか?
はい、ソースコードに加えて、APK、AAB、およびIPAビルドを検査できます。
AIエージェントでAPSAを使用するにはどうすればよいですか?
MCP server経由、またはClaude Codeのプラグインとして監査エンジンを使用できます。