モバイルチームのためのDORAコンプライアンス：スコープと実際にやるべきことを理解する

DORAコンプライアンス・シリーズの紹介

DORA規制は、モバイルチームにもっともな問いを投げかけます。これはiOSとAndroidのデリバリーにとって、実際には何を意味するのか、という問いです。

本シリーズは、この問いに実践的な観点から答える4回シリーズです。規制の深掘りも理論もありません。モバイルチームとAppSecチーム、そしてそれを統括するリーダーにとって機能する、モバイルファーストのDORAコンプライアンスへのアプローチだけをお届けします。

• 第1回：スコープと実際にやるべきことを理解する （本記事）
• 第2回：モバイルリリースのための最も簡単なベースライン、判定、例外のモデル
• 第3回：BFSIのモバイルジャーニーのための最もシンプルなレジリエンス訓練ライブラリ
• 第4回：サードパーティリスク、SDKガバナンス、監査に耐えるエビデンスパック
  
  

---

銀行・金融サービス・保険（BFSI）のモバイルアプリを構築または保護しているなら、コンプライアンスと現代のエンジニアリングが出会う「楽しい」部分はすでにご存じでしょう。自社アプリは、製品であり、セキュリティ境界であり、カスタマーサポートの問い合わせを引き寄せる存在であり、依存関係の収集場所でもあります。そのすべてを同時に担っています。

そこに登場するのが、デジタル・オペレーショナル・レジリエンス法（DORA）規制です。そしてすぐ後に、たいていは期限とスプレッドシートを伴って、DORAコンプライアンスという言葉がやってきます。

本記事は、実践的な視点を保つためのモバイルファーストのガイドです。厳密なモバイルスコープを定義し、DORAをモバイルの文脈に当てはめ、モバイルチームと意思決定者の双方にとって機能するシンプルな運用モデルにたどり着きます。

すべての議論を、モバイルチームが常に指し示すただ一つのもの、リリースに結び付けて進めます。

では、そもそもなぜこれほど苦痛に感じるのでしょうか。

DORAがモバイルチームとAppSecチームにとって苦痛に感じられる理由

DORAが苦痛に感じられることが多いのは、それがコンプライアンスの形をした問題としてやってくる一方で、モバイルの仕事はリリースの形をしているからです。モバイルチームは、アプリのバージョン、ビルド番号、ロールアウト計画、重要なジャーニー、インシデント対応のプレイブックという単位で考えます。コンプライアンスの要求は、多くの場合「Xを証明せよ」という形で現れ、XがiOSとAndroidにとって何を意味するのかは明確にされません。

さらに、モバイルのリスクがモバイルのコードだけにあることはまれであるため、事態は複雑になります。モバイルのジャーニーは、IDサービス、OTPの遅延、プッシュ通知の配信、バックエンドAPI、不正検知、リモート設定のエラー、サードパーティプロバイダーの障害によって失敗する可能性があります。要件に「レジリエンスを確保すること」とあれば、モバイルチームが最初に問うのは「正確には何のレジリエンスで、どのように測定するのか」です。

苦痛を減らす最もシンプルな方法は、DORAと戦うことではありません。DORA規制を自社が実際に責任を持てるモバイルスコープに翻訳し、リリースごとに再現可能なエビデンスを生み出すことで、DORAコンプライアンスを日常業務にすることです。

では、規制の読書会にしてしまわずに、DORAを平易な言葉で説明するとどうなるでしょうか。

平易な言葉で見るDORA、モバイルの現実への翻訳

大まかに言えば、DORA規制は組織を2つの成果へと向かわせようとしています。

1. 混乱の最中も含め、デジタルサービスを安全に稼働させ続ける。
2. その能力を、再現可能で検証可能なエビデンスによって実証する。

モバイルチームにとっての「デジタルサービス」とは、アプリのバイナリだけでなく、エンドツーエンドのモバイル体験です。自社アプリは、IDと認証、バックエンドAPI、OTPとプッシュ通知、不正・リスクシステム、決済サービス、そしてアプリ内に同梱されたサードパーティSDKに依存しています。

DORAをモバイルファーストで翻訳すると、次のようになります。

• ICTリスク管理は、明確なオーナーを伴うモバイルリリース管理策のベースラインを定めます。
• インシデントへの備えは、バージョンを考慮した影響評価、タイムライン、そして無理なく組み立てられるエビデンスパックを求めます。
• オペレーショナル・レジリエンス・テストは、単発のテストだけでなく、重要なモバイルジャーニーの訓練を実施します。
• ICTサードパーティリスクは、重要なジャーニーを壊し得る、組み込みSDKと実行時プロバイダーのガバナンスを対象とします。
• 継続的改善は、インシデントと訓練によって管理策、監視、ランブックが更新されるループを生み出します。

これらを一貫して行えば、「単なる」書類作業をしているのではありません。DORAコンプライアンスを支えるモバイルの運用モデルを構築していることになります。

「モバイルDORAスコープ」を1ページで定義する（含まれるもの、含まれないもの）

スコープを明確にすることが、コンプライアンス対応の手戻りを減らす最速の方法です。以下は、モバイルチームが担うべきDORAコンプライアンス作業の、厳密かつ実践的なスコープです。

モバイルチームのスコープに含まれるもの

• 出荷するモバイルリリースの成果物
  特定のバージョンとビルド番号に紐付いた、iOSのIPAと、AndroidのAABまたはAPK
• リリースプロセスのエビデンス
  ビルドの来歴、署名、承認、そしてリリース候補に対してどのチェックが実行されたかの記録
• 組み込みのサードパーティSDKとライブラリ
  アプリに何が含まれているか、前回のリリースから何が変わったか、誰がそれを承認したか
• 重要なモバイルジャーニーに影響する実行時の依存関係
  IDと認証、バックエンドAPI、OTPとプッシュ通知、不正・リスクシステム、決済、リモート設定、フィーチャーフラグ
• 重要なジャーニー
  ログイン、ステップアップ認証、アカウント復旧、決済と送金、そしてアプリに含まれている場合はオンボーディング

スコープが明確になったので、DORAをモバイルチームにとって実践的なものに保つ、ただ一つの問いを立てることができます。

DORAコンプライアンスを実践的に保つ、リリース単位のただ一つの問い

「このモバイルアプリのリリースは、DORAに整合した自社のアプリケーションセキュリティとレジリエンスの管理策に準拠しているか」という問いに答えるには、次の条件を満たす必要があります。

• 具体的であること：特定のiOSまたはAndroidのバージョンとビルドに適用されます。
• 再現可能であること：コンプライアンス部門に求められたときだけでなく、リリースのたびに答えます。
• 実行可能であること：チェックとオーナーに対応付けられます。
• レビュー可能であること：リスク部門と経営陣が、毎回同じ形のエビデンスを評価できます。

この問いは、DORA規制を「モバイルだけ」に矮小化するものではありません。モバイルチームが信頼に足る形で責任を持てるもの、つまりモバイルの成果物とモバイルのジャーニーに対するリリース単位の保証を定義しているだけです。

リリース日を儀式にしてしまわずにこの問いに答えるには、最小限の運用モデルが必要です。

最小限の運用モデル（リリースレコード、判定、エビデンスパック）

リリース単位の問いに答えられるようにするには、3つの構成要素が必要です。まずは軽量に保ち、時間をかけて自動化していきます。

1) リリースレコード

これはリリースの「索引カード」です。成果物、エビデンス、判断を結び付けます。

最低限の項目：

• アプリ識別子（バンドルIDまたはパッケージ名）
• プラットフォーム（iOSまたはAndroid）
• バージョンとビルド番号
• 成果物の識別子またはフィンガープリント（ハッシュまたは一意のビルドID）
• ソースの参照（リポジトリとコミットSHA）
• パイプライン実行ID
• リリースオーナーと日付

エビデンスを特定の成果物に紐付けられなければ、後から何かを確実に証明することはできません。退屈な作業ですが、良い意味での退屈です。

2) リリース判定

現実に即し、ガバナンスを支える判定モデルを使います。

• PASS
• FAIL
• PASS_WITH_EXCEPTIONS

PASS_WITH_EXCEPTIONSは、管理されている場合には有効です。つまり、オーナー、有効期限、補完的な管理策、修復計画が揃っているということです。例外が失効しないなら、それが事実上のベースラインになってしまいます。

3) エビデンスパック

エビデンスパックは、判定を正当化できるものにし、DORAコンプライアンスの説明に信頼性を与えるものです。

パックは次の問いに答えるべきです。

• 何を出荷したか
• どのチェックを実行し、何が見つかったか
• リスクがあった場合、それはどう扱われ、誰が承認したか

リリースごとに保持すべき最低限のエビデンス：

• ビルドの来歴と署名の証明
• 正確な成果物に紐付いたセキュリティテストの出力
• 重大度とカテゴリを含む検出結果の一覧
• 前回承認されたリリースとの差分、何が変わったか
• リリースのSDKインベントリと、前回のリリースから変わった点
• 重要なジャーニーに対するレジリエンス訓練とランブックが最新であることの証明
• 例外がある場合は、その承認と有効期限

モバイルチームにとっての利点は、これが再現可能になることです。意思決定者にとっての利点は、レビューが一貫性を持ち、監査可能になることです。

「それでもまだ手間がかかりそうだ」と思われるなら、そのとおりです。達成可能な状態を保つために、30日で「良い状態」がどのようなものかを定義しましょう。

不要な作業を生むよくある落とし穴と、よりシンプルな代替策

落とし穴1：「スキャンの結果、DORAに準拠していると出た」

スキャンは価値あるエビデンスですが、DORAコンプライアンスは単一の出力よりも広範なものです。

よりシンプルな代替策：主張はリリース単位にとどめます。スキャンは、リリース判定とエビデンスパックへのエビデンスの入力として使います。

落とし穴2：モバイルがすべてを担うまで膨らむスコープ

責任の所在が不明確だと、モバイルチームが組織の半分を調整する羽目になります。

よりシンプルな代替策：厳密なモバイルスコープを保ちます。モバイルリリース、重要なモバイルジャーニー、組み込みSDKのガバナンス、リリース単位のエビデンスを担います。上流の管理策については、ID、プラットフォーム、プロバイダーの各オーナーと連携します。

落とし穴3：エビデンスを示せない管理策

管理策を成果物、レポート、チケット、ログに紐付けられなければ、それは繰り返し議論の的になります。

よりシンプルな代替策：エビデンスが明白になるまで管理策を書き直します。エビデンスを示せないなら、それはまだ管理策ではありません。

落とし穴4：失効しない例外

恒久的な例外は、恒久的なリスクに変わります。

よりシンプルな代替策：すべての例外には、オーナー、有効期限、補完的な管理策、修復計画が必要です。有効期限の順守状況を追跡します。

落とし穴5：ジャーニーではなくコンポーネントをテストする

コンポーネントのテストは有用ですが、顧客が体験するのはジャーニーです。

よりシンプルな代替策：重要なジャーニーを定義し、IDサービスの劣化、OTPの遅延、プッシュ通知の途絶、プロバイダーの障害など、ジャーニーを壊す障害モードを訓練します。

本記事から一つだけ持ち帰るなら、これを覚えておいてください。DORAは、モバイルのリリースサイクルの外側に存在する並行した「コンプライアンスプロジェクト」になる必要はありません。スコープをモバイルに保ち、リリースをガバナンスの単位とし、出荷しながらエビデンスを生成すれば、DORA規制の要件は管理可能になり、DORAコンプライアンスは再現可能になります。

次回の記事では、これをさらに具体的にします。シンプルなDORAに整合したモバイルリリース管理策のベースラインを定義し、それを明確なPASS、FAIL、PASS_WITH_EXCEPTIONSの判定に変える方法を示し、デリバリーを遅らせずに例外を扱う最も簡単な方法を紹介します。

このモバイルDORAスコープにおけるOstorlabの役割

スキャンはエビデンスの入力であり、DORAの判定ではありません（落とし穴1）。ここでは、Ostorlabがモバイルリリースのためにエビデンスパックのどの部分を作成できるか、そのために何が必要か、そして何が自社チームに残るかを説明します。

エビデンスパックとして得られるもの

• ビルドに紐付いたセキュリティテストの出力：ビルドごと、ストアリリースごとのスキャン結果。各検出結果はクリティカル、高、中、低で評価され、潜在的な検出結果は分けて管理されます。モバイルのSASTはソースコードを必要とせず、APK、AAB、IPAを直接解析します。モバイルのDASTはアプリを実行し、トラフィック、スタックトレース、スクリーンショットを取得します。
• リリースごとのSDKインベントリ：各リリースに含まれるSDKとネイティブライブラリを、そのバージョンとアプリバンドル内の場所とともに、既知の脆弱性に対応付けてリリースからリリースへと追跡します。
• ログイン後の重要なジャーニーのテスト：Ostorlabはテストアカウントでログインし、SMS、メール、TOTPのワンタイムコードを入力して、ステップアップのフローを含め、ログイン、トークンの更新、セッションの無効化、MFAの強制をテストします。アプリとそのAPIに対するAIエージェントによるペンテストでは、AIエージェントの検出結果ごとに、再生可能な実際に動作するエクスプロイトが追加されます。
• 修復の証明：検出結果はプラットフォーム内、またはJiraやServiceNowのチケットとして追跡され、修正後の再テストによって問題が解決したかどうかが確認されます。

必要なもの

• リリース成果物（APK、AAB、IPA）、またはストアやTestFlightのアプリ
• すべてのビルドがスキャンされるよう、CI/CDパイプラインに組み込まれたスキャン。リリースのない週でも、スケジュールされたパイプライン実行によって週次のペースを維持できます。
• ログイン画面だけでなく、ログイン、決済、アカウント変更までテストできるようにするための、テストアカウントとワンタイムコードの受け取り手段

自社チームに残るもの：Ostorlabは、モバイルアプリとその背後にあるAPIを対象とします。リリース判定、例外の承認、業務機能の分類、テストプログラムは自社の責任として残ります。Ostorlabは脅威ベースのペネトレーションテスト（TLPT）を実施せず、それに代わるものでもありません。既知のアプリとAPIの問題を修正した状態でTLPTに臨めるよう支援し、その後に修復計画のアプリとAPIの項目を再テストするのを支援します。ネットワーク、物理セキュリティ、バックアップ、インシデント管理など、アプリケーション層を超える要件は、他のツールとチームの担当です。

エビデンス

• モバイルバンキングアプリのためのDORAレジリエンステストでは、DORAのテスト要件ごとに、Ostorlabが行うことと自社に残ることを対応付けています。
• Bumbleの導入事例は、リリースゲートの実践例を示しています。修正が確認されるまで、HighとCriticalの検出結果があるリリースはブロックされます。
• ICTサードパーティリスクのレビューに向けて：Ostorlabは、2024年11月18日から2025年4月18日までを対象期間とするSOC 2 Type IIレポート（Securityの基準）を取得しており、現在の期間の監査が進行中です。Enterpriseプランでは、EUでのデータ保管を選択するか、オンプレミスでスキャンを実行できます。

次のステップ：ベースラインを取りましょう。顧客向けの各アプリをストアからの無料スキャンで一度スキャンし、デモを予約して、リリース全体にわたるテストを計画してください。

次回：モバイルリリースのためのDORAコンプライアンス：最も簡単なベースライン、判定、例外のモデル モバイルリリースの準備、AppSecのゲート、リスク部門の承認を担当しているなら、この記事がDORAを「何かしなければ」から「リリースはこうやって回す」へと変えてくれます。