MobSFとは？Dockerでの導入と動的解析の対応版・REST APIまで解説

MobSF（Mobile Security Framework）は、AndroidのAPKやiOSのIPAの静的解析とレポート生成に対応し、対応端末や接続設定を別途用意すれば動的解析も行えるオープンソースのモバイルアプリ診断基盤です。Dockerで起動できますが、動的解析には対応OSのイメージと端末への接続設定が別途必要です。MobSFが動的解析に使えるAndroidはバージョン11（API 30）までで、しかもroot権限のあるイメージに限られます。この記事では、2026年8月10日に公開されたv4.5.2を前提に、起動からログイン、レポートの読み方、REST APIでのCI/CD連携までを公式リポジトリの実装にあたって整理します。

まとめ：MobSFの導入・解析・自動化の要点

• 最新の安定版はv4.5.2（2026年8月10日公開）。ライセンスはGPL-3.0-only、リポジトリのスター数は約21,800。
• 最短の起動はdocker run -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latestで、初期の認証情報はmobsf/mobsf。
• 動的解析が使えるのはAndroid 4.1〜11.0（API 30まで）のroot済みVM／エミュレータのみ。Google Playストア入りのイメージとAndroid 12以降は使えない。
• iOSの動的解析はCorelliumか、v4.5.1以降でベータ提供されている脱獄済み実機。非脱獄の実機とiOSシミュレータには対応しない。
• REST APIの認証キーは認証を無効化しても必須。鍵は~/.MobSF/secretのSHA-256か、環境変数MOBSF_API_KEYで固定できる。
• ソースコードをCIで継続的に検査したいだけなら、本体ではなく同じ開発元のmobsfscanを使う。GitHub Actionが公式に用意されている。

MobSFの解析機能と対応ファイル形式

MobSFはAndroid・iOS・Windows Mobileのアプリを対象にしたセキュリティリサーチ基盤で、公式リポジトリは静的解析エンジン・動的解析エンジン・REST APIの3つを1つのDjangoアプリケーションにまとめています。静的解析はバイナリとソースコードの両方を受け付け、動的解析はインストゥルメンテーションによる実行時の挙動観測とHTTPSトラフィックの傍受を担当します。ツールの位置づけとしては、コードを実行せずに問題を探す静的解析とは？実行せずに欠陥を見つける仕組みとツールの選び方で扱う手法を、モバイルアプリのバイナリに特化させたものと考えると整理しやすくなります。

受け付けるファイル形式は設定ファイルmobsf/MobSF/settings.pyに定数として定義されています。

zipはAndroidのソースコード一式を指し、iOSのソースコードもzipで受け付けます。Windowsへ直接導入したMobSFではIPA解析ができないこと、逆にAPPX解析にはWindowsホストかWindows VMが必要なことは公式の要件に明記されているので、解析対象が複数プラットフォームにまたがるならDockerで揃えるのが無難です。

解析結果はWeb UIのほか、PDFとJSONで出力できます。静的解析の検出ルールにはCWE番号、OWASP Mobile Top 10の項目、MASVSの識別子が紐づいており、レポートの指摘をそのまま基準へマッピングできます。OWASP側の全体像はOWASPとは？主要プロジェクトの全体像とアプリ開発への組み込み方【2026年時点】で整理しています。

Dockerで動かす最短手順

公式はDocker Hubの配布イメージを案内しています。以下のlatestタグは更新されるため、常に本記事の前提であるv4.5.2と一致するとは限りません。再現性が必要な運用では、確認したイメージのダイジェストを記録して固定します。Dockerは20.10.0以上が推奨されています。

docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

起動後、ブラウザでhttp://127.0.0.1:8000を開き、mobsf/mobsfでログインします。この状態ではコンテナを落とすと解析結果が消えるため、継続して使うならホスト側のディレクトリを/home/mobsf/.MobSFにマウントします。コンテナ内のMobSFユーザーはUID 9901で動くので、マウント元の所有者を合わせておく必要があります。

mkdir mobsf_data
sudo chown -R 9901:9901 mobsf_data
docker run -it --rm --name mobsf -p 8000:8000 -v $(pwd)/mobsf_data:/home/mobsf/.MobSF opensecurity/mobile-security-framework-mobsf:latest

ボリュームを持ったままイメージを更新したときは、データベーススキーマの変更を当てるためにマイグレーションを実行します。更新でデータベーススキーマが変わった場合、マイグレーションを省くと静的解析の保存時に「no column named」などの例外が出ることがあります。

docker pull opensecurity/mobile-security-framework-mobsf:latest
docker run --rm -v $(pwd)/mobsf_data:/home/mobsf/.MobSF opensecurity/mobile-security-framework-mobsf:latest scripts/migrate.sh

Dockerでの主な挙動の切り替えには、環境変数を使えます。よく使うものを挙げます。

非同期スキャンでは、MobSFとDjangoQ2を別コンテナで起動し、同じボリュームを共有させます。次の例は各コマンドを別のターミナルで実行してください。Linuxではマウント元の ~/.MobSF を事前に作成し、UID・GID 9901で書き込めるようにします。大量のAPKをまとめて流すときはこの構成にしないと、Webワーカーが解析中に応答を返せなくなります。

docker run -it --rm --name mobsf -v ~/.MobSF:/home/mobsf/.MobSF -e MOBSF_ASYNC_ANALYSIS=1 -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
docker run -it --rm --name djangoq -v ~/.MobSF:/home/mobsf/.MobSF opensecurity/mobile-security-framework-mobsf:latest scripts/qcluster.sh

PostgreSQLとNginxリバースプロキシを含む構成は、リポジトリのdockerディレクトリにあるCompose定義で起動できます。コンテナイメージそのものの脆弱性をCIで見る話はDockerの脆弱性診断をCI/CDに組み込む手順とツール選定が別記事として扱っています。

ホストに直接インストールするときの要件

Dockerを使わずMac・Linux・Windowsへ直接入れる場合、公式が示すシステム要件はメモリ8GB以上、CPU 3GHz、空きディスク80GB以上です。jadxによる逆コンパイルとツール類のダウンロードで容量を使うため、数GBの空きでは足りません。

導入はリポジトリを取得してセットアップスクリプトを走らせるだけです。MacとLinuxは./setup.sh、Windowsはsetup.batで、起動はそれぞれ./run.shとrun.batです。

git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git
cd Mobile-Security-Framework-MobSF
./setup.sh
./run.sh 127.0.0.1:8000

引数を付けずに起動スクリプトを叩くと0.0.0.0:8000で待ち受けます。共有環境やクラウド上のサーバで動かすときは、意図せず外部公開しないよう待ち受けアドレスを明示してください。Windowsではsetup.batの実行前にMobSFのフォルダをエクスプローラやエディタで開いたままにしないこと、という注意も公式に書かれています。ファイルロックでセットアップが途中で失敗するためです。

なお、ユーザー独自の設定を書くファイルは~/.MobSF/config.py（Dockerではマウント先の.MobSF配下）で、初回起動時に生成されます。設定項目の大半は前掲の環境変数でも上書きできるので、コンテナ運用なら環境変数だけで足ります。

ログイン情報とAPIキーの扱い

MobSFの認証・認可はv4.0.7で追加された機能で、Web UIにはmobsf/mobsfでログインします。Dockerイメージではこの初期ユーザーがDJANGO_SUPERUSER_USERNAMEとDJANGO_SUPERUSER_PASSWORDで作られるため、そのまま外部へ公開するとログイン画面が既知の認証情報で開いてしまいます。社内であっても待ち受けアドレスを絞り、初回ログイン後にパスワードを変更してください。

検証環境で認証が煩わしい場合はMOBSF_DISABLE_AUTHENTICATION=1で無効化できますが、REST APIのキーはこの設定に関係なく常に必須です。公式FAQも「REST APIは常にAPIキーを要求し、これは無効化できない」と明記しています。

キーの決まり方は実装上3段階です。MOBSF_API_KEY_FILEがあればそのファイルの中身、なければ環境変数MOBSF_API_KEYの値、どちらも無ければ~/.MobSF/secretの内容のSHA-256ハッシュが使われます。つまり何も指定しなければインスタンスごとにキーが変わるので、CIから叩くならMOBSF_API_KEYで固定するのが実務的です。リクエスト時のヘッダはX-Mobsf-Api-KeyかAuthorizationのどちらかで、値はキーそのものです。トークン種別を表す接頭辞は付けません。

API呼び出しにはレート制限がかかり、既定は毎分7リクエストです。大量のAPKを回すバッチではMOBSF_RATELIMITを明示的に引き上げてください。

静的解析レポートとセキュリティスコアの読み方

静的解析を実行すると、コード解析の指摘、権限、ネットワークセキュリティ設定、トラッカー、ハードコードされた秘密情報の候補などが1画面にまとまります。最初に目に入るのが100点満点のSecurity Scoreですが、この値は脆弱性の深刻度を重み付けした指標であって、検出件数そのものではありません。算出式は実装（v4.5.2のappsec.py）にそのまま書かれています。

high = high判定の件数
warn = warning判定の件数
sec  = secure判定の件数
total = high + warn + sec

score = int(100 - ((high * 1 + warn * 0.5 - sec * 0.2) / total) * 100)
（totalが0なら0、100を超えたら100に丸める）

secure判定が減点を打ち消す方向に効くため、「安全側の項目が多いアプリほどスコアが上がる」構造になっています。画面に表示されるグレードはスコアの区分で、境界値も実装で固定されています。

スコアの分母はhigh・warning・secureの合計で、infoとhotspotは含まれません。アプリの機能数と、この集計対象の件数は同じではありません。リリース判定の閾値に使うなら、絶対値で線を引くのではなく、同じアプリの前回スキャンとの差分で見るほうが安定します。ハードコードされた秘密情報の候補は既定でwarning、設定によってはhotspot（要確認）として分類され、誤検出も混ざるため人の確認が前提です。指摘の優先順位付けをチーム内で決める枠組みは脅威モデリングとは？STRIDEでの脅威抽出手順とツール選定を実装目線で解説が参考になります。

動的解析の前提条件

動的解析では、OSバージョンとroot権限の条件を先に確認します。動的解析は「Androidエミュレータなら何でもよい」わけではなく、公式が対応を明言している組み合わせが限られます（出典はMobSF公式ドキュメントのセットアップ要件）。

Android 12以降が対象外なのは、新しいAVDが書き込み可能な/systemを提供しなくなったためです。Google Playストア入りのイメージはプロダクションイメージ扱いでroot権限が取れないため、AVDを作る段階でPlayストアなしのイメージを選ぶ必要があります。ここを間違えると、MobSFのDynamic Analyzer画面までは進めても端末が検出されません。

起動順序も決まっています。Android VMを先に立ち上げ、デバイス識別子を確認してからMobSFを起動します。Genymotionならタイトルバーに表示されるIPとポート5555の組み合わせ、Android Studioのエミュレータならemulator-5554のようなシリアルです。リポジトリのscripts/start_avd.sh（Windowsはstart_avd.ps1）を使うと、利用可能なAVDの一覧表示と起動、識別子の出力までやってくれます。

docker run -it --rm -p 8000:8000 -p 1337:1337 -e MOBSF_ANALYZER_IDENTIFIER=emulator-5554 opensecurity/mobile-security-framework-mobsf:latest

Linuxホストでは、コンテナからホスト側のエミュレータへadbが届きません。Docker 20.10.0以上で--add-host=host.docker.internal:host-gatewayを追加し、start_avd.shが案内するsocatの転送ポートを識別子に指定します。

sudo apt install socat
scripts/start_avd.sh Pixel_5_API_30
# 出力された MOBSF_ANALYZER_IDENTIFIER=host.docker.internal:5556 を使う

docker run -it --rm -p 8000:8000 -p 1337:1337 --add-host=host.docker.internal:host-gateway -e MOBSF_ANALYZER_IDENTIFIER=host.docker.internal:5556 opensecurity/mobile-security-framework-mobsf:latest

公開している2つ目のポート1337は、MobSFが内蔵するHTTPSプロキシです。通信内容を傍受するために端末のグローバルプロキシをここへ向けますが、公式ではAndroid Studioエミュレータの9.0以上とGenymotionの4.4以上でプロキシが自動設定されます。Android Studioエミュレータの5.0〜8.0でも自動設定を試みますが、失敗した場合は手動設定が必要です。傍受した通信をさらに細かく触りたい場合は、Burp Suiteとは？通信傍受の仕組みとエディションの選び方・初期設定やOWASP ZAPの診断項目とは？検出できる脆弱性一覧と使い方で扱うプロキシツールを上流に挟む構成が使えます。

APKのインストールに失敗する典型はINSTALL_FAILED_NO_MATCHING_ABISです。x86系のエミュレータにARM向けネイティブライブラリを含むAPKを入れようとしたときに出るもので、対象アーキテクチャに合ったAPKを用意するか、ARMアーキテクチャのエミュレータを使う必要があります。

REST APIとCI/CDへの組み込み

MobSF本体にAPKをスキャンするコマンドラインツールはありません。mobsfコマンドはサーバを起動するエントリポイントで、自動化の窓口はREST APIです。mobsf/MobSF/urls.pyに定義されている主なエンドポイントは次のとおりです。

hashとして渡すのはアップロード時に返るMD5で、形式が違えばエラーになります。scan APIではhashが欠けると422、不正なhashや未登録のファイルを指定すると500が返ります。ほかのAPIはエラー条件とステータスが異なります。curlで一巡させると次の3ステップです。

# このシェルの MOBSF_API_KEY に、接続先MobSFと一致するAPIキーを設定してから実行する
: "${MOBSF_API_KEY:?接続先MobSFのAPIキーを設定してください}"
KEY=$MOBSF_API_KEY

# 1. アップロード（レスポンスの hash を控える）
curl -s -F '[email protected]' -H "Authorization: $KEY" http://127.0.0.1:8000/api/v1/upload

# 2. 静的解析の実行
curl -s -X POST --data 'hash=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' -H "Authorization: $KEY" http://127.0.0.1:8000/api/v1/scan

# 3. スコアカードだけ取得してCIの合否判定に使う
curl -s -X POST --data 'hash=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' -H "Authorization: $KEY" http://127.0.0.1:8000/api/v1/scorecard

ビルド成果物のAPK／IPAをCIで検査するには、この流れにhashの自動取得、HTTPエラー時の停止、解析完了の確認、指摘内容に基づく合否判定を加えます。一方、ソースコードの安全でない実装パターンをプルリクエストごとに検査したいなら、同じ開発元が出しているmobsfscanのほうが適しています。こちらはMobSFの静的解析ルールをsemgrepとlibsastで回す単体のCLIで、Java・Kotlin・Android XML・Swift・Objective-C・Info.plistに対応し、出力形式にSARIF 2.1.0、SonarQube、GitLab SASTを持っています。GitHub Actionも公式に提供されています。

name: mobsfscan
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v5
    - uses: actions/setup-python@v6
      with:
        python-version: '3.12'
    - name: mobsfscan
      uses: MobSF/mobsfscan@main
      with:
        args: '. --json'

掲載例はJSONをジョブログへ出力します。GitHubのコード スキャンへ連携する場合はSARIFファイルを生成し、security-events: writeの権限とSARIFのアップロード処理を追加します。ライセンスは本体がGPL-3.0-onlyなのに対し、mobsfscanはLGPL-3.0で、必要なPythonは3.10から3.14です。このあたりの棲み分けは、依存パッケージ側の脆弱性を見るSnykとは？CLIでの脆弱性スキャンとCI組み込み・料金の実額を実装視点で解説のようなツールと組み合わせて考えると決めやすくなります。

よくある質問

MobSFは無料で商用利用できますか？

本体はGPL-3.0-onlyのオープンソースで、自社の診断業務に使うこと自体に費用はかかりません。改変したMobSFのコピーを外部へ配布する場合は、GPLに従ったライセンス付与と対応するソースコードの提供が必要です。ただし、コピーを渡さずネットワーク越しに利用させるだけで、一般公開義務が生じるわけではありません。自社サービスへ組み込む前にライセンス条件を法務と確認してください。優先的な機能要望やオンサイト研修が必要な場合は、開発元が有償のエンタープライズサポートを提供しています。

Android 13や14の端末で動的解析できますか？

できません。公式ドキュメントは動的解析の対応をAndroid 4.1から11.0（API 30まで）のroot済み環境に限定しており、12以降は非対応と明記しています。理由は新しいイメージで/systemが書き込み不可になったためで、設定で回避する手段は用意されていません。新しいOSでの挙動を見たい場合は、実機とFridaを直接使う構成など、MobSF以外の手段を検討することになります。

コマンド1つでAPKをスキャンできませんか？

本体にその用途のCLIはありません。mobsfコマンドはDjangoサーバを起動するためのもので、解析の実行はWeb UIかREST API経由になります。CIから使うなら/api/v1/uploadと/api/v1/scanをcurlで叩くか、ソースコード検査に絞ってmobsfscanを使ってください。

Windowsだけで全機能を動かせますか？

できない部分があります。iOSのIPA解析はMac・Linux・Dockerコンテナでのみ動作します。逆にWindowsアプリ（APPX）の解析にはWindowsホストかWindows VMが必要なので、両方を扱うならDockerでMobSFを動かしつつ、APPX解析だけWindows側に寄せる構成になります。

公開されているmobsf.liveをそのまま使ってよいですか？

開発元が静的解析を試せるオンライン版として案内しているものなので、手元に環境を作る前の動作確認には使えます。ただしアップロードしたAPKやIPAは第三者のサーバへ送られます。未公開アプリや顧客から預かったバイナリは対象にせず、自前のインスタンスを立てて解析してください。

関連記事

• 静的解析とは？実行せずに欠陥を見つける仕組みとツールの選び方
• OWASP ZAPの診断項目とは？検出できる脆弱性一覧と使い方
• Burp Suiteとは？通信傍受の仕組みとエディションの選び方・初期設定
• Dockerの脆弱性診断をCI/CDに組み込む手順とツール選定
• OWASPとは？主要プロジェクトの全体像とアプリ開発への組み込み方【2026年時点】