モバイルリリースにおけるDORAコンプライアンス：最もシンプルなベースライン、判定、例外のモデル

本シリーズの最初の記事モバイルチームのためのDORAコンプライアンス：スコープとやるべきことを理解するをお読みいただいた方は、すでに基礎が身についているはずです。

1/ モバイルのスコープを把握し、リリースがガバナンスの自然な単位である理由を理解しています。

2/ DORAコンプライアンスを実践的なものに保つ、ただ一つの問いを手にしています。それは、このモバイルアプリのリリースは、DORAに沿った当社のアプリケーションセキュリティおよびレジリエンスの制御に準拠しているかという問いです。

ここからは、その問いに、繰り返し可能かつ監査可能な形で答えられるようにする段階です。

本記事では、モバイルリリースにおけるDORAコンプライアンスの仕組みを扱います。モバイル向けの最小限の制御ベースラインを定義し、シンプルな判定モデルを紹介したうえで、リリースのたびにガバナンスの交渉が発生することのないよう、例外をどう扱うかを説明します。

まずは、これが汎用的なコンプライアンス作業ではなく、リリース単位の作業である理由から始めましょう。

モバイルのDORAコンプライアンスで最も実践的な単位がリリースである理由

「当社のアプリはDORAに準拠している」といった全体的な主張をしようとすると、モバイルのコンプライアンスは難しくなります。この主張は、組織のガバナンス、サードパーティの監督、インシデント対応プロセス、技術的な制御を一つの文に混ぜ込んでおり、モバイルチームの立場からきれいにエビデンスを示すことはほぼ不可能です。

リリースのほうが単位として優れているのは、モバイルの作業がもともとリリース単位で進むからです。iOSとAndroidの各リリースは、それぞれが個別の変更を表します。リスクもそれに合わせて変化します。エビデンスは、後になって誰かが監査依頼を送ってきたときに再構成するのではなく、リリースの時点で収集できます。

リリースをDORAコンプライアンスの単位として扱うと、次の3つのことが起こります。

• 出荷の一環として、エビデンスが自然に収集される
• リスクの判断が、暗黙の前提ではなく明示的に行われる
• コンプライアンスの説明が、リリースごとに一貫したものになる

次に、維持できるほど小さく、かつ役に立つほど強力なベースラインを定義します。

モバイルリリースのDORAコンプライアンスベースライン

モバイルチームにとってDORAコンプライアンスを実体のあるものにする最もシンプルな方法は、ベースラインを定義することです。ベースラインとは、すべてのリリースが出荷前に満たさなければならない制御のリストにすぎません。制御の数は多くても10〜20個に抑えます。それ以上になると、ガバナンスのツールではなく保守の負担になってしまいます。

良い制御には3つの特性があります。合格か不合格かを言える、つまり二値またはそれに近いこと。成果物、レポート、チケットを示せる、つまりエビデンスに結び付いていること。そして、不合格になったときに誰かが責任を負う、つまりオーナーがいることです。

さらに踏み込む前に、一つ念を押しておきます。この部分は、放っておくといくらでも複雑になります。シンプルに保ってください。エビデンスを示せない制御は、まだ制御とは言えません。

以下に、モバイルのスコープにおけるDORAコンプライアンスの大部分をカバーする5つのカテゴリを示します。

1) リリースの完全性とトレーサビリティ

このカテゴリは、何を出荷したかを正確に把握し、後からそれを証明できるかどうかに答えます。実際には、すべてのリリース成果物がバージョン、ビルド番号、フィンガープリントによって一意に識別され、承認済みのパイプラインで署名・生成されていることを意味します。また、セキュリティチェックが、開発者ビルドやステージング環境の近似版ではなく、まさにそのリリース候補の成果物に対して実行され、成果物をコミット、リポジトリ、パイプラインの実行に結び付ける来歴（プロベナンス）の記録があることも意味します。最後に、誰かの記憶に頼らず後からレビューできるよう、裏付けとなるエビデンスが保持されていることです。

地味ですが極めて重要なカテゴリです。成果物を特定できなければ、ほかのどの事柄も帰属させられないからです。

2) 脆弱性と露出のしきい値

このカテゴリは、このリリースが定義済みのリスク許容度の範囲内にあるか、という問いに答えます。

チームをトラブルから守る制御：

• リリースにクリティカルの検出結果がない
• モバイルにとって重要なカテゴリ（一般的には認証とセッション管理、暗号、機密データの保存、通信のセキュリティ、安全でない設定）に高の検出結果がない
• 最後に承認されたリリースと比べて、クリティカルまたは高の新たなリグレッションがない
• 出荷を妨げない検出結果についても修復の期待値が定められており、リスクが人知れず蓄積しない

ここで重要なのは、しきい値を適用する前に定義しておくことです。「見ればわかる」は制御ではありません。

3) サードパーティSDKのガバナンス

このカテゴリは、バイナリに何が含まれているかを把握し、その変化を管理できているか、という問いに答えます。

SDKのリスクを管理可能にする制御：

• このリリースのSDKインベントリがあり、組み込まれたすべてのSDKとライブラリが列挙されている
• 最後に承認されたリリースからの変更点を示す差分がある
• 新しいSDKやメジャーバージョンのアップグレードには、明示的な承認と担当オーナーの割り当てが必要である
• 禁止されたSDKの種類や既知の脆弱なSDKバージョンは、出荷がブロックされる
• 重大なSDKアドバイザリに迅速に対応するプロセスがあり、パッチ適用の期待値が定められている

モバイルには、依存関係がアプリの内部に同梱されて出荷されるという、独特なサードパーティリスクのプロファイルがあります。SDKは、自社のコードに一切変更がなくても、想定外のデータを収集したり、ユーザージャーニーを壊したり、脆弱性を持ち込んだりする可能性があります。DORAコンプライアンスがきわめてモバイル固有のものになるのは、このカテゴリです。

4) 重要なジャーニーに対するレジリエンスの備え

このカテゴリは、顧客にとって最も重要な障害モードをテストしたか、という問いに答えます。

「レジリエンス」を曖昧な言葉にしないための制御：

• ログイン、ステップアップ認証、アカウント復旧、決済など、アプリの重要なジャーニーが宣言されている
• ジャーニーごとに、アイデンティティ、OTPとプッシュ通知、API、不正対策、決済、リモート設定を網羅した依存関係マップがある
• 高リスクの機能について、ロールバック計画、キルスイッチ、フィーチャーフラグのガードレールが用意され、テスト済みである
• レジリエンス訓練のエビデンスが添付され、リリース記録にリンクされている

「セキュアである」と「レジリエントである」を分けるのが、このカテゴリです。セキュリティとレジリエンスは関連していますが、同じものではありません。

5) インシデントへの備え

このカテゴリは、このリリースで何か問題が起きたときに、迅速かつ整然と対応できるかどうかに答えます。実際には、テレメトリがバージョン単位の分析に対応しており、どのアプリバージョンが影響を受けているか、緩和策の適用に伴って影響がどう変化するかを特定できることを意味します。また、不正やアカウント乗っ取りのシグナルを含むモバイルのセキュリティイベントについて明確なインシデント重大度の基準があり、手作業のフォレンジックなしにすばやく記入できるエビデンスパックのテンプレートがあることも意味します。最後に、何が、誰によって、どのような根拠で決定されたかを記録する意思決定ログのプロセスが必要です。これにより、インシデントの経緯が一貫し、レビュー可能なものになります。インシデントへの備えは、チームが最後に整えるカテゴリであることが多いものの、実際に何かが起きたときに最も重要になるカテゴリです。

ベースラインができたら、すべてのリリースレビューの結果を一貫した形で表す方法も必要になります。

DORAコンプライアンスのリリース判定モデル

ベースラインができたら、すべてのリリース候補は3つの結果のいずれかを出すべきです。

PASS

すべての制御を満たしています。エビデンスはそろっており、リリース記録にリンクされています。リリースを進めることができます。

FAIL

ブロッキングの制御のうち一つ以上を満たしていません。ブロッカーが解決されるか、例外として正式に扱われるまで、リリースは出荷されません。

PASS_WITH_EXCEPTIONS

一つ以上の制御が正式に承認された例外によって免除されていることによってのみ、ベースラインを満たしているリリースです。これはガバナンスのもとでの結果であり、近道ではありません。

3状態のモデルは、二値のモデルよりも誠実です。モバイルのBFSIでは、より優先度の高いリスクに対処するために出荷しなければならないこともあり、すべて問題ないふりをするよりも、補完的な制御を伴う正式な例外のほうが責任ある対応です。

例外は、プログラムが規律を保てるか、それとも少しずつ「後で直す」領域へ流されていくかの分かれ目です。

すべてを遅らせることなく例外を扱う方法

例外は、非公式かつ恒久的になりがちなため、評判がよくありません。しかし、適切に管理された例外は実は有用なツールです。リスクを静かに蓄積させるのではなく、管理されたトレードオフを明示的に行えるからです。

良い例外には、次の5つが必要です。

• ID：レビューをまたいで追跡できるようにする
• オーナー：例外の解消に責任を持つ
• リスクステートメント：リスクが何であり、なぜ現時点では許容できるのかを平易な言葉で説明する
• 補完的な制御：例外が有効な間、実際の影響を軽減する
• 有効期限：フォローアップを強制する。期限がないなら、それは例外ではなくポリシーの変更です。

ガバナンスのルールはシンプルです。PASS_WITH_EXCEPTIONSが有効なのは、5つの要素がすべてそろい、適切な担当者（通常はセキュリティ部門とリスク部門の両方）によって承認されている場合に限ります。

例外は指標として追跡します。例外の数が増え続け、有効期限の遵守率が低いなら、ベースラインは適用されているのではなく、回避されています。

ここで、これをリリース記録に結び付けます。そうすることで、監査やレビューの負担が大きく軽くなるからです。

リリース記録の最小限の項目（監査を容易にするために）

リリース記録は、判定をエビデンスに結び付け、モデル全体を監査可能にします。すべてのリリース記録に含めるべき最小限の項目は次のとおりです。

リリースの識別情報

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

判定

• PASS、FAIL、PASS_WITH_EXCEPTIONSのいずれか
• 制御のサマリー（どれが合格し、どれが不合格だったか）
• FAILの場合はブロッカーのリスト（検出結果または課題のID、オーナー、修復目標）
• PASS_WITH_EXCEPTIONSの場合は例外のリスト（例外ID、免除された制御、有効期限、承認者）

エビデンスへのリンク

• 成果物にリンクされたセキュリティテストレポート
• 重大度とカテゴリを含む検出結果のエクスポート
• SDKインベントリと差分
• 重要なジャーニーに関する訓練のエビデンスとランブックへのリンク
• 承認の履歴と例外登録簿のエントリ

これらの項目がそろっていれば、監査人は、チームにすべてを一から再構成するよう求めることなく、後からリリースの判断をレビューできます。それが実務上の価値です。

最後のピースは展開です。目標は、これを新しい儀式ではなく、普段どおりの出荷のように感じられるものにすることです。

リリーストレインを止めずに展開する方法

チームが犯す最大の過ちは、すべてを一度に適用しようとすることです。そうするとブロッカーが生まれ、リリースが遅れ、ベースラインがツールではなく障害物のように感じられてしまいます。

より良いアプローチは、小さく始めて広げていくことです。

一つのハードゲートから始める

最も重要な制御を一つ選び、ブロッカーとして適用します。最初の選択肢としては「クリティカルの検出結果がないこと」が適しています。それ以外はすべて計測はしても、最初の数回のリリースでは出荷を妨げないものにしておけます。

制御を段階的に追加する

チームがモデルに慣れてきたら、制御を一つか二つずつ追加します。目標は、ベースラインを独立したコンプライアンス作業ではなく、出荷の通常の一部と感じられるようにすることです。

エビデンスの収集を早期に自動化する

エビデンスの生成を早く自動化するほど、モデルの負担は小さくなります。まずは成果物に結び付いたスキャンレポートから始め、次にSDKの差分、さらに訓練とランブックのチェックを加えます。

初日から例外を可視化する

当初は例外をほとんど使わないとしても、最初から追跡可能で期限付きのものにしておきます。何か月も非公式に運用された後で例外にガバナンスを加えるのは、はるかに困難です。

おわりに

制御のベースラインは、役に立つために完璧である必要はありません。一貫しており、エビデンスに裏付けられ、適用されていることが必要です。iOS、Android、HarmonyOSのすべてのリリースが判定とリンクされたエビデンスパックを生み出すようになれば、DORAコンプライアンスは四半期ごとの慌ただしい作業ではなくなります。モバイルの出荷のあり方から自然に生まれる成果物になるのです。

次の記事では、リリースの制御からオペレーショナルレジリエンスへと話を進めます。BFSIのモバイルジャーニー向けの最もシンプルな訓練ライブラリ、各訓練が生み出すべきエビデンス、そして訓練の結果とリリースの制御をつなぐループの閉じ方を取り上げます。

次の記事：DORAのもとでのモバイルのオペレーショナルレジリエンス：BFSIジャーニー向けの最もシンプルな訓練ライブラリ