スマホアプリ脆弱性診断とは｜発注前に整理する対象と範囲

スマホアプリの脆弱性診断を依頼するとき、Webアプリと同じ依頼書でよいのか、iOSとAndroidをどこまで分けるのかで迷うことがあります。アプリ本体だけを対象にすると、認証、API、配布形態、利用者権限といった条件が後から抜けやすくなります。

結論から言うと、スマホアプリ診断はアプリ本体だけでなく、認証・API・配布形態を含めて対象を確定します。OS名や画面数だけで範囲を決めず、利用者が触れる経路と、アプリが連携する先を一つの対象表にまとめます。

発注前に対象と制約を整理しておけば、依頼先からの質問に答えやすくなり、報告後の修正・再確認の担当も決めやすくなります。この記事では、アプリ運営担当者が準備する情報を、対象、実施条件、報告後の確認に分けて説明します。

本記事で分かること

• モバイル診断で整理する対象
• OS・認証・APIを分ける方法
• 依頼書に書くテスト用情報と制約
• 報告後の修正と再確認の確認点

結論：アプリ本体と連携先を分けて棚卸しする（早見表）

スマホアプリ診断は、アプリ本体、認証、API、配布形態を別々に確認し、相互の関係を対象表に残します。画面が同じように見えても、利用者の権限や連携先が異なれば、発注時に確認する条件も変わります。

発注前に確認する対象

OS名だけで範囲を決めず、利用者が触れる経路を確認します。アプリの画面、ログイン後の操作、連携先、配布する版を対象表に並べ、どの条件で確認するかを記録します。

OSと配布形態

対象表には、iOSとAndroidのどちらを確認するかだけでなく、確認するアプリの版と配布形態を記載します。両方のOSを提供していても、利用者の機能や連携先が同じとは限りません。共通する部分と異なる部分を分け、依頼先にどの版を確認してほしいかを伝えます。

配布形態も、実施環境の準備に関わる条件です。公開中のものか、検証用に用意したものか、配布先を限定しているものかを整理します。確認する版が更新される予定なら、対象表に変更予定と連絡先を残し、依頼後に前提が変わらないようにします。

認証と権限

認証後の画面は、画面名だけでなく、利用者区分と主な操作を対応付けます。一般利用者、管理を担う利用者、社内確認用の利用者など、権限が異なる場合は、それぞれが使う機能を整理します。テスト用の情報を用意する担当と、権限の範囲を決める担当も分けておきます。

認証の方式や利用者の登録状況により、確認できる画面が変わる場合があります。対象外にする権限や、業務上利用できない操作がある場合は、その理由を対象表へ記載します。Webアプリ診断の対象範囲も参照し、認証後の機能を対象一覧に含めるかを発注前に決めます。

APIと外部連携

スマホアプリは、アプリ本体だけで完結せず、APIや外部サービスと連携している場合があります。連携先を対象に含めるかを考える際は、名称だけでなく、誰が管理しているか、どこまで承諾を得られるか、どの環境で確認するかを整理します。

外部サービスを利用しているだけの場合は、自社の判断だけで確認対象に含めません。管理者や契約上の窓口を確認し、対象にできない範囲は対象外として残します。アプリ本体と連携先を同じ行にまとめず、関係を追える形で別行にすると、見積条件を説明しやすくなります。

依頼書に書く条件

対象一覧は画面数だけでなく、テスト用情報と制約を含めます。実施環境、時間帯、変更予定、連絡窓口を事前にそろえ、想定外の影響が疑われる場合に誰が判断するかを決めます。

テスト用アカウント

テスト用アカウントは、利用者区分ごとに必要な権限と、利用できる範囲を整理して準備します。実在の利用者情報をそのまま渡すのではなく、社内の取扱いルールに沿って用意できる情報と、確認が必要な情報を分けます。提供方法と利用期限も、連絡窓口と合わせて記載します。

利用者区分ごとに確認できる画面が異なる場合は、どのアカウントでどの機能を確認する想定かを対象表に書きます。アカウントを提供できない機能があれば、対象外にする理由と、別の確認方法を検討する担当を残します。情報を渡すこと自体を完了条件にせず、使える範囲を共有します。

実施環境と時間帯

実施環境では、確認するアプリの版、利用する環境、業務上避ける時間帯を整理します。通常の利用が集中する時間帯や、連携先の保守予定がある時間帯を事前に共有すると、実施条件を調整しやすくなります。環境名だけでなく、どの版に対応するかを明記します。

本番に近い環境を使う場合は、利用できる操作と、実施中に確認すべき連絡先を決めます。本番で行うかどうかは、アプリの利用状況、対象機能、運用上の制約を踏まえて関係者で判断します。判断結果と制約を依頼書に残し、見積書の条件と照合します。

変更凍結と連絡窓口

対象となる版や連携先に変更予定がある場合は、診断中に変更を避ける期間と、変更が必要になった場合の連絡方法を決めます。変更を完全に止められない場合も、どの変更を共有するか、誰が対象範囲への影響を判断するかを記録します。

連絡窓口は、通常の質問を受ける担当と、予定外の影響が疑われる場合に判断する担当を分けます。セキュリティ診断の発注ガイドを参考に、対象、期限、担当をそろえてから見積を依頼します。連絡体制を先に決めることで、依頼後の調整を進めやすくなります。

報告後に確認すること

指摘の優先度と修正確認の範囲を先に合意します。報告書に対象がどのように記載されるか、誰が修正を担うか、どこまで再確認するかを確認し、結果を次の作業へつなげます。

報告書の対象記載

報告書を受け取ったら、対象にしたOS、確認したアプリの版、認証後の権限、連携先が、発注時の対象表と対応しているかを確認します。対象外にした範囲も記載されていれば、今回確認していない領域を関係者と共有しやすくなります。

報告内容を読む担当だけでなく、対象表を確認する担当も決めておきます。対象の認識が発注時と異なる場合は、どの条件が違っていたかを整理し、追加確認が必要かを判断します。報告書を保管するだけでなく、対象と結果を結び付けることが重要です。

修正の担当分担

修正が必要になった場合は、アプリ本体、API、外部連携、運用設定のどこを誰が担当するかを分けます。一つの指摘でも複数の担当が関わる場合があるため、修正の窓口と完了を確認する担当を決めます。修正予定が別のリリースに入る場合は、対象表と変更予定を更新します。

修正内容を共有するときは、開発担当だけでなく、アプリの運用や利用者への影響を確認する担当にも伝えます。診断結果をそのまま作業依頼に転記するのではなく、自社の変更管理の方法に沿って、担当、期限、確認する範囲を整理します。

再確認の条件

再確認では、どの指摘に関係する機能を確認するか、どの版を対象にするか、結果をどの形式で受け取るかを決めます。修正の対象が認証や連携に関わる場合は、関連する利用者区分やAPIも含めて範囲を確認します。追加の変更があった場合は、当初の対象との違いを記録します。

手動診断とツール診断の違いを参照し、確認方法の名称だけでなく、再確認で何を確認するかを仕様にします。報告書の対象記載、修正担当、再確認の条件を対応付ければ、次のリリース計画にも反映しやすくなります。

まとめ

スマホアプリ脆弱性診断では、アプリ本体、認証、API、配布形態を一つの対象表に整理します。テスト用アカウント、実施環境、変更予定、連絡窓口を発注前にそろえ、報告後の修正・再確認の担当まで決めると、条件の違いを追いやすくなります。

対象範囲の整理は、Webアプリ診断の対象範囲と、お役立ち記事一覧から確認できます。