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

DASTツールは、アプリケーションの実装に使われたプログラミング言語など、アプリケーションに関する情報を必要としません。そのため、ニッチなプログラミング言語を使っている場合でも、アプリケーションのセキュリティを向上できます。

DASTはほかのセキュリティテスト手法とどう違うのか？

特定のセキュリティテスト手法が自社のアプリケーションテスト環境に適しているかを判断するには、そのメリットだけでなく制約も考慮することが重要です。それぞれのテスト手法の違いを見ていきましょう。

SASTとDASTとSCAの比較

静的アプリケーションセキュリティテスト（SAST）はコードに焦点を当てます。CIパイプラインの早い段階でソースコード、バイトコード、バイナリーコードをスキャンし、ベストプラクティスに反する問題のあるコーディングパターンを特定します。SASTはプログラミング言語に依存します。

動的アプリケーションセキュリティテスト（DAST）は、実行時のアプリケーションをスキャンするブラックボックステスト手法です。CIパイプラインの後半で実施されます。DASTはリグレッションの防止に有効で、特定のプログラミング言語に依存しません。

インタラクティブアプリケーションセキュリティテスト（IAST）は、実行時のアプリケーションの振る舞いに焦点を当てる点でDASTに似ています。ただしIASTの分析は、ブラックボックステスト、スキャン、アプリケーション内部のフロー分析を組み合わせて行います。IASTの利点は、DASTのような検出結果をSASTのようにソースコードに関連付けられることです。一方、プログラミング言語に依存し、CIパイプラインの後半でしか実施できないという欠点があります。

ソフトウェア構成分析（SCA）は、アプリケーションで使用されているサードパーティ製コードの依存関係に焦点を当てます。オープンソースライブラリを多く使用するアプリケーションで特に効果を発揮します。この手法もプログラミング言語に依存します。

SASTとDASTの違いと、2つを組み合わせる方法について詳しく読む。

DASTはほかのアプリケーションセキュリティテスト手法とどう組み合わせられるのか？

DASTは、SASTやSCAのような静的チェックに依存するアプリケーションセキュリティテスト手法と組み合わせるのが効果的です。静的なソースコード分析に、実行時の追加情報を提供できるためです。

多くの場合、SASTツールは個々のコードスニペットだけを見て、そのコンテキストを考慮しません。あるファイルのコードが問題と見なされても、それを使う別のファイルのコードがすべての問題に対処していることがあります。また、システムに実装したセキュリティ対策が、まったく別のコンピューター上で実行される場合もあります。たとえば、入力値のサニタイズがデータ使用直前にサーバー上で行われていても、SASTツールはその処理と関連付けられないため、サニタイズされていない入力を問題として検出します。

DASTツールは、エンドツーエンドのテストを行います。クライアントコードが入力値のサニタイズに関するベストプラクティスに従っているかどうかは把握しません。アプリケーションの入力と出力を検査し、出力がサニタイズされていれば、アーキテクチャのどこでサニタイズが行われたかは問題にしません。

ただし、特定のユースケースしかテストせず、理論上の入力を網羅しないため、エッジケースでのみ失敗するアプリケーションの部分はDASTツールの死角になることがあります。そこで役立つのがSASTやSCAのツールです。これらのツールはソースコードを調べ、DASTツールだけでは見逃される問題のある振る舞いを検出します。

たとえば、型変換によってエラーが発生したり、望ましくない出力が生じたりする場合があります。10種類の入力しかカバーしないDASTのテストケースでは問題なしと報告されるかもしれません。しかしSASTツールなら、アプリケーションの実装時に想定もしなかった特定の値で変換メソッドが失敗しやすいことを検出できます。

DASTのメリットとデメリット

DASTツールはアプリケーションを実行時にテストすることを主な機能としており、多くのメリットがある一方で、欠点もあります。DASTがソフトウェアプロジェクトに適しているかを判断できるよう、詳しく見ていきましょう。

メリット：

• 誤検知が少ない：アプリケーション全体をスキャンしないため、DASTは通常、SASTよりも誤検知が少なくなります。脆弱性が実際に存在するかをより迅速に確認し、後続の工程で防止できるかどうかを見極められます。

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

• 修正した脆弱性をすばやく再テストできる：DASTはリグレッションを防ぎます。脆弱性が見つかり、再現できた場合、その再現手順を自動化してDASTテストスイートに追加できます。これにより、以降のリリースでも、過去に問題を引き起こした操作がテストされます。問題が再発した場合も、リリース前にDASTが検出します。

デメリット：

• コードに関する情報が得られない：DASTはシステムの入力と出力だけを確認します。そのため、検出した脆弱性をコードの行に関連付けることはできません。

• テストに時間がかかる：自動テストを使う場合でも、ソフトウェアを実行して操作する必要があるため、テストに時間がかかることがあります。複数の入力パターンでサインアップの手順をクリックして進めるだけでも、時間を要します。

• CI/CDパイプラインの後半で結果が出る：DASTツールはアプリケーションを実行しなければ機能しないため、CI/CDパイプラインのかなり後半に位置します。アプリケーションが成長するにつれて、テストにかなりの時間がかかることがあります。

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

DASTを効果的に導入する方法

DASTはアプリケーションの実行を前提とするため、テストパイプラインへの追加はSASTほど簡単ではありません。DASTのプロセスは自動化できますが、自動化する部分は事前にスクリプト化または記録しておく必要があります。DASTツールをパイプラインに追加した後は、次の手順に沿って進めます。

1. ユーザーと話し合う

DAST導入の出発点として、ユーザーと話し合い、アプリケーションの使い方を記録しましょう。操作内容を記録するだけでなく、何をしているのか説明してもらいます。

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

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

次に、自動化ツールを使ってユーザーの操作をスクリプト化します。GUIアプリケーションよりもCLIやAPIのアプリケーションのほうが簡単な場合がありますが、一般的にはどの種類でも自動化できます。

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

自動操作によって重要なユースケースを網羅できたら、DASTツールでアプリケーションをスキャンしながら、これらのスクリプトを実行できます。最初のDAST実行後、脆弱性の修正に取りかかりましょう。

4. テストスイートにリグレッションテストを追加する

日常的なアプリケーションの利用中に脆弱性が見つかった場合は、特定の操作を行うスクリプトをテストスイートに追加できます。これにより、問題の再発を防げます。

まとめ

DASTは信頼性の高い脆弱性検出手法として有用ですが、DASTだけですべてをカバーできるわけではありません。一方で、アプリケーションの実装にニッチなプログラミング言語を使っている場合や、一般的なプログラミング言語向けのクローズドソースのパッケージや拡張機能を使っている場合など、DASTしか選択肢がないこともあります。

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

SASTとDASTを比較すると、検出したセキュリティの問題をより簡単かつ低コストで修正できる開発プロセスの早い段階で使えるため、全体的にはSASTのほうが優れているように見えるかもしれません。しかし、DASTツールにも大きなメリットがあります。