LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

モバイルアプリのセキュリティ診断とは

モバイルアプリのセキュリティ診断とは、iOS・Androidアプリに潜む脆弱性や設計上のセキュリティ欠陥を専門的な手法で洗い出し、修正すべき問題を報告書としてまとめる評価活動を指します。自社サービスのアプリを外部の診断専門会社に委託して実施するケースが多く、開発者自身では見つけにくい認証バイパスや通信の暗号化不備、不適切なデータ保存などを体系的に検出できます。

セキュリティ診断が必要とされる背景には、モバイルアプリが扱うデータの機密性の高まりがあります。金融・医療・HR・ECなどのアプリは個人情報や決済情報を扱うため、脆弱性が悪用された場合の影響範囲が広くなります。また、アプリのバイナリはストアからダウンロード可能であるため、攻撃者がリバースエンジニアリングで内部ロジックを解析するリスクがWeb系より高いという特性もあります。

「セキュリティ診断」「脆弱性診断」「ペネトレーションテスト」はしばしば混同されますが、役割が異なります。脆弱性診断は既知の脆弱性パターンをスキャンして網羅的に検出することに重点を置きます。ペネトレーションテスト（ペンテスト）は実際の攻撃者の視点で侵入経路を探索し、攻撃シナリオを実証することが目的です。セキュリティ診断はこれらを含む総称として使われることが多く、依頼時に「どの手法を含むか」を確認することが大切です。

OWASP MASVS/MASTG — iOS/Android共通の診断基準

OWASP MASVS（Mobile Application Security Verification Standard）とは、モバイルアプリが備えるべきセキュリティ要件を体系化した国際標準であり、iOS・Androidの両プラットフォームに共通して適用できる「物差し」として機能します^*1。開発・調達・診断のいずれの場面でも参照でき、「何をどこまで検証すべきか」という基準の共通言語となります。

MASVSの要件は大きく次の領域に分かれています。

• ストレージ：機密データを端末にどう保存するか（Keychain・Keystoreの適切な利用、ログへの平文書き出し防止など）
• 暗号：暗号アルゴリズムの選定・鍵管理の適切さ（弱い暗号スイートの排除、ハードコードされた鍵の禁止など）
• 認証・認可：セッション管理・多要素認証・権限昇格の防止
• ネットワーク通信：TLSの正しい実装・証明書検証・Certificate Pinningの要否
• プラットフォーム連携：IPC（プロセス間通信）・WebView・パーミッションの適切な利用
• コード品質：デバッグ設定・例外処理・サードパーティライブラリの脆弱性管理
• リバースエンジニアリング・改竄耐性：難読化・ルート検出・デバッガ検出などの耐タンパー性

MASTG（Mobile Application Security Testing Guide）はMASVSの各要件を実際に検証するための手法ガイドです^*1。iOSテストガイドとAndroidテストガイドに分かれており、使用するツールや確認手順が具体的に記述されています。診断会社への依頼時には「MASTGに準拠した手法で実施するか」を確認することで、診断の実施内容を客観的に評価できます。

2024年にはMASWE（Mobile Application Security Weakness Enumeration＝モバイルアプリ脆弱性の分類体系）がOWASP MASプロジェクトに加わり、MASVS要件・MASTG手法・個別の脆弱性分類が統合されました^*1。これにより「要件→弱点→テスト手法」のトレーサビリティが整い、報告書の記載内容と標準要件を照合しやすくなっています。

調達時の活用として、発注先の評価や契約仕様書にMASVSのレベル（MASVS-L1相当・L2相当）を明示する使い方があります。診断スコープをMASVSの章立てで指定することで、何をどこまで確認するかを発注者・受注者間で明確に合意できます。

診断を外注で進める流れ — 対象範囲定義から再診断まで

モバイルアプリのセキュリティ診断を外注で進める際は、対象の明確化から再診断までを5つのフェーズで整理するとスムーズです。各フェーズで決めるべき事項と、対応を誤った場合のリスクをあわせて押さえておくことが大切です。

フェーズ1：診断対象範囲の定義

最初に「何を診断するか」を明確にします。アプリ全体を対象にするのか、認証・決済・ファイル保存など特定の機能に絞るのかによって診断工数が大きく変わります。

対象の定義が曖昧なまま発注すると、診断会社が前提とする範囲と発注者が期待する範囲にずれが生じ、重要な機能が診断から漏れるリスクがあります。iOS・Androidの両OSを対象にするか、バックエンドAPIも含めるかも事前に決めておく必要があります。

フェーズ2：診断方式の選択

静的解析（SAST＝ソースコードやバイナリの解析）、動的解析（DAST＝実行中のアプリと通信の解析）、手動ペネトレーションテストの3方式から、目的と予算に応じて組み合わせを決めます。

自動ツール中心の診断はコストを抑えて既知の脆弱性パターンを網羅できますが、認証ロジックのバイパスや業務フロー固有の欠陥は手動でないと検出が難しい場合があります。OWASP MASTGでは手動テストを含む組み合わせが推奨されています^*1。

フェーズ3：診断の実施

診断会社にアプリのビルド（またはTestFlightリンク・APKファイル）と必要に応じてテスト用アカウントを提供します。通信解析が必要な場合はテスト環境のAPIエンドポイントを用意することも求められます。

診断期間中は開発チームが質問に対応できる体制を整えておくと、診断の精度が上がります。業務ロジックの確認が必要な場面では、開発担当者へのヒアリングが診断品質に直結します。

フェーズ4：報告書の受領と優先度確認

報告書には発見された脆弱性がリスクレベル（Critical・High・Medium・Lowなど）と再現手順とともに記載されます。Critical・High に分類された問題はリリース前に修正することが基本です。

報告書の質は診断会社によって差があります。問題の再現手順・影響範囲・推奨する修正方針が具体的に書かれているかどうかを評価ポイントにすると、開発チームへの還元がしやすくなります。

フェーズ5：修正後の再診断（リテスト）

修正が完了したら、報告された脆弱性が適切に解消されているかを再診断で確認します。修正したつもりでも根本原因が残っているケースがあるため、再診断は省略しないことが大切です。

再診断対応の可否と費用を最初の発注時に確認しておくことで、修正サイクルを円滑に回せます。再診断を別契約にする会社と、初回費用に含む会社があるため、見積もり段階で確認することをお勧めします。

診断方式と費用の考え方 — 自動ツールと手動ペンテストの違い

モバイルアプリのセキュリティ診断にかかる費用は、診断方式・対象機能数・iOS/Android両対応の有無によって幅が大きく変わります。費用を左右する主要な要因は「自動ツール診断中心か、手動ペネトレーションテスト中心か」という診断方式の選択です。

自動ツール診断（SAST/DAST中心）の特徴

静的解析ツールや動的解析ツールを中心とした診断は、既知の脆弱性パターンを網羅的にスキャンするのに向いています。ハードコードされた認証情報・弱い暗号スイート・不適切なログ出力など、コーディングレベルの問題を効率よく検出できます。

一方で、業務ロジックに依存する認可バイパスや、複数ステップにまたがる攻撃シナリオは自動ツールでは検出が難しく、手動検証が必要です。費用は機能数・対象スコープによって変動しますが、自動ツール中心の軽易な診断では数十万円程度から実施できる場合があります（市場参考値・一次資料ではありません）。

手動ペネトレーションテスト（MASTG準拠）の特徴

OWASP MASTGに準拠した手動ペネトレーションテストは、セキュリティ専門家が実際の攻撃者の視点でアプリを検証します。認証フローのバイパス・Certificate Pinningの回避確認・リバースエンジニアリングへの耐性など、自動ツールでは検出しにくい問題を発見できます。

診断に必要なスキルとして、iOS（Swift/Objective-C・Frida・objection等のツール）とAndroid（Kotlin/Java・Jadx・Burp Suite等）のプラットフォーム固有知識が求められます。専門家が時間をかけて確認するため、費用は自動診断より高くなる傾向があり、本格的な手動ペンテストを含む診断では数百万円規模になる場合もあります（市場参考値・一次資料ではありません）。

費用はいずれも市場参考値であり一次資料に基づく確定値ではありません。対象機能数・iOS/Android両対応・バックエンドAPIの有無によって変動幅が大きいため、要件を整理したうえで複数の診断会社に見積もりを依頼することが費用管理の前提となります。

費用を左右するその他の要因

• iOS/Android両OS対応：片方のみと比べて工数が増加します。プラットフォーム固有の実装差異はそれぞれ検証が必要です。
• バックエンドAPIの有無：モバイルアプリと通信するAPIを診断スコープに含める場合、Web診断と組み合わせる形になり費用が上がります。
• 再診断（リテスト）の回数：修正後の確認を何回行うかによってトータルコストが変わります。
• ソースコードの提供有無：ソースコードを提供するホワイトボックス診断はより深い静的解析が可能ですが、提供可否は発注側の判断が必要です。

委託先（診断会社）の選び方 — MASVS準拠・報告書・再診断・開発還元の4軸

モバイルアプリのセキュリティ診断会社を選ぶ際は、一般的なWebアプリ診断との違いを踏まえた評価が必要です。iOS/Androidのプラットフォーム固有の知見と、OWASP MASVSを実際の診断に組み込める実績が委託先選定の核となります。評価軸を4点に整理します。

評価軸1：MASVS/MASTGに基づく診断の実施実績

提案書や実績資料に「OWASP MASVS準拠」「MASTGの手法を採用」という記載があるかを確認します。単に「モバイルアプリ診断の経験がある」だけでなく、MASVSのどの領域をどの手法で確認するかを具体的に説明できる会社を選ぶことが大切です。

iOS・Androidの両プラットフォームに対応できるか、またはどちらか一方のみかも確認ポイントです。自社アプリが両OS対応であれば、両方を診断できる体制を持つ会社への依頼が効率的です。

評価軸2：報告書の具体性と再現手順の詳細さ

診断報告書のサンプルを事前に確認できる会社では、記載の具体性を評価できます。脆弱性の再現手順・影響範囲・MASVSのどの要件に対応するか・推奨する修正方針が明記されているかが品質の指標となります。

「脆弱性が存在する」という指摘だけで修正方針が書かれていない報告書では、開発チームが何をすべきかわからず、修正コストが増大するリスクがあります。開発に還元できる具体性があるかを評価してください。

評価軸3：再診断（リテスト）対応の可否と費用

修正後の再確認を同一の診断会社が実施できるかどうかを確認します。再診断を初回費用に含む会社と別途費用が発生する会社があるため、総コストで比較することが重要です。

修正確認を別会社に委託すると、初回診断と再診断の間で前提条件の共有が必要になり、追加の工数が発生します。再診断まで一貫して対応できる会社を選ぶ方が、修正サイクルを効率よく回せます。

評価軸4：開発プロセス（SDLC）への還元サポート

単発の診断にとどまらず、検出した脆弱性を開発プロセスの改善に活かすための助言ができる会社かどうかも評価に加えるとよいでしょう。OWASP MASのドキュメントでは、セキュリティ診断をSDLC（ソフトウェア開発ライフサイクル）の中に組み込むことが推奨されています^*1。

診断会社が「この脆弱性はコーディング規約で防ぐべき問題」「設計レビューで検出できる問題」のように分類して説明してくれると、次のリリースサイクルから予防的な対策を組み込めます。再発防止策の提案を報告書に含めるかどうかも、発注前に確認することをお勧めします。

まとめ：モバイルアプリ診断外注で押さえる3つの判断軸

本稿では、モバイルアプリのセキュリティ診断を外注で進める際の基準・フロー・費用・委託先選定を整理しました。要点を3点に集約します。

第一に、OWASP MASVSはiOS/Android共通の診断基準として機能します。ストレージ・暗号・認証・ネットワーク・プラットフォーム連携・コード品質・改竄耐性という7領域の要件を物差しにすることで、発注スコープの定義と診断結果の評価を客観的に行えます。2024年にMASWEが統合されたことで、要件から脆弱性・テスト手法までのトレーサビリティもより整っています。

第二に、診断方式の選択が費用と検出できる脆弱性の深度を決めます。自動ツール診断は網羅性に優れ、手動ペネトレーションテストは業務ロジック固有の欠陥や改竄耐性を検証できます。OWASP MASTGでは両者の組み合わせが推奨されており、リスクレベルと予算に応じた方式を選ぶことが大切です。

第三に、委託先の評価はMASVS準拠の実績・報告書の具体性・再診断対応・開発還元の4軸で行うことが有効です。報告書の質は開発チームへの還元効率に直結するため、サンプルの確認と再診断費用の事前確認を実施することをお勧めします。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OWASP「OWASP Mobile Application Security」（https://mas.owasp.org/）— MASVS・MASTG・MASWEの概要・章立て・更新状況（2024年MASWE統合を含む）

Tweet