モバイルセキュリティのボトルネック
50以上の社内Androidアプリを手動で監査するのは、燃え尽き症候群への近道です。私のチームもかつては、2週間ごとのアップデートの波に飲まれ、apktoolやdex2jar、jd-guiを駆使して格闘していました。それはまるで、錆びたドライバー1本でTeslaを再構築しようとするようなものでした。プロセスは遅く、ヒューマンエラーが発生しやすく、開発チームの成長に合わせてスケールさせることは不可能でした。
現代のAndroidアプリは巨大です。一般的なエンタープライズ向けAPKは、15以上の異なるAPIを呼び出し、40以上のサードパーティ製依存関係を取り込んでいることも珍しくありません。
これらのライブラリの多くは2021年以来更新されておらず、攻撃対象領域（アタックサーフェス）を無防備な状態にさらしています。もし今でも手動でAPKをデコンパイルしているなら、ハードコードされたAWSキー、安全でないローカルストレージ、設定ミスのあるIntentといった重大な欠陥を見逃している可能性があります。ローカルマシンを壊れたJavaの依存関係の墓場にすることなく、CI/CDパイプラインにセキュリティを組み込む方法が必要でした。
コアコンセプト：なぜMobSFとDockerなのか？
Mobile Security Framework (MobSF)は、オールインワンのモバイルペネトレーションテストにおける業界標準です。Android、iOS、Windowsに対応しており、静的解析（SAST）と動的解析（DAST）の両方を実行できます。このガイドでは、コードを実行せずにスキャンするSASTに焦点を当てます。これは、DevOpsフレンドリーなワークフローにおいて、一般的なバグの80%をキャッチする最も速い方法です。
MobSFをネイティブ環境にインストールするのは、非常に手間がかかることで知られています。Python 3.10やOpenJDK 11の特定のバージョン、そして煩雑なシステムレベルのライブラリを要求されるからです。Dockerはこの摩擦を解消します。MobSFをコンテナ化することで、環境の隔離を保証できます。私のLinuxワークステーションでも、あなたのmacOSノートPCでも、あるいはヘッドレスなJenkinsエージェント上でも、ツールは全く同じように動作します。環境の競合も、言い訳も、もう必要ありません。
60秒でMobSFを起動する
開始するには、Dockerさえあれば十分です。OpenSecurityが提供している公式イメージをお勧めします。頻繁に更新されており、高いパフォーマンスを発揮するように事前設定されています。
まず、最新のイメージをローカルレジストリにプルします：
docker pull opensecurity/mobsf:latestダウンロードが完了したら、コンテナを起動します。UIにアクセスできるようにしつつ、終了時にコンテナの一時的な状態を消去するために、以下のフラグを使用します：
docker run -it --rm -p 8000:8000 opensecurity/mobsf:latest内部では以下のような処理が行われています：
-it: リアルタイムのログストリーミングを提供し、デコンパイラの動作を監視できます。--rm: 停止時にコンテナを破棄し、ディスクの肥大化を防ぎます。-p 8000:8000: コンテナのウェブサーバーをローカルブラウザにブリッジします。
ログを確認してください。サーバーの準備が整ったという信号が出たら、http://localhost:8000にアクセスします。最初のターゲットを受け入れる準備が整った、クリーンなダッシュボードが表示されます。
最初のAPKを分析する
MobSFは複雑さを取り除いてくれます。APKをアップロードボックスにドラッグすると、フレームワークがデコンパイル、DalvikからJavaへの変換、パターンベースの脆弱性スキャンという多段階のパイプラインをトリガーします。
先月、レガシーな銀行アプリをテストした際にその真価が証明されました。正確に4分12秒で、MobSFは7つの重大な脆弱性を指摘する50ページの監査レポートを吐き出しました。その一つは、ローカルデータベースの暗号化に使用されていたハードコードされたAESキーでした。このツールが手動作業を何時間も節約してくれる、3つの具体的な領域を見ていきましょう。
マニフェスト分析：容易に発見できる問題の特定
AndroidManifest.xmlはアプリのDNAです。MobSFは即座に「危険な」権限にフラグを立てます。例えば、機密性の高いActivityにandroid:exported="true"が見つかった場合、外部アプリがIntent Injectionを介してそのコンポーネントをハイジャックできる可能性があると警告します。
また、allowBackupフラグもチェックします。これがtrueに設定されていると、物理的なアクセス権を持つ人やADBが有効な人は誰でも、ルート権限なしでセッショントークンを含むアプリのプライベートデータを取得できてしまいます。修正は簡単ですが、開発者が見落としがちなポイントです。
ハードコードされたシークレットの探索
これこそが、自動化が人間の目を上回る部分です。MobSFは、AWSの認証情報、Stripeトークン、Firebase URLなどのパターンに一致する高エントロピーな文字列をスキャンします。難読化された.classファイルの奥深くに埋もれていて、手動の監査人なら特定に数時間はかかったであろう本番環境のAPIキーが発見されるのを何度も見てきました。
シークレットはAPKではなく、安全なヴォルト（Vault）に保管すべきです。インフラを強化する一方で、サーバー側の認証情報には toolcraft.app/ja/tools/security/password-generator にあるようなパスワードジェネレーターを活用しましょう。これは完全にブラウザ内で動作するため、エントロピーがネットワークに流れることはありません。セキュリティは単なるツールセットではなく、マインドセットなのです。
コード分析とバイナリ保護
MobSFは、すべての発見事項をOWASP Mobile Top 10に関連付けます。弱い暗号化（MD5など）、SSLピンニングの欠如、JavaScriptが有効なWebViewインスタンスなどにフラグを立てます。これらはモバイルアプリにおけるクロスサイトスクリプティング（XSS）の侵入口となります。
コード以外にも、バイナリレベルの保護を監査します：
- NX (No-eXecute): スタックからのコード実行を防止します。
- Stack Canaries: バッファオーバーフロー攻撃を防御します。
- ASLR: メモリアドレスをランダム化し、ROPチェーン攻撃を阻止します。
デプロイメントの強化
チームでMobSFを運用しますか？それならlocalhostのままにせず、永続的なバックグラウンドサービスとして実行しましょう。コンテナの再起動時にレポートを失わないよう、ボリュームをマウントします：
docker run -d \
-p 8000:8000 \
-v /home/user/mobsf_data:/home/mobsf/.MobSF \
--name mobsf-server \
opensecurity/mobsf:latest-vフラグにより、ホストマシンの/home/user/mobsf_dataディレクトリが永続化されます。これは、異なるアプリバージョンにわたるスキャン履歴を保持するために不可欠です。
今後の展望
自動化はセキュリティエンジニアに取って代わるものではありません。退屈な作業からあなたを解放してくれるものです。MobSFをコンテナ化することで、現代のDevSecOpsに適合する、再現可能でスケーラブルな監査プロセスを構築できます。次に誰かからAPKを渡され、安全かどうか尋ねられたら、推測で答えるのはやめましょう。コンテナを起動し、スキャンを実行し、データに語らせるのです。
