モバイルバンキングアプリのセキュリティテストガイド

モバイルは今や、顧客が金融機関とやり取りする主要なデジタルチャネルです。最新のバンキングアプリケーションでは、ユーザーが口座残高の確認、送金、請求書の支払い、受取人の管理、本人確認に関する手続きを、モバイル端末から直接行えます。こうしたアプリケーションが顧客体験の中心になるにつれ、金融機関全体のセキュリティ態勢においても、より重要な存在になっています。

モバイルバンキングアプリは極めて機密性の高い金融情報や個人情報を処理するため、サイバー犯罪者にとって魅力的な標的です。攻撃者は、認証情報の窃取、通信の傍受、脆弱なAPIの悪用、金銭目的での取引ワークフローの操作を試みる可能性があります。このリスクは、モバイル環境の性質によってさらに増幅されます。バンキングアプリは金融機関が管理できない端末上で動作し、複数のバックエンドサービスと通信し、複雑な認証、セッション、決済のロジックに依存しています。この組み合わせが、広範で変化し続けるアタックサーフェスを生み出します。

こうした複雑さを踏まえ、金融機関には、端末、ネットワーク、バックエンドシステムにわたってバンキングアプリケーションがどのように振る舞うかを評価できる最新のモバイルセキュリティテストのアプローチが必要です。これにより、チームは弱点をより早く特定し、機密データと重要なワークフローが適切に保護されているかを検証し、エンジニアリングチームに修復のためのより明確な方向性を示せます。

モバイルバンキングのセキュリティテストが重要な理由

モバイルアプリケーションセキュリティテスト（MAST）は、実際の攻撃で悪用される前に脆弱性を特定することで、モバイルバンキングアプリケーションの耐性を評価するために用いられます。効果的なモバイルセキュリティテストは、静的解析、動的評価、実行時の観察を組み合わせ、アプリケーションのコード、実行時の挙動、ローカルストレージ、ネットワーク通信を調べます。最新のモバイルセキュリティテストは、理論上の検出結果を出すだけでなく、ログ、トレース、実行アーティファクトといった技術的なエビデンスも生成でき、エンジニアリングチームが問題を検証し、確信を持って修復の優先順位付けを行えるよう支援します。

モバイル金融アプリケーションは、デジタルエコシステムの中でも特に機密性の高い情報を扱っています。これには、個人の身元データ、認証用のシークレット、口座記録、取引の詳細が含まれます。この環境に影響する弱点は、直接的な金銭的損失だけでなく、評判や規制面でも深刻な影響をもたらす可能性があります。

モバイルバンキングのセキュリティを特に複雑にしている要因はいくつかあります。金融アプリケーションは高額かつ極めて機密性の高いデータを処理するため、当然ながらサイバー犯罪者を引き寄せます。また、iOS、Android、そして状況によってはHarmonyOSなど、多様なハードウェアとオペレーティングシステム上で動作するため、セキュリティチームが考慮すべき技術的な変数が増えます。同時に、ユーザーは信頼できない端末や侵害された端末からこれらのアプリケーションにアクセスする可能性があり、金融機関が完全には管理できない新たな露出が生まれます。

従来のWebアプリケーションと比べて、モバイルアプリには追加のセキュリティ上の考慮事項もあります。モバイルアプリは、ローカルストレージ、実行環境、組み込みコンポーネント、アプリの権限、ディープリンク、モバイル固有のフレームワークに依存しています。そのため組織には、標準的なWebセキュリティの手法を超え、モバイルエコシステム特有の実情を考慮したテスト手法が必要です。

セキュリティテストは、フロントエンドとバックエンドの両方のシステムで保護メカニズムが一貫して機能していることを、金融機関が検証するのに役立ちます。重要なユーザージャーニーにおける弱点を特定し、機密データが安全に扱われているかを検証し、頻繁なリリースやアップデートを通じてアプリケーションが進化してもセキュリティ制御が有効であり続けることを確認できます。既存の弱点の規模を見れば、その重要性が分かります。調査では、ハードコードされたシークレットがアプリの50%以上に影響しており、古いライブラリは46%で見つかりました。

これらの検出結果の背景にあるデータを詳しく知るには、500以上のモバイルバンキングアプリを対象とした大規模調査に基づくBanking Report 2025の全文をお読みください

モバイルバンキングのアタックサーフェス

効果的なセキュリティを実現するには、金融機関はモバイルバンキングを単独のアプリではなく、エコシステム全体として捉える必要があります。一般的なバンキング環境は、クライアント端末、ネットワーク通信層、バックエンドシステムにまたがっています。各層はそれぞれ異なる種類のリスクをもたらし、攻撃者はそのうちの一つだけを狙うのではなく、層をまたいで移動することがよくあります。

クライアントのレベルでリスクにさらされる主なアセットは、ユーザーの認証情報、アプリのロジック、ローカルで処理されるデータです。ネットワーク側では、認証トークン、口座の詳細、取引情報を含む転送中のデータが主な懸念事項です。バックエンドシステムでは、ID管理サービス、金融記録、取引処理のロジックが最も価値の高いアセットです。そのため、モバイルバンキングアプリを保護するには、3つの層すべてにわたって連携したセキュリティ制御が必要です。

層	リスクにさらされる主なアセット	一般的な緩和策
クライアント	ユーザーの認証情報とアプリのロジック	難読化とroot検知
ネットワーク	転送中のデータ	証明書ピンニングと暗号化
バックエンド	個人データと金融データ	堅牢なIAMとAPIゲートウェイ

端末レベルのリスク

モバイルバンキングに対する脅威では、ユーザーの端末が最初の攻撃ポイントになることがよくあります。攻撃者は、アプリの仕組みを理解したり、隠された機能を特定したり、ハードコードされたシークレットを抽出したりするために、アプリケーションのバイナリをリバースエンジニアリングしようとする可能性があります。侵害された端末では、セキュリティ制御を回避したり、実行中のアプリの挙動を変えたりするために、マルウェアの注入や実行時の操作を試みることもあります。金融機関はユーザーの端末の健全性や信頼度を完全には管理できないため、難読化、実行時チェック、ハードニング技術といったアプリケーションレベルの保護が特に重要です。古いアプリケーション基盤がいまだに一般的な市場では、これはなおさら重要です。500以上のモバイルバンキングアプリを対象とした大規模調査では、分析したiOSアプリの25%が2008年から2011年の間に、さらに22%が2011年から2014年の間にリリースされており、Androidアプリの27%は2010年から2013年の間にリリースされていました。

ネットワーク通信のリスク

モバイルバンキングアプリケーションは、認証、口座へのアクセス、決済フローのために、バックエンドのAPIとの通信に大きく依存しています。この通信が適切に保護されていなければ、攻撃者は中間者攻撃（MitM）によってトラフィックを傍受または改ざんしようとする可能性があります。これにより、転送中の認証トークン、セッションデータ、取引の詳細が露出するおそれがあります。このリスクを減らすには、強固なトランスポートセキュリティ、証明書の検証、安全なセッション処理が不可欠です。脆弱なトランスポートの実装がいまだに残っていることも、この点を裏付けています。分析したバンキングアプリの20%では、いまだに平文のHTTPが見つかっています。

バックエンドシステムのリスク

モバイルクライアント自体が十分に保護されていても、バックエンドの認証、認可、取引検証に弱点があれば、不正やデータ漏えいにつながる可能性があります。攻撃者は、保護が不十分なエンドポイント、脆弱なIDフロー、認可チェックの欠如を悪用して、機密記録にアクセスしたり、不正な操作を実行したりする可能性があります。実際のところ、モバイルバンキングのセキュリティは、アプリを支えるバックエンドシステムの強さに左右されます。バックエンドの集中は、システム全体の露出も高めます。調査では、iOSバンキングアプリの78%が2つ以下のバックエンドに接続しており、バンキングアプリのバックエンドの77%以上が米国を拠点としていました。

この集中はインフラストラクチャのレベルでも見られます。OstorlabのBanking Report 2025は、多くのモバイルバンキングアプリが限られた数のバックエンドシステムに依存していることを示しており、API、IDサービス、取引検証層を保護することの重要性が高まっています。

強力な保護が必要なモバイルバンキングの重要なワークフロー

モバイルバンキングアプリケーションは、特にリスクの高い少数のワークフローに依存しています。これらのワークフローが侵害されると、攻撃者は口座への不正アクセス、取引の宛先の変更、機密性の高い金融データの露出を引き起こす可能性があります。そのため、これらの領域はテストにおいてセキュリティ上の優先事項として扱うべきです。

認証と本人確認

認証は、ユーザー環境全体へのアクセスを制御するため、バンキングアプリケーションで最も重要な機能の一つです。モバイルバンキングアプリでは、パスワード、生体認証、ワンタイムコード、トークンベースの仕組みを組み合わせて使うのが一般的です。この領域のセキュリティテストでは、認証ロジックを回避できるかどうか、セッショントークンが予測可能か不適切に保護されていないか、生体認証が安全に実装されているか、ログインフローを操作できるかどうかを調べます。認証はあらゆる機密操作への入り口であるため、小さな弱点でも大きな影響をもたらす可能性があります。生体認証は現在バンキングアプリの65%で採用されている一方、その28%では生体認証バイパスの脆弱性が依然として確認されていることから、この点は特に重要です。

セッション管理のセキュリティ

セッション処理は、アプリケーションの利用中にユーザーの身元がどのように維持され、セッションが期限切れになったときやユーザーがログアウトしたときにアクセスがどのように終了するかを決定します。セッション管理が脆弱だと、攻撃者がアクティブなセッションを乗っ取ったり、期限切れの認証情報を再利用したり、意図した期間を超えてアクセスを維持したりできる可能性があります。そのため、テストではトークンのライフサイクル管理、ログアウト時の挙動、有効期限のロジック、トークンの保存方法、そして異常な条件下でセッション固定や再利用が可能かどうかを評価する必要があります。

決済と送金のワークフローの保護

決済と送金は、資金の直接的な移動を伴うため、あらゆるバンキングアプリケーションで最も機密性の高い操作の一つです。セキュリティテストでは、クライアント側の操作によって取引リクエストを改変できないこと、支払金額と送金先の詳細が正しく検証されること、バックエンドの認可チェックが一貫して適用されていることを検証する必要があります。取引の不正な改変は、モバイルバンキングにおける最も重要な不正シナリオの一つであり続けているため、このワークフローにはクライアント側とサーバー側の両方で強力な保護が必要です。

受取人管理のセキュリティ

受取人管理もリスクの高い領域です。多くの不正スキームでは、不正な受取人の追加や支払情報の変更が試みられるからです。攻撃者が受取人の記録を改変したり、支払いを悪意のある口座に振り向けたりできれば、その影響は即座に、かつ深刻に現れます。これらの機能を保護するには、強固なサーバー側の検証、承認フロー、監視が不可欠です。受取人管理は不正リスクと密接に結び付いているため、モバイルセキュリティテストの一環として継続的に評価する必要があります。

モバイルバンキングアプリケーションによく見られる脆弱性

モバイルバンキングアプリには複数の技術層にわたって弱点が存在する可能性があり、これらの脆弱性はアプリケーション自体と、それを取り巻くより広い金融環境の両方に影響を与えます。こうしたカテゴリを理解することで、チームはリスクが最も高い領域にテストの労力を集中できます。

機密データの露出

認証トークン、個人識別子、暗号素材などの機密情報は、決して安全でない場所に保存すべきではありません。モバイルアプリでは、シークレットがローカルデータベース、共有プリファレンス、キャッシュ、ログ、スクリーンショットに書き込まれたときにリスクが生じることがよくあります。安全でないメモリ処理によって、実行中に価値の高いデータが露出することもあります。金融アプリケーションは機密性の極めて高いユーザー情報と取引情報を処理するため、この種の弱点は口座の侵害やデータ漏えいに直結する可能性があります。これは周辺的な問題ではありません。ハードコードされたシークレットだけでも、分析したアプリの50%以上に影響しており、コード内のAPIキー、トークン、認証情報が露出していました。

KYCフローのセキュリティリスク

顧客の本人確認プロセスは、ますますモバイルアプリケーションに直接組み込まれるようになっています。書類のアップロード、自撮りによる本人確認、身元情報の取得といったステップは、極めて機密性の高い個人データを扱うため、新たな露出を生み出します。これらのワークフローの保護が不十分だと、本人確認のアーティファクトが永続的に保存されたり、安全でない形でキャッシュされたり、脆弱なセッション状態の管理によって露出したままになったりする可能性があります。セキュリティテストでは、KYCプロセスを単なる業務機能としてだけでなく、重要なデータ処理ワークフローとしても扱う必要があります。

暗号実装の弱点

暗号化はバンキングアプリケーションの保護において中心的な役割を果たしますが、実装上の誤りは依然としてよく見られます。アプリが古い暗号アルゴリズムに依存していたり、ハードコードされた鍵を使っていたり、鍵のローテーションとライフサイクルを適切に管理していなかったりすると、問題が生じることがあります。脆弱な暗号設計は、保存データと転送データの両方の機密性を損なう可能性があり、信頼と完全性が不可欠な金融環境では大きな懸念事項です。

クライアント側のセキュリティ制御の弱点

モバイルアプリケーションはリバースエンジニアリングや操作が可能であるため、セキュリティ上の判断をクライアント側のロジックだけに頼るべきではありません。重要なチェックがアプリ自体でしか実施されていない場合、攻撃者は実行時の挙動を改変したり、隠された制御を悪用したり、想定されたインターフェースの外からAPIと直接やり取りしたりして、それらを回避する可能性があります。強固なセキュリティ設計では、重要な判断をクライアントだけに任せるのではなく、サーバー側で検証する必要があります。

アプリケーションの改ざんと耐性

攻撃者は、アプリケーションの挙動を理解したり変えたりするために、デバッグの悪用、実行時の注入、コードの改変、不正な計装を試みる可能性があります。バンキングアプリの場合、これにより信頼境界が弱まり、さらなる悪用が容易になります。アプリケーションのハードニングと耐性の技術は、実行中の完全性を保ち、攻撃者がアプリをうまく操作できる可能性を減らすのに役立ちます。

WebViewとディープリンクのセキュリティリスク

組み込みブラウザーのコンポーネントやナビゲーションスキームは、慎重に実装されていないと脆弱性をもたらす可能性があります。WebViewのコンテキスト内でのインジェクション、ディープリンクを通じた悪意のあるリダイレクト、URLの操作によるセッションハイジャックは、いずれも不正な操作の糸口になり得ます。小さなナビゲーションの欠陥でも、認証、セッション、決済に関連するワークフローを露出させる可能性があるため、これらの問題はモバイルバンキングでは特に重要です。

サプライチェーンとサードパーティコンポーネントのリスク

最新のモバイルバンキングアプリケーションは、サードパーティのソフトウェア開発キット（SDK）、ライブラリ、組み込みフレームワークに依存しています。これらのコンポーネントは開発を加速させる一方で、古かったり、脆弱だったり、侵害されていたりするとリスクをもたらします。脆弱性は銀行自身のコードだけでなく、アプリが依存する外部の依存関係から生じる場合もあるため、モバイルセキュリティにおいてサプライチェーンのリスクはますます重要になっています。この問題の規模は調査からも明らかで、古いライブラリはバンキングアプリの46%に影響していました。

モバイルセキュリティテストが生成するエビデンス

効果的なセキュリティ検証では、理論上の検出結果のリストを示すだけでは不十分です。何が見つかったのか、なぜそれが重要なのか、どのように修正すればよいのかをチームが理解できるエビデンスを生成する必要があります。セキュリティ上の判断をエンジニアリングとコンプライアンスの両方の関係者がレビューする必要があることの多いバンキング環境では、これは特に重要です。

1. 逆コンパイルされたアプリケーションのコンテキスト
2. ファイルシステムのアクティビティのエビデンス
3. コードパスの実行カバレッジ
4. トリアージにすぐ使える調査アーティファクト

規制とコンプライアンスに関する考慮事項

金融機関は、モバイルバンキングのセキュリティプログラムを業界の規制やサイバーセキュリティのフレームワークに整合させる必要があります。モバイルアプリケーションは機密性の高い顧客データを扱い、重要な取引を支えているため、規制当局は金融機関に対し、強固な制御、レジリエンスの高いシステム、継続的なテストの実践を示すことをますます求めています。

セキュリティテストは、保護策が正しく実装され、意図したとおりに機能していることを組織が検証するのを助けることで、こうした期待に応えます。また、セキュリティチームがデータ保護、決済のセキュリティ、オペレーショナルレジリエンスについて、より強固な社内保証を構築するのにも役立ちます。

NIS2

NIS2は、金融エコシステムの一部を含む重要セクターに対して、サイバーセキュリティとリスク管理の義務を定めています。モバイルバンキングにとっては、アプリケーションのリスクを可視化し、レジリエンスの実践を強化する必要性が一層高まります。

DORA

デジタル・オペレーショナル・レジリエンス法（DORA）は、金融機関のオペレーショナルレジリエンスとICTリスク管理に焦点を当てています。モバイルバンキングの文脈では、重要なデジタルサービスをテストし、セキュリティ制御が長期にわたって有効であり続けることを検証することの重要性が浮き彫りになります。

PCI DSS

PCI DSSは、決済関連データを保護するための基準を定めています。決済処理に関わるモバイルアプリケーションは、カード会員データを保護し、取引フローを安全にするために、これらの要件に準拠する必要があります。

FFIECのガイダンス

FFIECのガイダンスは、金融セクターにおけるサイバーセキュリティテストと監査に関する期待事項を示しています。モバイルアプリケーションにとっては、反復可能なセキュリティ検証と、リスクが監視され対処されていることを示す明確なエビデンスの必要性を裏付けるものです。

GLBA

GLBAは、金融機関に消費者の金融情報を保護することを求めています。モバイルバンキングアプリはこうしたデータをさまざまな形で処理・保存することが多いため、コンプライアンスを支えるには強固なテストと保護策が不可欠です。

OWASP Mobile Top 10

OWASP Mobile Top 10は、モバイルのリスクの一般的なカテゴリを理解するための有用な参考資料であり続けています。チームがテストの取り組みを構造化し、技術的なリスクをより標準化された形で伝えるのに役立ちます。

開発ライフサイクルへのモバイルバンキングのセキュリティテストの組み込み

最新のモバイルセキュリティ戦略は、開発後にときどき行う評価だけに頼るべきではありません。バンキングアプリケーションは急速に進化するため、問題をより早く特定し、変更後に再評価できるよう、セキュリティテストを開発ライフサイクルに組み込む必要があります。

CI/CDとの連携

セキュリティスキャンをCI/CDパイプラインに組み込むことで、チームはリリースプロセスのより早い段階で問題を検出し、アプリケーションの進化に合わせてより一貫したテストカバレッジを維持できます。これにより、フィードバックが速くなり、後工程での修復コストが下がります。

課題管理と修復のワークフロー

セキュリティの検出結果は課題管理システムと自然に連携し、エンジニアリングチームが整理された形でレビュー、優先順位付け、解決を行えるようにすべきです。これにより、セキュリティチームと開発チームの協力が改善され、評価から修復までの間で脆弱性が見失われることを防げます。

IDとアクセスの制御

テストプラットフォーム、検出結果、修復データへのアクセスは、特に金融環境では慎重に管理する必要があります。セキュリティワークフローを取り巻く強固なIDとアクセスの管理は、機密情報を保護し、説明責任を維持するのに役立ちます。

継続的な再評価

アプリケーションの小さなアップデート、依存関係の変更、バックエンドの修正でさえ、新たな弱点をもたらす可能性があります。継続的な再評価は、セキュリティ制御を一度きりのチェックとして扱うのではなく、長期にわたって有効であり続けるようにするのに役立ちます。

モバイルバンキングアプリケーションは現代の金融サービスの中心にありますが、その重要性ゆえに攻撃者の格好の標的にもなっています。これらのプラットフォームの保護は、一度きりのプロジェクトではありません。継続的なテスト、端末・ネットワーク・バックエンドシステムにわたるより強固なレジリエンス、そしてチームが効率的に問題を検証・修正できるようにする技術的なエビデンスが必要です。

プロアクティブなモバイルセキュリティテストを開発ライフサイクルに組み込むことで、金融機関は悪用される前に脆弱性を特定し、リスクの高いワークフローの保護を強化し、規制当局の期待により適切に応えられます。モバイルファーストがますます進む金融環境において、このレベルの慎重さはもはや任意のものではありません。リスクを低減し、顧客の信頼を維持し、より安全なデジタルバンキング体験を提供するために不可欠です。

Ostorlabがバンキングチームを支援する方法

このアプローチを自社のバンキングアプリに適用したい場合に向けて、Ostorlabが何を行い、何を必要とし、どこまでが対象範囲なのかを説明します。

得られるもの：Ostorlabは、自社のバンキングアプリのリリースごとにテストを行います。ログインし、TLSピンニングや難読化が施されている場合も含めて顧客がダウンロードするビルドをテストし、アプリを追って口座や決済の背後にあるAPIとビジネスロジックまで調べます。AIエージェントによる各検出結果には、再生可能な実際に動作するエクスプロイトが付属し、検出結果には前述のような種類のエビデンス、つまり逆コンパイルされたソースのコンテキスト、ファイルシステムのエビデンス、関数呼び出しのカバレッジが含まれます。高速スキャンは通常1～5分、フルスキャンは15～45分で完了します。AIエージェントによるペンテストはより深く調べるもので、アプリによりますが、通常は数時間かかります。検出結果はチケットにまとめられ、プラットフォーム上で担当者を割り当てたり、Jira、ServiceNow、その他のチケット管理システムに送信したりできます。

必要なもの：

• アプリ：まずはostorlab.coでApp StoreまたはGoogle Playの自社アプリを検索し、無料の高速スキャンを実行してください。ログインは不要です。アカウントがあれば、AndroidのAPKやAAB、iOSの暗号化されていないIPAをアップロードしたり、TestFlightのビルドをスキャンしたりすることもできます。
• ログイン後のフロー用のテストアカウント：ログイン、決済、アカウントの変更は、スキャンがサインインできる場合にのみカバーされます。スキャンの設定でテストアカウントを追加し、SMS、TOTP、メールでワンタイムコードを受け取る手段も用意してください。SMSコードについては、Ostorlabサポートがテスト専用の電話番号を提供しており、テストアカウントでその番号を使います。ランダムな数字パッドのような独自方式は、Appiumスクリプトで自動化するか、Ostorlabのサポートチームが対応します。
• ネットワークアクセス：インターネットに公開されているアプリには、特別なアクセスは必要ありません。インターネットに公開されていないバックエンドの場合は、スキャナーのIPアドレスを許可するか、オンプレミススキャンを使ってネットワーク内部からステージング環境のアプリとAPIをスキャンしてください。
• アプリの保護機能への対応方針：Ostorlabのモバイルスキャンの前提条件では、すべての保護機能を有効にした状態でテストした後、無効にした状態でもテストし、保護機能がどの検出結果を隠していたかを確認することを推奨しています。

対象範囲と対象外：

• 対象範囲：Android、iOS、HarmonyOSのアプリ、それらが呼び出すAPIとバックエンド、認証とワンタイムコードのフロー、そしてMobile Shielding ScanによるAndroidとiOSアプリのアプリシールディング。
• WebアプリとAPIは、モバイルアプリなしで単独でテストすることもできます。Web Agentic Deep Scanは、ターゲットのURLまたはドメイン、テスト用の認証情報、そしてAPIの場合はOpenAPI、GraphQL、WSDLのスキーマを受け付けます。
• Ostorlabは手動のペネトレーションテストに取って代わるものではありません。リリースごとにテストするため、手動テストの合間に問題が見つかり、必要な手動ペンテストの工数を減らせる可能性があります。人間の判断が必要な範囲には、引き続き手動テストを行ってください。
• 上記のフレームワークについて、Ostorlabはそのセキュリティ上の期待事項に照らしたテストを支援し、エビデンスとして再利用できるレポートを提供します。DORAに基づく脅威ベースのペネトレーションテスト（TLPT）は実施しません。また、ネットワーク、物理セキュリティ、バックアップ、インシデント管理など、アプリケーション層を超える制御は、他のツールやチームの担当範囲となります。

エビデンス：

• Banking Report 2025は、上位500以上のモバイルバンキングアプリのセキュリティを取り上げています。
• Bypassing Mobile App Shieldingでは、本番環境の5つのバンキングアプリでシールディングがどの程度機能したかを検証しています。
• Bumbleの導入事例では、iOSとAndroidのリリースプロセスにOstorlabが組み込まれ、重大度が高およびクリティカルの検出結果があるリリースは、修正が確認されるまでブロックされる様子を紹介しています。
• ベンダー審査向け：OstorlabはSOC 2 Type IIレポート（セキュリティ基準、2024年11月18日～2025年4月18日）を取得しており、現在の期間の監査が進行中です。Enterpriseプランでは、データの保管場所として米国、欧州連合、GCC、アジア太平洋地域を選択できます。

次のステップ：まずはストアから自社アプリの無料スキャンを行い、その後テスト用の認証情報を追加してフルスキャンを実行し、ログイン後のフローもカバーしてください。リリース全体にわたるテストを計画するには、Ostorlab for bankingをご覧いただくか、デモをご予約ください。