DORAのサードパーティリスク：モバイルSDKのガバナンス

本シリーズをここまで読み進めてきた方は、現時点で次のものを手にしています。

• モバイルのリスク対象領域を定義するスコープ（第1回：モバイルチームのためのDORAコンプライアンス理解）
• ビルドごとに明確な判定を生み出すリリースレベルの制御（第2回：モバイルリリースのためのDORAコンプライアンス）
• 実際のモバイル障害モードに結び付けられたレジリエンスのエビデンス（第3回：DORAモバイルレジリエンス訓練）

残る領域がサードパーティリスクです。

モバイルアプリケーションは、組み込みSDKを同梱して出荷され、実行時には外部プロバイダーに依存します。DORAのもとでは、そうした露出も依然として自社の責任であり、リリースレベルでガバナンスを効かせなければなりません。これはモバイルのプログラムでは見過ごされがちです。「ベンダーリスク」が、バイナリやカスタマージャーニーに直接影響するものではなく、書類仕事として扱われてしまうためです。

1) モバイルのサードパーティリスクはなぜ異なるのか

構造的には、モバイルアプリはDockerイメージやJavaのWARと同様、パッケージ化された成果物です。自社のコードをサードパーティライブラリとともにバンドルし、特定のバージョンを出荷します。その部分は特別なものではありません。

特別なのは、出荷した後に何が起きるかです。バックエンドチームは通常、自社が運用するインフラ上で中央集権的にパッチを当て再デプロイできます。一方、モバイルチームはアプリストアを通じて顧客の端末へ出荷し、パッチの普及はストアの処理、ロールアウトの判断、端末の制約、ユーザーによる更新に左右されます。つまり、古いバージョンが現場で稼働し続けることになり、それがしばしば何週間、あるいはそれ以上に及びます。

ガバナンスを効かせるべき、異なる2種類のリスクがあります。

組み込みSDK
これらはバイナリの内部に同梱されて出荷され、アプリの権限で実行されます。SDKに脆弱性、ポリシー上の問題、破壊的変更があった場合、修復はリリースという形を取ります。新しいアプリバージョンを出荷し、その後、普及を待つことで修正します。実際の結果として、同時に稼働する複数のアプリバージョンにまたがって露出が長期化します。

実行時プロバイダー
アイデンティティ、OTP、プッシュ、不正検知、決済といった外部サービスは、性能が低下したり、部分的に障害を起こしたり、環境によって挙動が異なったりすることがあります。その不安定さは、実際の端末と実際のネットワーク上で、重要なモバイルジャーニーに直接現れます。障害が起きれば、顧客はすぐにそれに気づきます。

ガバナンス上の含意はシンプルかつ厳格です。モバイルにおけるサードパーティリスクは、リリース単位でスコープを定め、実行時に関連し、エビデンスに基づくものでなければなりません。

2) SDKガバナンスモデル（リリース単位）

目標は、各リリースで出荷を許可するサードパーティコードを、後から証明できる形で制御することです。このモデルはインベントリから始まり、次に変更を可視化し、その後、意思決定の記録を結び付けることで、リリースの判定を弁護可能なものにします。

まずはリリースごとのSDKインベントリから始めます。これを一度きりのレポートではなく、ベースラインとして扱ってください。あらゆるリリース記録について、SDK名、正確なバージョン、提供元/出所、機能上の役割、そして（把握している場合は）リスクに関する注記や分類を示せるようにしておくべきです。このインベントリが、承認、禁止、パッチSLA、監査時の取り出しの拠り所となります。

次に、リリースごとに差分を必須とします。新しいリリースごとに、直前に承認されたリリースと比べて、どのSDKが追加され、どのバージョンが変更され、何が削除されたかを言えるようにしておくべきです。これによって、「何も変わっていないと思う」が「何が変わったかを示せる」へと変わります。

変更が見えるようになれば、それを制御できます。新しいSDKやメジャーアップグレードには明示的なレビュー判断を必須とする一方、通常のパッチアップグレードは、承認済みのバージョンポリシーの範囲内にとどまる限り、より軽量な手順に従えるよう、承認ルールを定めます。あわせて、非推奨のSDK、脆弱なバージョン、非準拠のプロバイダーについては禁止リストを維持し、依存関係のドリフトを通じて既知のリスクがアプリに再び入り込まないようにします。

最後に、自社のリスクポリシーに沿ったパッチSLAを定め、SDKの脆弱性ごとにパッチまでの時間を計測します。重要なのは完璧さではありません。パッチが遅れたときに、制御されていないバックログではなく、期限を区切った判断を示せることが肝心です。

フィールド	説明
SDK名	ライブラリ名またはベンダー名
バージョン	ビルドに含まれる正確なバージョン
提供元	ベンダー、リポジトリ、または出所
役割	分析、認証、決済など
リスク注記	既知のリスク、分類、または根拠

3) モバイル向けのSBOM形式のエビデンス

DORAはモバイルに完璧なSBOMを求めてはいません。求められているのは、リリース固有で、弁護可能であり、運用上のガバナンスに結び付いた依存関係の可視性です。

モバイル向けの実用上最小限のSBOMは、そのリリースのSDKインベントリ（名前＋バージョン）に、ビルドツールが提供できる依存関係の参照情報を加え、さらにその正確なリリースに紐付いた脆弱性のコンテキストを加えたものです。要件は、それがバージョン単位でスコープ化され、リリース記録に紐付けられていることです。これにより、ソース管理、古いCIログ、属人的な知識から再構築することなく、「バージョンXにはどの依存関係が存在したか」に答えられます。

4) リリースレベルの制御

サードパーティガバナンスを運用に乗せるには、それを明確な結果を生み出すリリース制御として表現します。目指すのは、より多くの文書を作ることではありません。精査に耐えて有効であり続けるリリースの判定を生み出すことです。

実用上の最小限は、各リリースがSDKインベントリ、直前のリリースに対するSDK差分、新しいSDKとメジャーアップグレードに対する明示的な承認または例外、そして禁止されたSDKやバージョンが含まれていないことのチェックを備えていることを確保することです。各リリースはまた、SLAの範囲内にあるか、期限を区切った例外でカバーされているかのいずれかである脆弱性態勢を示すべきです。実行時の面では、リリースは重要なジャーニーに関するプロバイダー依存関係マップにリンクし、それらのジャーニーについて定義済みの性能低下およびフォールバックの判断を参照すべきです。

すでに第2回：モバイルリリースのためのDORAコンプライアンスの判定パイプラインがあるなら、これらは同じ判定へのサードパーティの入力となります。リリース記録は、判断とエビデンスへのリンクが存在する唯一の場所であり続けます。

5) 監査対応のエビデンスパック（リリースごと）

この段階で、エビデンスはリリースレベルに収束します。エビデンスパックは「手元にあるすべて」ではなく、デプロイ時点でそのリリースが許容できるものであった理由を説明する、最小限の成果物のセットです。

リリースのエビデンスパックには、次のものを含めるべきです。

• リリースのアイデンティティ（アプリID、バージョン、ビルド参照、成果物フィンガープリント）
• SDKインベントリと差分
• 承認と例外
• 重要なジャーニーごとのプロバイダーマッピング
• 性能低下とフォールバックの定義
• 第2回：モバイルリリースのためのDORAコンプライアンスからの制御結果
• 第3回：DORAモバイルレジリエンス訓練からのレジリエンスのエビデンス

「エビデンスがある」と「監査対応ができている」の違いは取り出しやすさにあります。そのため、リリースバージョンで整理され、パックの内容を指し示す、シンプルなインデックスを維持してください。

例外がギャップにならないよう、例外記録を標準化します。それは、スコープ（SDKまたはプロバイダー）、影響を受けるリリース、根拠、説明責任を負うリスクオーナー、代替的な制御、失効日またはレビュー日、そして承認のタイムスタンプを明示すべきです。これにより、「パッチを当てられなかった」が「オーナーと制御を伴う、期限を区切った判断を下した」へと変わります。

そうすれば保持はシンプルになります。リリース記録、エビデンスパック、インデックスを、社内および規制上のポリシーに沿って保管するだけです。重要な性質は、エビデンスがバージョン単位でスコープ化され、インデックス化され、必要に応じて取り出せる状態にとどまることです。

6) 経営層への報告（トレンド重視）

経営層のレベルでは、各リリースを蒸し返すことよりも、トレンドの可視性が目標となります。3つの指標がうまく機能する傾向があります。例外の経過期間は、リスクの判断が見直されているのか、それとも恒久化しつつあるのかを示します。SDKの脆弱性に対するパッチまでの時間は、自社のモバイルサプライチェーンが迅速に対応できているかを示します。リリースごとのSDK変更率は、依存関係のチャーンを示し、これはレビューの負荷や想定外のリスクと強く相関します。

小さく始め、その後に拡大する

リリースの流れを止めることなく、段階的に実装します。可視性がてこを生むため、まずはSDKインベントリとリリースごとの差分から始めます。次に、新しいSDKとメジャーアップグレードの承認を加え、続いて禁止リストの適用と、期限を区切った例外を伴うパッチSLAの追跡を加えます。

SDKガバナンスが安定したら、重要なジャーニーごとにプロバイダー依存関係をマッピングし、フォールバックの判断を文書化します。最後に、エビデンスパックのインデックスと保持を正式に定め、取り出しが特別なプロジェクトではなく日常的な作業になるようにします。