脆弱性を見つける。攻撃の前に。

SaaS製品は、公開されているエンドポイントだけで構成されているわけではありません。さまざまなロール、招待、エクスポート、バックグラウンド処理、管理機能が合わさってビジネスロジックを形成しています。そのため、テストの前に、どのプロセスが特に高い保護を必要とし、アプリケーションがどの境界を守るべきかを明らかにします。この視点は、従来型の技術的検証を補完するものです。ある機能が形式的には正しく応答していても、ログインしている本人やそのテナントに想定されていない操作を許してしまう場合があります。

これに基づき、合意したテスト範囲を策定します。ブラックボックス、グレーボックス、ホワイトボックスの各要素は、目的と利用可能な情報に応じて選択します。ソースコードやアーキテクチャ資料が提供される場合は、観察結果をより的確に位置づけることができます。検証は認可されたアプリケーションに焦点を当て、合意済みのアカウントとデータを使用します。ツールによる検出結果を、評価を経ずに確定した脆弱性として扱うことはありません。影響と前提条件は、貴社のチームが理解し、確認できる形で示す必要があります。

SaaSとPaaSでは、責任の境界が重要な意味を持ちます。貴社のアプリケーションや設定を検証することは、プラットフォーム事業者のインフラを攻撃する許可を自動的に意味するものではありません。目的、許可された手法、必要な承認は、共同で記録します。APIや連携部分については、想定されたデータおよび権限の範囲に収まっているかを検証します。特に注目するのは、実際のアプリケーションの経路において、異なるロールやテナントが確実に分離されているかという点です。

レガシーソフトウェアには、多くの場合異なる進め方が求められます。ドキュメントが不十分であったり、テスト環境が本番環境を部分的にしか反映していなかったり、一部のコンポーネントが負荷に敏感に反応したりすることがあります。こうした条件は、開始前の計画段階で考慮する必要があります。テスト時間帯、連絡が取れる窓口担当者、中止基準をあらかじめ調整します。妥当な形で検証を実施できない部分がある場合は、その制約を結果の中で明示します。これにより、テストからどのような結論を導けるか、また追加調査が必要な箇所はどこかが明確になります。

レポートは、判断を可能にし、開発チームの修正作業を支援するためのものです。そのため確定した検出結果には、該当するバージョン、必要な前提条件、合意した証跡、想定される影響を記載します。経営層と技術チームでは、必要とする詳細度が異なります。優先順位付けはアプリケーションの文脈を踏まえて行い、同じ重みの検出結果を単に長く並べたリストにはしません。証跡は必要な範囲にとどめ、権限を持つ窓口担当者と合意した経路を通じて共有します。

是正内容については貴社のチームと協議し、合意したリテストで具体的な変更を評価します。ただし、ある検出結果が解消されたからといって、アプリケーション全体に脆弱性がないことを意味するわけではありません。新しいリリースや設定変更によって、状況が変わることがあります。ご要望に応じて、重要な変更点を対象とした定期的な検証へと発展させることも可能です。また、適切かつ明確に範囲を定めた目標についてはResult as a Serviceを取り決めることもできます。この場合、報酬はあらかじめ定義され、証明された成果に応じて決まります。