DASTとRASPの違い：アプリケーションセキュリティを理解する

脆弱性の積極的な発見とリアルタイムの脅威防御を、どのように両立すればよいのでしょうか？

現代のアプリケーションセキュリティには、重大な課題があります。ソフトウェアを安全に保つには、デプロイ前に脆弱性を特定すると同時に、実行時の攻撃からも防御する必要があります。前者に優れているのがDASTで、後者を担うのがランタイムアプリケーション自己保護（RASP）です。API中心のアーキテクチャ、クラウドネイティブなデプロイ、そして巧妙化する攻撃手法が広がる今、多層的なセキュリティ戦略が求められています。デプロイ前のテストだけでも、実行時の保護だけでも十分ではありません。

ここでは両方のテクノロジーを詳しく見て、セキュリティプログラムにおけるそれぞれの役割と、包括的なアプリケーションセキュリティを実現するための連携方法を解説します。

DASTを理解する：脆弱性を積極的に発見する

DASTは、重要なブラックボックステスト手法です。稼働中のWebアプリケーションやAPIを外部から調査し、攻撃者が弱点を探る様子を、ソースコードや内部アーキテクチャの知識なしで再現します。DASTは現実の攻撃シナリオをシミュレートし、悪意あるペイロードを送信してアプリケーションの応答を確認します。この外部からの視点により、開発者やAIイノベーターは新しいWebアプリケーションをすばやく立ち上げ、本番環境に到達する前に悪用可能な脆弱性を特定できます。

DASTの特徴

• ブラックボックステストのアプローチ：ソースコードや内部アーキテクチャへのアクセスを必要とせず、アプリケーションを「閉じた箱」として外部からテストします

• デプロイ前に重点：ソフトウェア開発ライフサイクル（SDLC）のテスト、品質保証（QA）、ステージングの各段階で主に使用します

• 現実の攻撃をシミュレート：SQLインジェクション、クロスサイトスクリプティング（XSS）、認証の不備、安全でないAPIエンドポイント、設定ミスなどの脆弱性を特定します

• CI/CDとの統合：最新のDASTツールは、c継続的インテグレーションおよび継続的デリバリーのパイプライン内でセキュリティスキャンを自動化し、脆弱なコードが次の段階に進むのを防ぐセキュリティゲートを提供します

AI駆動型DASTソリューションを選ぶ理由

DASTは、アプリケーションセキュリティテストのライフサイクルで重要な役割を果たします。特に、開発の早い段階でテストを行う「シフトレフト」セキュリティの取り組みで欠かせません。Snyk API & Webのような最新のAI駆動型DASTプラットフォームは、人工知能と機械学習を活用して脆弱性検出の精度を高め、誤検知を減らし、検出結果のトリアージと優先順位付けを自動化します。AIアルゴリズムは過去のスキャンからパターンを分析し、データを相互参照したうえで、現実のリスクに基づいて脆弱性を順位付けするため、より迅速な修正が可能になります。

API中心のアーキテクチャの普及を受け、DASTツールはAPIセキュリティテスト機能を強化しています。最新のDASTソリューションは、REST、GraphQL、SOAPのエンドポイントを含む複雑なAPIをマッピング、スキャン、テストし、認証の不備、安全でないエンドポイント、過剰なデータ露出などの脆弱性を検出できます。CI/CDパイプラインと緊密に統合することで、コード変更のたびにスキャンを自動実行し、新規または更新されたAPIエンドポイントをすみやかに評価できます。

さらに、さまざまな形態のAIエージェント（ボットなど）といったLLM搭載アプリケーションでは、POST /api/chat,のように、プロンプトを受け取って応答を返すAPIエンドポイントが公開されるケースが増えています。こうした新しいWeb・API中心のアプリケーションの登場により、プロンプトを通じてさまざまなシステム動作を引き起こせる、AI駆動型DASTの必要性が高まっています。

実環境におけるDASTの機能

実際のシナリオを考えてみましょう。開発チームが大規模リリースを前に、WebアプリケーションをスキャンするためDASTを導入します。スキャン中、DASTはサードパーティ製決済ゲートウェイとの連携に、認証回避の脆弱性を発見します。この脆弱性を悪用すると、攻撃者は認証チェックを回避し、顧客の機密性の高い決済データにアクセスできます。テスト段階で問題を特定できれば、チームはデプロイ前に欠陥を修正し、本番環境でのデータ侵害や規制上の罰則を防げます。

DASTはデプロイ前に悪用可能な脆弱性を見つけるのに優れていますが、テスト中にしか動作しません。アプリケーションが稼働し、実際のユーザーにサービスを提供し始めると、DASTでは攻撃から保護できません。この制約が、実行時の保護メカニズムが必要な理由です。

RASPを理解する：実行時のリアルタイム保護

RASPは、アプリケーションのランタイム環境に直接組み込まれるセキュリティテクノロジーです。外部からテストするDASTとは異なり、RASPはアプリケーション内部で動作します。アプリケーションの挙動を継続的に監視し、悪意ある活動を検出して、本番環境での実行中に発生する攻撃をリアルタイムでブロックします。RASPはアプリケーションのロジック、データフロー、制御フローを深く可視化し、コンテキストに応じた保護を提供します。

RASPの特徴

• 実行時の保護：本番環境で常時稼働し、アプリケーションの挙動を24時間365日監視します。脆弱性を悪用しようとする脅威をリアルタイムでブロックします

• アプリケーションへの組み込み：アプリケーションのランタイム、アプリケーションサーバー、または仮想マシンに直接統合し、コードの実行経路、データ処理、システムコールを深く可視化します

• コンテキストに応じた防御：アプリケーションロジック、データフローのパターン、制御フローに関する知識を利用し、正当なリクエストと悪意ある攻撃を高い精度で見分けます

• ゼロデイ攻撃の緩和：シグネチャベースのパターン照合だけに頼らず、挙動分析や異常検知に基づいて未知の脅威や新たな攻撃手法を検出し、ブロックできます

AI駆動型RASPソリューションの仕組み

RASPはランタイム環境内で高度な仕組みを通じて動作します。RASPエージェントはアプリケーションコードにインストルメンテーションを施し、重要な実行ポイントにフックして、入力、実行経路、出力を監視します。SQLインジェクションの試み、不正なデータアクセス、コマンドインジェクションのパターンなど、不審な挙動を検出すると、セキュリティチームへの通知、インシデントの記録、被害が発生する前の攻撃の即時ブロックが可能です。最新のRASPソリューションでは、挙動分析にAIや機械学習を活用するケースが増えています。こうした高度なシステムは、アプリケーションの挙動パターンを分析して異常を特定し、本番環境の脆弱性と有効な脅威インテリジェンスを関連付けることでゼロデイ攻撃を検出します。

次の例を考えてみましょう。本番稼働中のECアプリケーションが、Webアプリケーションファイアウォール（WAF）を含む境界防御をすり抜ける、巧妙なゼロデイSQLインジェクション攻撃に突然さらされます。攻撃者は、新たにデプロイされた機能に存在する未知の脆弱性を悪用する、これまでにないペイロードを仕掛けました。アプリケーション内で動作するRASPは、実行コンテキストとデータフローを分析して悪意あるSQLパターンをリアルタイムに検出します。アプリケーションの停止や緊急パッチ、サービス中断を必要とせず、攻撃を即座にブロックしてデータの流出を防ぎ、セキュリティチームに通知します。チームは、本番環境を保護したまま根本原因を調査し、修正できます。

RASPは本番環境における「最後の防衛線」として、デプロイ前のテストで見逃された脅威や、アプリケーション稼働後に発生した脅威から保護します。ただし、RASPはDASTなどの積極的なテスト手法を置き換えるのではなく、補完するものです。RASPは脆弱性を狙う攻撃を緩和しますが、脆弱性そのものをなくすわけではありません。

DASTとRASPの主な違い：テストと保護

最も重要な違いは次のとおりです。DASTは、本番環境に到達する前に脆弱性を見つけて修正するための、積極的なテスト手法です。一方、RASPは実行時にアプリケーションを防御する、事後対応型の保護メカニズムです。

DASTは開発時の品質保証プロセスの一部としてCI/CDパイプラインに組み込まれ、リリース前にコードがセキュリティ基準を満たしていることを確認します。対照的にRASPは運用セキュリティ基盤として、本番環境で継続的に稼働し、現実の攻撃から防御します。

この2つのテクノロジーは競合するものではなく、相互に補完するものです。アプリケーションのデプロイ後、DASTはリアルタイムの攻撃から保護できません。RASPは脆弱性を根本からなくしたり、安全でないコードの作成を防いだりすることはできません。特に脅威が急速に進化し、攻撃対象領域が絶えず拡大するハイブリッド環境やクラウドネイティブ環境では、両方を組み合わせることが包括的なアプリケーションセキュリティの標準になりつつあります。

DASTとRASPの強みと制約を分析する

それぞれのテクノロジーはソフトウェアライフサイクルの異なる段階で独自の価値を発揮しますが、互いに補える制約もあります。

DASTの強み：

• 現実の攻撃シナリオをシミュレートし、攻撃者の外部からの視点で、アプリケーションが実際にどのように悪用されるかを特定します

• 稼働中のアプリケーションで悪用可能な脆弱性を特定します。設定ミス、連携の不備、静的解析では見逃される可能性のある複雑なビジネスロジックの問題も検出できます

• ソースコードへのアクセスが不要なため、内部コードを確認できないサードパーティ製アプリケーション、ベンダーソフトウェア、レガシーシステム、APIのテストに効果的です

• 早期検出によって根本原因の修正が可能になり、本番環境へのデプロイ前にセキュリティ負債を防ぎ、修正にかかるコストと複雑さを軽減できます

DASTの制約：

• テスト段階でしか動作しないため、アプリケーションが本番環境にデプロイされた後は保護を提供できません

• アプリケーション内部のロジックやコードレベルの実装詳細を把握しにくく、特定の種類の脆弱性を見逃す可能性があります

• 複雑なビジネスロジックの脆弱性や、アプリケーションへの深い理解が必要な高度な認証・認可の不備を見逃すことがあります

• 誤検知が発生する場合があり、効果的なトリアージには手動での検証とセキュリティの専門知識が必要です

• テスト範囲はスキャン設定、クローリングの有効性、テストケースの網羅性に左右され、見落としが生じる可能性があります

一方、RASPはまったく異なる方式で動作し、独自のメリットとトレードオフがあります。

RASPの強み：

• 本番環境でリアルタイムに保護し、ゼロデイ攻撃やテストでは検出できなかった未知の脆弱性を含む攻撃を防ぎます

• コンテキストを考慮した防御では、アプリケーションの動作、データフローのパターン、実行コンテキストを深く理解することで、攻撃と正当なトラフィックを正確に見分けます

• 実行時のインテリジェンスと、実際のアプリケーションの状態やユーザーの意図を把握できるため、外部のセキュリティツールと比べて誤検知率が低くなります

• 攻撃者が回避するケースが増えているWebアプリケーションファイアウォール（WAF）やネットワークセキュリティ制御などの境界防御をすり抜ける脅威から保護します

• 進化する脅威に適応できるため、ただちにコードを変更したり、緊急パッチを適用したり、アプリケーションを再デプロイしたりする必要はありません。修正の開発中も継続的に保護します

RASPの制約：

• 脆弱性の特定や排除はできず、脆弱性を悪用する攻撃を緩和するだけのため、コードベースに根本的なセキュリティ上の欠陥が残ります

• 実行時のパフォーマンスに影響する可能性があります。アプリケーションの複雑さ、トラフィック量、RASPの設定によって異なりますが、通常は2～8%程度です

• 正当なアプリケーションの動作を妨げたり、有効なユーザーリクエストをブロックしたりしないよう、慎重な統合とチューニングが必要です

• 有効性は適切な計装と設定に左右されるため、正しく導入・運用するには専門知識が必要です

• 事前の脆弱性テストやセキュアコーディングの代わりにはなりません。根本原因ではなく、その結果として現れる問題に対処するものだからです

• 導入、継続的な管理、インシデント対応に専門スキルが必要となる場合があり、人員確保やトレーニングが課題となります

互いを補完する強みと、重複しない制約があるため、先進的なセキュリティプログラムでは、階層型防御戦略の一環として両方のテクノロジーを導入しています。DASTは開発中に脆弱性の根本原因に対処し、RASPは本番環境の実行時に悪用を防ぎます。

DASTとRASPの実用的なユースケースと用途

DASTとRASPをいつ適用するかを理解することは重要です。どちらを選ぶかは、具体的なセキュリティ目標とアプリケーションのライフサイクルの段階によって決まります。2025年までに、成熟したセキュリティプログラムの大半が、両テクノロジーにはそれぞれ異なる重要な役割があると認識しています。

DASTのユースケース：

1. デプロイ前のセキュリティ検証：リリース前にWebアプリケーションやAPIをスキャンし、認証メカニズム、セッション管理、データ検証、認可制御における悪用可能な脆弱性を特定します

2. サードパーティ統合のテスト：ソースコードにアクセスできない、またはアクセスが現実的でない外部API、決済ゲートウェイ、SaaS統合、ベンダー提供コンポーネントのセキュリティリスクを評価します

3. コンプライアンスと監査要件：定期的な脆弱性評価とセキュリティテスト、およびその記録を求める規制基準（PCI DSS、HIPAA、SOC 2、ISO 27001）に対応します

4. CI/CD全体の継続的なセキュリティ：DevOpsパイプラインに自動化されたセキュリティゲートを組み込み、脆弱なコードがステージング環境や本番環境に進むのを防ぎます

5. APIセキュリティ評価：REST、GraphQL、SOAP APIをテストし、インジェクションの欠陥、認証の不備、過剰なデータ公開、レート制限の欠如、安全でないAPI設計パターンを検出します

RASPのユースケース：

1. 本番環境の保護：稼働中でインターネットに公開されているアプリケーションへの攻撃を継続的に監視・ブロックします。機密データや高額取引を扱う重要システムで特に有効です

2. ゼロデイ脅威の緩和：パッチが未適用、またはテスト時に発見されなかった未知の脆弱性や新たな攻撃手法から防御します

3. レガシーアプリケーションのセキュリティ：ビジネス上の制約、技術的負債、リソース不足などにより、セキュリティ修正を簡単に適用・リファクタリング・再デプロイできない古いアプリケーションを保護します

4. 価値の高い標的の保護：機密データ（個人識別情報、金融情報、医療記録）を扱うアプリケーションや、リアルタイム防御が必要な重要なビジネス機能を支えるアプリケーションを保護します

5. コンプライアンスと監査証跡：規制報告、コンプライアンス監査、セキュリティ調査に活用できる詳細なログ、攻撃の試みを示すフォレンジック証拠、セキュリティインシデントの記録を提供します

包括的な保護には、階層型のアプローチを推奨します。顧客の取引や機密性の高いアカウントデータを扱う金融サービスアプリケーションを例に考えてみましょう。セキュリティチームは、毎週のCI/CDパイプラインスキャンでDASTを使用し、各リリース前にSQLインジェクション、認証の不備、安全でないAPIエンドポイントなどの脆弱性を特定して修正します。一方、RASPは本番環境で継続的に稼働し、ゼロデイ攻撃、高度な標的型攻撃、境界防御をすり抜ける巧妙なエクスプロイトの試みから保護します。この組み合わせにより、脆弱性の根本原因（DAST）と、実環境で悪用される可能性（RASP）の両方に対処できます。

導入時の検討事項と選定基準

DASTとRASPのどちらを選ぶか、あるいは両者を効果的に組み合わせる方法を判断するには、組織の優先事項と技術的な現実の両方を評価する必要があります。適切な戦略は、アプリケーション環境とセキュリティ態勢を明確に把握することから始まります。単にツールを選ぶのではなく、セキュリティ機能をビジネスリスク、開発の成熟度、運用上の制約に合わせることが重要です。

主な選定要因：

• アプリケーションのライフサイクル段階：DASTは開発、テスト、QAの各段階に自然に組み込めます。RASPは本番環境の実行時に特化しています

• セキュリティ目標：脆弱性の事前排除（DAST）とリアルタイムの攻撃防止（RASP）のどちらを優先するかを判断します

• 利用可能なリソース：担当者の専門知識、予算の制約、継続的なメンテナンス要件、これらのテクノロジーを管理するセキュリティ担当者や開発担当者の有無を考慮します

• パフォーマンス要件：DASTはテスト環境で実行されるため本番環境に影響しません。RASPは実装方法によって、実行時の負荷が高くなる可能性があります

• アプリケーションアーキテクチャ：クラウドネイティブアプリケーションやコンテナ化されたアプリケーションは、最新のRASP導入モデルと特に相性が良いといえます

• 規制要件：一部のコンプライアンスフレームワークでは、特定のテスト手法（PCI DSSにおけるDAST）や実行時の保護機能（重要インフラにおけるRASP）が義務付けられています

• リスク許容度：価値が高い、インターネットに公開されている、または規制対象のアプリケーションでは、セキュリティとコンプライアンスの要件を満たすために、両方の保護層が必要になる場合があります

まずは、セキュリティテストの基本的な実践としてDASTを導入し、CI/CDパイプラインに自動スキャンを組み込んで、脆弱性が本番環境に持ち込まれるのを未然に防ぐことをお勧めします。この「シフトレフト」アプローチはコスト効率に優れ、根本原因に対処し、開発文化にセキュリティを根付かせます。

リソースが限られている組織は、まずDASTテストを優先し、脆弱性の根本原因に対処して修正できる体制を整えましょう。テストプロセスが成熟し、基本的なセキュリティプラクティスが確立したら、露出度が高い、規制要件のある、または機密データを扱う重要なアプリケーションにRASPを導入するか検討します。成熟したセキュリティプログラムを持つ企業は、多層防御戦略の補完的な要素として両方を導入し、DASTによる事前テストとRASPによる実行時保護を活用するべきです。

今後は、セキュリティプラットフォームがDASTやRASPの機能を、静的アプリケーションセキュリティテスト（SAST）やソフトウェア構成分析（SCA）などの他のテスト手法と統合し、収束していくと見られます。こうした統合プラットフォームは、複数のセキュリティツールにAI主導の脅威インテリジェンス、一元管理ダッシュボード、自動化されたワークフローを組み合わせ、ソフトウェアライフサイクル全体にわたる包括的なアプリケーションセキュリティ管理を実現します。

Snykでアプリケーションを保護

包括的なアプリケーションセキュリティを実現するには、開発ライフサイクル全体にわたって脆弱性に対処する統合戦略が必要です。アプリケーションのセキュリティは後回しにしたり、開発を遅らせるボトルネックにしたりするものではありません。ソフトウェアの作成からデプロイまで、あらゆる段階にシームレスに組み込むべきものです。

SnykのAI搭載開発者向けセキュリティプラットフォームはこの考え方を体現し、この記事でご紹介した階層型セキュリティアプローチの導入に必要なツールを提供します。Snyk Codeは、開発者がコードを書くそばから脆弱性を検出し、リアルタイムにコードのセキュリティを分析します。Snyk Open Sourceは、本番環境で問題になる前に、オープンソースの依存関係に含まれる脆弱性を特定して修正します。Snyk Containerは、現代のインフラを支えるクラウドネイティブアーキテクチャに対応し、コンテナ化されたアプリケーションやKubernetesのデプロイを保護します。Snyk IaCは、コードとして管理するインフラを設計段階から安全に保ちます。

これらの機能は、既存の開発者ワークフロー、CI/CDパイプライン、バージョン管理システムにシームレスに統合できます。SnykのAI搭載プラットフォームは、脆弱性の検出を自動化し、実環境での悪用可能性やビジネスコンテキストに基づいて問題の優先順位を決定するとともに、インテリジェントな修正ガイダンスを提供します。DASTの原則に沿った事前の脆弱性検出と、アプリケーションスタック全体にわたる包括的な保護を実現します。

より安全なコードを書きたい開発者、包括的なAppSecプログラムを構築するセキュリティリーダー、自動化パイプラインにセキュリティを組み込むDevOpsエンジニアのいずれにとっても、Snykは2025年以降を見据えた開発者ファーストのセキュリティプラットフォームを提供します。

検出結果を修正につなげませんか？SnykがSASTとDASTを相関分析し、チームが実際のリスクに優先順位を付け、より迅速に修正する方法をご覧ください。