Ostorlabによるリリース速度に合わせた継続的なモバイルセキュリティテスト
Bumbleは、Ostorlabを含むツールをリリースプロセスに直接組み込むことで、iOSおよびAndroidのすべてのリリースでセキュリティを検証しています。スキャンはCI起動のワークフローを通じて継続的に実行され、スケジュールされたスキャンで補完されるため、主要なマイルストーンだけでなく、アプリの変化に応じて継続的にセキュリティを評価できます。
モバイル製品チームは頻繁にリリースを行います。Bumbleは、セキュリティリスクと製品のペースのバランスを取りながら、すべてのリリースでセキュリティを検証する方法を必要としていました。このアプローチは以下をサポートする必要がありました：
- 複数のアプリと製品チーム間で一貫してスケールすること
- 何をスキャンするか、いつ実行するか、何がリリースをブロックするかについての期待を標準化すること
- 低リスクの検出結果でリリースをブロックすることを避けつつ、それらが確実に修正されるようにすること
- エンジニアが迅速に動けるよう、トリアージ時のばらつきと曖昧さを減らすこと
リリースワークフローにおける継続的なセキュリティテスト
Bumbleは、iOSおよびAndroidのリリースプロセスの一部として、一貫してセキュリティスキャンを実行しています。これは主にCI起動のスキャンによって行われ、継続的なカバレッジを維持するためのスケジュールされたスキャンで補完されます。
このモデルにより、直前の手動レビューに依存するのではなく、進化し続けるアプリのアタックサーフェスをチームが継続的に評価できるようになります。
深刻度に基づくリリース制御
Bumbleは、製品の提供を遅らせることなくユーザーを保護するための明確なガードレールを使用しています。
- HighまたはCriticalの検出結果: 修正が完了し、問題が解決されたことが確認されるまでリリースはブロックされます。
- Medium、Low、またはInformationalの検出結果: リリースは自動的にはブロックされません。修復作業が作成され、修正パイプラインを通じて優先順位が付けられます。
このアプローチにより、深刻度の低い検出結果によるストップ・ザ・ラインの状況を回避しつつ、問題が確実に追跡され対処されることを保証します。
Bumbleは、ポートフォリオ全体で同じ全体的なセキュリティテストプロセスに従っています。標準化は以下によってもたらされます：
- 複数のアプリ間で同じCI起動のスキャンとスケジュールされたスキャンを実行すること
- 一元化された深刻度のしきい値を適用し、チーム間でリリースの判断が一貫するようにすること
- 何が実行されるか、何がブロッカーとなるか、ブロックしない検出結果がどのように処理されるかを予測可能にすること
これにより、アプリやチーム間でのばらつきが減り、各製品のプロセスを再発明することなくセキュリティプラクティスを拡張できます。
一貫したスキャンアプローチと一元化された深刻度のしきい値を使用することで、検出結果の解釈と対処方法におけるアプリ間およびチーム間のばらつきを減らすことができます。
— Bumble
Bumbleにとって、自動化は人員を追加せずにサイクルタイムを短縮するものでなければなりません。それには静的チェックを実行する以上のことが求められます。関連性が高く、再現可能で、迅速なトリアージのために設計されたテストが必要です。
要件1: アプリケーションを実行するテスト
Bumbleは、自動化された継続的なセキュリティテストは、静的解析のみに依存するのではなく、アプリケーションをインテリジェントに実行し、制御された方法でファジングを実行しなければならないと強調しました。
要件2: 実際のエンドポイントとの関連性
重要な要件の1つは、結果がエンジニアリングチームにとって関連性が高く実行可能な状態を保つために、Bumble自身のエンドポイントを対象とする機能です。
要件3: 概要から生の証拠へのトレーサビリティ
Bumbleは、2つのレベルでのトレーサビリティも重視しました：
- 概要: 何が実行され、どのエンドポイントがテストされ、どの手法が試行されたか。
- 完全な生の証拠: エンジニアが迅速に再現して検証できるように、正確なリクエスト、ペイロード、レスポンス、実行された手順を示す詳細なログ。
これにより、トリアージ時の推測ややり取りが減り、より迅速な修復がサポートされます。
セキュリティテストをシフトレフトし、Ostorlabを継続的に使用することで、Bumbleはリリース時に一般公開されているモバイルアプリのアタックサーフェスに、明らかに容易にエクスプロイト可能な欠陥が含まれていないという確信を高めました。
運用上、継続的なスキャンをプロセスに組み込むことは、速度とセキュリティの両方の目標をサポートします：
- 明確なガードレールを強制しながらリリース速度を維持する
- HighおよびCriticalの深刻度の検出結果に対してのみリリースをブロックする
- アプリポートフォリオ全体でリスクの一貫した可視性を維持する
プロセスに継続的なスキャンを組み込むことで、速度とセキュリティの両方の目標がサポートされます。
— Bumble
コードの変更は通常のモバイルリリースプロセスを経て進行します
CIで起動されたセキュリティスキャンが継続的に実行され、スケジュールされたスキャンで補完されます
検出結果は一元化された深刻度のしきい値を使用して評価されます
HighまたはCriticalの検出結果は、修正され検証されるまでリリースをブロックします
Medium、Low、およびInformationalの検出結果は修復パイプラインに回されます
エンジニアはスキャンの概要と生の証拠を使用して、効率的に再現し修復します
Bumbleのアプローチは、モバイルセキュリティテストを継続的なプラクティスとして運用する方法を示しています。明確なリリースガードレール、チーム間での標準化されたスキャン、そして証拠が豊富なトレーサビリティにより、セキュリティは最後のチェックポイントではなく、デリバリーの組み込み機能となります。
始めましょう
あなたのCIパイプラインでどのように機能するかをご覧ください
Ostorlabで、チームが深刻度に基づくリリース制御と証拠が豊富な検出結果を伴う継続的なモバイルセキュリティテストをどのように設定するかについてのウォークスルーをご覧ください。
デモをリクエスト