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

他のタイプのアプリケーション・セキュリティー（AppSec）・テストと比較すると、DASTはアウトサイド・イン・アプローチが際立っています。他のツールがセキュリティー脆弱性を評価するためにソースコードとアプリケーション内部へのアクセスを必要とするのに対し、DASTは悪意のある行為者を模倣してシミュレートされた攻撃を使用して、外部からアプリケーションのランタイム環境をテストします。このため、DASTはアウトサイド・イン・テストやブラックボックス・テストと呼ばれることがあります。これは、テスターが内部構造へのアクセスや調査をせず、あるいは内部構造に関する知識がない状態でもシステムを検査できるテスト方法です。

現在の開発者は、コードベース全体を包括的に把握できなくても、特定のコード領域を1日に複数回更新し、すばやく作業することがよくあります。サードパーティーやオープンソースのコンポーネントに大きく依存しており、セキュリティーチームとの効果的なコラボレーションに苦労していることがよくあります。またそのほとんどが、絶えず進化するサイバーセキュリティーの脅威を管理しながら、多数の機能、ライブラリー、依存関係を備えた、ますます複雑になるアプリケーションにも取り組んでいます。

その結果、セキュリティーの脆弱性が表面化する領域が常に増加し、安全なコードを書いたり、機密情報をデータ侵害から保護したりすることがますます困難になっています。開発者は、生産性を損なうことなく、作業中に潜在的な脆弱性をテストする方法を必要としています。

DASTはセキュリティー・テスト・プロセスを自動化することで、これを実現します。現実世界のハッカーの行動を模倣することで、外部から作業して実行中のアプリケーションの潜在的な脆弱性を明らかにします。DASTを使用すると、開発者はコードをテストして、公開前にアプリ全体のセキュリティーにどのように影響するかを確認でき、認証エラーやコードの脆弱性といった、ソフトウェア・コンポジション分析（SCA）などの他のテスト方法では見落とされがちなセキュリティーの問題を特定することができます。

最新のDAST（下記参照）ツールはDevOpsおよびCI/CDパイプラインにもシームレスに統合され、アプリケーション開発ワークフローの初期段階を含む開発のすべての段階にインターフェースを提供します。

ビルドとデプロイメントの統合は、DevOpsチームがソフトウェア開発ライフサイクル（SDLC）の早い段階でテストを行うことで、より費用対効果が高く時間のかからない修復を実現する「シフトレフト」アプローチの一環として、DevOps/DevSecOps環境で一般的にDASTを採用する理由の1つです。 DASTツールによって強化されるその他のDevOpsの原則には、自動化、コラボレーション、継続的なフィードバックを優先することが含まれており、開発者とセキュリティー・チームはセキュリティーを損なうことなくアジャイル性と生産性を維持できます。

DASTはブラックボックス・アプローチを採用しているため、悪意のある脅威アクターがWeb アプリケーションに侵入を試みる場合に実行する可能性のあるアクションをエミュレートします。

一般にDASTには次の5つのステップが含まれます。

DASTテスト・ツールには公式のサブタイプはありませんが、セキュリティーの専門家は最新のDASTツールとレガシーDASTツールの2つの非公式なグループに分類することがほとんどで、その主な違いは自動化／統合と脆弱性検証です。

レガシーDASTツールには自動化機能がないことがよくありますが、スキャンのプロセスは自動化されています。通常、リクエストの送信、応答の受信、予備評価などの基本的なテストに重点を置いているため、完全な脆弱性検証は提供せず、潜在的なセキュリティー問題のリストのみを提供します。

最新のDASTツールは自動化の度合いが高く、Webアプリケーションの脆弱性をより徹底的にレビューします。

最新のDASTソリューションはSDLCにシームレスに統合し、バックグラウンドで透過的に動作できます。さらに、自動化サーバーは最新のDASTツールをトリガーし、スキャン結果を開発者の問題トラッカーにチケットとして提示できます。最新のDASTツールの中にはエクスプロイテーションの証拠を提供するものもあり、ペネトレーション・テスターやセキュリティーの専門家による、時間のかかる手動検証が不要になります。

DASTは、ウェブ・アプリケーション・セキュリティー・テストの重要な一部とみなされることがよくあります。独自の長所には次のようなものが挙げられます。

• 汎用性。ユーザーはソフトウェア開発ライフサイクルのさまざまな段階でDASTをデプロイでき、DASTは実行中のWebアプリケーションや、すでにデプロイされているアプリケーションを変更なしでテストできるため、レガシー・システムの評価がより容易になります。

• オートメーション。DASTツールはDevOpsおよびCI/CDパイプラインに簡単に統合できるため、開発プロセスの早い段階で自動セキュリティー・テストを実行し、修復のコストを大幅に削減できます。

• 言語に依存しない。DASTは外部から内側に動作するため、アプリケーションで使用されるプログラミング言語に依存せず、さまざまなフレームワークで動作できます。DASTはWebインターフェースとAPIの両方を効果的にテストし、攻撃者が脆弱性を見つける方法をエミュレートします。

• 少ない誤検出。DASTは通常、ユーザー・アクションをシミュレートする際に、SASTなどの他の方法よりも偽陽性と偽陰性が少なくなります。

• 現実的で再現性のあるテスト。DASTは実際の攻撃者の行動をエミュレートするため、悪意のある行為者が悪用する可能性のある脆弱性を特定するための実用的なソリューションです。DASTにはテストが反復可能という利点もあり、アプリケーションの進化に合わせて継続的な脆弱性評価を行うことができます。

• 包括的な脆弱性の発見。DASTはSQLインジェクション、XSS、構成ミスなど、さまざまな脆弱性を発見できます。

• 業界標準との連携。多くの場合、企業は業界標準に準拠し、PCIコンプライアンスなどの規制報告を支援するためにDASTを使用しています。多くの会社はアプリケーション・セキュリティー・リスクのコンプライアンス・ベンチマークとしてOWASP Top 10リストを使用しています。

これらの多くのメリットにもかかわらず、DASTには制限がある場合があります。DASTは実行中のアプリケーションのセキュリティー上の欠陥を特定することに長けていますが、すべての脆弱性、特に特定の一連のアクションを必要とする脆弱性を明らかにするわけではありません。DASTを静的アプリケーション・セキュリティー・テスト（SAST、下記参照）、対話型アプリケーション・セキュリティー・テスト（IAST）、ソフトウェア構成解析（SCA）、手動ペネトレーション・テストなどの他の方法と組み合わせると、DASTを補完し、より包括的なセキュリティー・プログラムを提供できます。

DASTのその他の制限には、次のものがあります。

• 実行可能なコードに焦点を当てる。DASTは主に、すでにデプロイされているWebアプリケーションの一部 （つまり既に実行可能なコード）をテストするため、まだ開発中のセクションを見逃す可能性があります。

• 認証の課題。DASTは、非標準の認証や複雑なビジネス・ロジックでは効果が低下する可能性がありますが、プロフェッショナルのDASTツールには、このような状況に対応するガイダンス・モジュールが含まれています。

• 業務への影響。適切なチューニングを行わないと、DASTテストは通常のアプリケーション・オペレーションに影響を与え、サンプルデータを導入したり、アプリケーションを遅くしたりする可能性があります。その結果多くの企業は、DASTを本番ではなく、ステージングまたは本番クローン環境で実行します。

DASTとSAST、または静的アプリケーション・セキュリティー・テストは、Webアプリケーションのセキュリティーの脆弱性を特定するために使用される2つのテスト方法です。しかし、DASTが本番環境のアプリケーションを評価し、悪意のあるユーザー攻撃を模倣してセキュリティー問題を特定するのに対し、SASTはソースコードを掘り下げて、Webサイト・アプリケーションの脆弱性を探します。

一般的にサイバーセキュリティーの専門家は、セキュリティー・リスクに対処する際にSASTとDASTの両方を使用して、潜在的な脆弱性を完全に把握することを推奨しています。たとえばSASTツールは、プログラムのソースコードを調査する際に、SQLインジェクション、バッファー・オーバーフロー、XXE攻撃、その他のOWASP Top 10リスクなど、DASTが見逃す可能性のあるさまざまなセキュリティーの脆弱性を明らかにすることができます。

また、SASTの方法論を使用することで、開発中の早期テストが促進され、後のフェーズでアプリケーションのソースコードにセキュリティー上の欠陥が発生する可能性が減り、開発期間が短縮され、全体的なセキュリティーが向上します。