動的アプリケーションセキュリティテスト (DAST)

DAST ツールでは、導入するアプリケーションでどのプログラミング言語が使用されたかといった、アプリケーションに関する知見は必要とされません。これにより、ニッチなプログラミング言語を使用する場合でも、アプリケーションセキュリティを向上させることができます。

DAST が他のセキュリティテスト手法と異なる点

特定のセキュリティテスト手法がアプリケーションのテスト環境に適しているかどうかを判断するには、その手法の利点とその限界について検討することが重要です。それでは、それぞれのテスト手法の違いについて見ていきましょう。

SAST vs DAST vs SCA

静的アプリケーションセキュリティテスト (SAST) は、コードに注目します。CI パイプラインの初期段階で動作し、ソースコード、バイトコード、またはバイナリコードをスキャンして、ベストプラクティスに反する、問題のあるコーディングパターンを特定します。SAST はプログラミング言語に依存します。

動的アプリケーションセキュリティテスト (DAST) は、実行時にアプリケーションをスキャンするブラックボックステスト手法で、CI パイプラインの後半で実施します。DAST は、特定のプログラミング言語に依存せず、回帰を防ぐのに適した手法です。

インタラクティブアプリケーションセキュリティテスト (IAST) は、ランタイムのアプリケーションの動作に注目するという点で、DAST と似ています。ただし、IAST の解析は、ブラックボックステスト、スキャン、内部アプリケーションフローの分析の組み合わせに基づいて行われます。IAST の利点は、SAST のように DAST 的な知見をソースコードにリンクさせることができることです。このアプローチの欠点は、IAST のプログラミング言語への依存度が高く、CI パイプラインの後半でしか実行できないことです。

ソフトウェアコンポジション解析 (SCA) は、アプリケーションで使用されるサードパーティのコードの依存関係に注目します。ソフトウェアコンポジション解析は、多くのオープンソースライブラリを使用するアプリケーションで非常に効果的です。この方法もプログラミング言語に依存します。

詳しくは、SAST と　DAST　の比較、その違いと 2 つを組み合わせる方法をご覧ください。

DAST は他のアプリケーションセキュリティテスト手法と組み合わせることができますか

静的なソースコード解析に加えて、DAST ではランタイムで追加的な知見を提供できるため、SAST や SCA のような静的チェックに依存するアプリケーションセキュリティテスト手法と組み合わせるのが最適です。

多くの場合、SAST ツールは単一のコードスニペットを見るだけで、そのコンテキストは考慮されません。あるファイルのコードは、それを使用する別のファイルのコードですべての問題を解決したとしても、問題視される可能性があります。システムに導入したセキュリティが、まったく別のコンピューターで動作することもあります。たとえば、SAST ツールでは、サニタイズされていない入力はすべて問題として識別されてしまいます。これは、データが使用される直前にサーバー側でサニタイズされることを認識できないためです。

DAST ツールでは、むしろエンドツーエンドのテストが実施されます。クライアントコードが入力規則のベストプラクティスに従っているかどうかはチェックできません。DAST ツールでは、アプリケーションの入力と出力を見ます。出力がサニタイズされていれば、アーキテクチャのどこでサニタイズされたかは気にしません。

しかし、エッジケースでのみ失敗するアプリケーションの一部は、DAST ツールにとって盲点となります。なぜなら、DAST ツールは理論的な入力ではなく、特定のユースケースのみを対象としているからです。そのような場合に SAST や SCA ツールが活躍します。これらのツールは、ソースコードを調べ、DAST ツールだけでは見過ごしてしまうような問題のある動作をチェックします。

たとえば、型変換を行う場合、失敗したり、好ましくない出力をすることがあります。10 個の入力しかカバーしていない DAST テストケースでは、すべて問題なしと報告されるかもしれませんが、SAST ツールでは、アプリケーションの導入時に考慮したこともない特定の値で変換方法が失敗する可能性があることを知ることができます。

DAST の長所と短所

DAST ツールの主な機能は、アプリケーションを実行中にテストするという性質上、多くの利点がありますが、同時に欠点もあります。DAST がソフトウェアプロジェクトに適しているかどうかを判断するために、以下の点の詳細を検討してみましょう。

長所:

• 誤検出が少ない: アプリケーション全体をスキャンするわけではないため、通常、DAST は SAST よりも誤検出が少なくなります。これにより、脆弱性が実際に存在するかどうかすばやく検証でき、脆弱性を未然に防ぐことができるかどうか確認できます。

• 言語に依存しない: DAST は、プログラミング言語に依存しない唯一のセキュリティテスト手法です。DAST では、ソースコード、バイトコード、またはアセンブリコードは調べられません。システムの入力と出力のみがチェックされます。ニッチなプログラミング言語で実装されたアプリケーションの場合、DAST が唯一の選択肢となる場合があります。

• 修正された脆弱性のすばやい再テストが可能:DAST は回帰をチェックできます。セキュリティ脆弱性が発見され再現された場合、その再現を自動化し DAST テストスイートに追加することが可能です。つまり、以降のすべてのリリースには、過去の問題を引き起こしたインタラクションが含まれることになります。もし、これらの問題が何らかの形で再発しても、DAST ではリリース前にそれをキャッチできます。

短所:

• コードの知見が得られない: DAST ではシステムの入力と出力のみが調べられます。そのため、発見された脆弱性をコード行と関連付けることはできません。

• テストプロセスが遅い: ソフトウェアを実行して使用することが求められるため、自動テスト方法を使用した場合でも、テストプロセスが遅くなる可能性があります。入力の組み合わせが多いサインアッププロセスをクリックすると、時間がかかります。

• CI/CD パイプライン後半の結果になる:DAST は CI/CD パイプラインの一番右側で実施されることになります。DAST ツールを使う場合、アプリケーションを実行する必要があるためです。特にアプリケーションの規模が大きくなると、この作業にかなりの時間がかかるようになります。

• 手動テストが必要な場合がある: 何らかの理由でアプリケーションの実行と使用を自動化できない場合、CI/CD パイプラインから DAST チェックを完全に外し、リリースごとにアプリケーションを手動でテストする必要があります。

DAST の導入を成功させるには

DAST はアプリケーションの実行に依存するため、テストパイプラインに追加することは、SAST を追加するほど簡単ではありません。DAST は自動化することが可能ですが、自動化する部分をまずスクリプト化、あるいは記録する必要があります。このため、DAST ツールをパイプラインに追加した後に必要なプロセスがあります。

1\.ユーザーを観察する

DAST の導入は、ユーザーを観察してアプリケーションの使い方を記録することから始めるとよいでしょう。何をやっているのかを記録するだけでなく、説明も依頼してください。

ユーザーは、アプリケーションの中で実際に何をクリックしているのか忘れがちです。頻繁に行う操作は、無意識のうちに行うようになるからです。これは、ユーザーが自分のタスクに集中するのに役立ちますが、ユーザーがクリックしたものについて考えていないからといって、これが問題につながらないとは限りません。

2\.ユーザーの操作を自動化する

次のステップは、自動化ツールを使用してユーザーのアクションをスクリプト化することです。これは、GUI よりも CLI および API アプリケーションの方が簡単かもしれませんが、一般的には、これらすべてのアプリケーションで可能です。

3\.テストスクリプトを CI/CD パイプラインに追加する

最も重要なユースケースを自動化操作でカバーできたら、DAST ツールがスキャンしている間に、アプリケーションでスクリプトを実行できます。DAST の最初の実行後、セキュリティの脆弱性の修正を開始できます。

4\.テストスイートに回帰テストを追加する

アプリケーションの日常的な使用において、たまたまセキュリティの脆弱性を発見した場合、特定の使用方法のスクリプトをテストスイートに追加できます。これによって、将来、問題が再発しないようにすることができます。

まとめ

DAST は信頼性の高い脆弱性検出手法としてツールベルトの中に入れておくべきものですが、DAST だけですべてのベースをカバーできるわけではありません。ただし、たとえばアプリケーションの実装にニッチなプログラミング言語を使用している場合や、一般的なプログラミング言語のクローズドソースパッケージや拡張機能を使用している場合など、それが唯一の解決策になることもあります。

DAST ツールの実行には、特に複雑な操作を要する場合、かなり時間がかかることがあります。また、そのような操作の自動化を設定できない場合、毎回のリリース前に手動で行う必要があり、完了するまでに数日から数週間かかることもあります。

SAST 対 DAST で比較すると、検出されたセキュリティの問題を修正する方が簡単かつ安価にできることに加えて、開発プロセスの早い段階で使用できるため、SAST の方が全体的に優れているように思えるかもしれません。ただし、DAST ツールに大きなメリットがあることも確かです。