ホワイトボックステストの基礎：SDLCの早期にセキュリティリスクを特定する

ソフトウェアセキュリティに関して、ユーザーの85%は、コードに最も近い開発者やエンジニアが責任を負うべきだと考えています。ソフトウェアが本番環境にデプロイされる前であっても、脆弱性の大半はソフトウェア開発ライフサイクルの早い段階で生じることを考えれば、これは驚くことではありません。テスト対象のシステムやソフトウェアに関する内部知識がない人にとって、こうした脆弱性の多くは発見が非常に困難です。

ここで活用できるのがホワイトボックステストです。この記事では、ホワイトボックス方式のアプリケーションセキュリティテストについて、実施方法やメリット、デメリットを解説します。

ホワイトボックステストを解説

ホワイトボックステストの図

ホワイトボックステストの最大の特徴は、「内部が見える」ことです。そのため、グラスボックステスト、クリアボックステスト、トランスペアレントボックステスト、オープンボックステストとも呼ばれます。テスターやツールはソフトウェアの内部構造を把握し、コードが本来どのように動作すべきかを理解しているため、ソフトウェアが攻撃にどれだけ耐えられるかを調べてセキュリティをテストできます。

ホワイトボックステストはブラックボックステストとは対照的です。名前が示すとおり、ブラックボックステストでは、セキュリティテスターはソフトウェアやネットワークにアクセスできず、テスト対象についてほとんど、あるいはまったく知識がありません。ペネトレーションテスターは、外部の攻撃者と同じ方法でアプリケーションをテストし、脆弱性を見つけます。

ホワイトボックステストの目的

なぜソフトウェアにホワイトボックステストを実施するのでしょうか。ホワイトボックステストが重要なのはなぜでしょうか。理由は大きく2つあります。

1. セキュリティリスクを発見できる

クラウドネイティブアプリケーションセキュリティの現状レポートによると、56%を超えるユーザーが、クラウドネイティブアプリケーションで設定ミス、または既知の未修正脆弱性に関するインシデントを経験しています。アプリケーションセキュリティは非常に重要です。軽視すれば、深刻な事態を招きかねません。セキュリティ上の不具合を早期に把握すれば、リスクを取り除き、セキュリティ侵害による多大なコストを防ぐことができます。侵害が起きれば、顧客からデータ管理能力への信頼を失い、訴訟に発展する可能性さえあります。

セキュリティ脆弱性の多くは、安全でないデシリアライゼーション、設定ミス、シークレットの露出、アクセス制御の不備など、コードのプログラミングエラーが原因です。ホワイトボックステストを行わなければ、こうした脆弱性がもたらすリスクへの対処は困難です。

2. バグを発見し、品質を向上できる

ソフトウェアチームはアジャイルに開発し、ユーザーからのフィードバックや市場の変化に応じて頻繁にアップデートを提供します。既存の機能を損なうことなく、定期的に更新や変更を行う必要があります。人気のある既存機能を使いにくくするアップデートほど、ユーザーをいら立たせるものはありません。ホワイトボックステストは、バグや互換性を損なう変更をタイムリーに検出するうえで重要です。

つまり、ホワイトボックステストは、バグ、潜在的なセキュリティ上の抜け穴、パフォーマンスの問題を早期に検出するために不可欠です。

ホワイトボックステストの種類

ホワイトボックステストには、さまざまな種類があります。

• 実行テスト／単体テスト：コードの一部を実行し、その出力を期待される結果と比較するホワイトボックステストです。期待どおりの結果が得られなければ、欠陥があるため修正が必要です。実行テストは継続的に行います。

• 静的テスト／構造解析：コードを実行せずに、コードベースを詳しく分析してバグや脆弱性を探します。たとえば、テスターは静的アプリケーションセキュリティテストツール（SAST）を使ってコードベースを分析し、脆弱性を特定できます。SASTでは、設定解析、セマンティック解析、データフロー解析など、特定の観点からアプリケーションを詳細に分析し、ソースコードの安全性を確保します。

• ミューテーションテスト：通常、最後の段階で行います。一般的なバグチェックに加えて、プログラムを拡張する際に最適なコーディング戦略を判断するための分析を行います。

何をテストするのか

まず、ホワイトボックステストを実施するには、テスト対象のソフトウェアを理解し、コードと期待される動作を把握する必要があります。次に、実行時に問題が起こり得る箇所や脆弱性が悪用される可能性のある箇所を確認するため、追加のコードを書いてテストケースを作成します。

一般に、ホワイトボックステストでは次の項目を対象とします。

• 内部のセキュリティ上の抜け穴

• コード内での特定の入力値の流れ

• 期待どおりの出力と予期しない出力

• 壊れている、または構造が不適切なコードパス

• 条件ループのロジック

• 各関数やクラスの動作

• 特定の入力値に対するソフトウェアの処理

ホワイトボックステストの手法

ホワイトボックス方式のペネトレーションテストは、内部と外部の両方の脆弱性を包括的に分析できるため、セキュリティテストの重要な一環です。セキュリティテスターと開発者が連携することで、システムへの理解が深まり、悪用される可能性のある箇所を把握できます。たとえば、銀行アプリのセキュリティと信頼性を検証し、ビジネスロジックに抜け穴がないことを確認するのも、ホワイトボックステストの手法の一つです。

ホワイトボックステストでよく使われる手法は次のとおりです。

• 条件網羅：論理条件を用いて、サブステートメント内の変数をテストする手法

• 命令網羅：コード内の命令に対して一連のテストを実行する手法で、行網羅とも呼ばれます。すべての命令を少なくとも1回テストします。

• 分岐網羅：コード内のすべての分岐を少なくとも1回テストできているかを確認する手法

• パス網羅：通常、アプリケーション内の各パスを個別にテストするために行います。

• データフローテスト：コード内の変数を基準に、ソフトウェア内のデータの流れを調べる手法

ホワイトボックステストとブラックボックステストの比較

ホワイトボックステストとブラックボックステストは、ソフトウェアの欠陥を検出する手法です。どちらも広く使われていますが、その内容は大きく異なります。以下の表に主な違いをまとめました。

ブラックボックステストの図

そのため、ホワイトボックステストとブラックボックステストは互いに置き換えられるものではありません。どちらか一方だけを実施すれば十分というわけでもありません。この2つのテスト手法は互いを補完し、より優れたソフトウェアの実現に役立ちます。ホワイトボックステストとブラックボックステストを組み合わせた手法は、グレーボックステストと呼ばれます。

ホワイトボックステストのメリットとデメリット

ホワイトボックステストには、メリットとデメリットの両方があります。

メリット：

• テスターはテスト対象のシステムについて事前知識があるため、情報収集や偵察にかかる時間を大幅に削減できます。

• 他のどのテスト手法よりも徹底したテストが可能で、より多くのセキュリティリスクを発見できます。

• 低レベルで行うテストであるため、SonarQubeなどの自動セキュリティツールを活用してCIパイプラインに組み込めます。

• コードに近い段階でテストできるため、開発者は発見された脆弱性を容易に修正できます。

デメリット：

• 徹底的にテストするため、最も時間と費用がかかるテスト手法です。

• テスト対象のシステムに関する深い知識が必要です。

まとめ

ホワイトボックステストは、その性質上、セキュアなソフトウェア開発ライフサイクルでDevOps文化を実践するうえで重要な要素です。ホワイトボックステストは自動化できるため、通常はCIパイプラインで実行され、開発者がコードをチェックする際に迅速なフィードバックを提供します。

Snyk Codeのようなホワイトボックスセキュリティテストツールは、静的なアプリケーションセキュリティテストをDevSecOpsパイプラインに組み込みます。これにより、開発プロセスの早い段階でセキュリティリスクを特定するために必要な、最大限のテストカバレッジを開発者に提供します。