In this article
SAST・DAST・IAST・RASPの比較:アプリケーションセキュリティテスト手法を理解する
現代のソフトウェア開発におけるアプリケーションセキュリティテストを理解する
アプリケーションセキュリティテストとは、攻撃者に悪用される前に、ソフトウェアアプリケーションを体系的に調査し、セキュリティ脆弱性やコーディングエラー、潜在的な脅威の侵入口を特定する手法です。主なテスト手法はSAST、DAST、IAST、RASPの4つです。これらは、この課題に対する根本的に異なるアプローチを表しています。それぞれが、最初のコードコミットから本番環境での稼働まで、開発・デプロイのライフサイクルにおける特定の段階を対象とします。
アプリケーションセキュリティで複数のテスト手法が重要な理由
単一のセキュリティテスト手法だけで、すべての脆弱性を網羅することはできません。1つのテスト手法だけに頼る組織には、大きな見落としが生じます。そのため、効果的なDevSecOpsを実現し、複雑な本番環境を保護するには、相互に補完し合う手法を組み合わせることが欠かせません。
SASTツールは誤検知が多くなる場合がある一方、実行時にのみ顕在化するランタイム脆弱性を見逃す可能性があります。一方、DASTは偽陰性を生むことがあります。到達できないコードパスに存在するビジネスロジックの欠陥を見落とすためです。その結果、危険な誤った安心感が生まれます。
現代のアプリケーションセキュリティ戦略では、ソフトウェア開発ライフサイクル全体に複数のテスト手法を組み込む必要があります。SASTは開発段階のコーディング中に問題を検出し、DASTは攻撃シミュレーションによってデプロイ済みアプリケーションの動作を検証します。IASTはソフトウェアのインストルメンテーションを通じてテスト中にリアルタイムでフィードバックを提供し、RASPは本番環境でアプリケーションを積極的に保護します。これらを組み合わせることで、あらゆる段階の脆弱性に対応する包括的な多層防御を実現できます。
SAST・DAST・IAST・RASPの比較
機能・特性 | SAST | DAST | IAST | RASP |
|---|---|---|---|---|
実行タイミング | 開発中(ビルド時) | テスト中、またはデプロイ済みアプリ上 | 機能テスト中 | 本番環境(実行時) |
仕組み | 実行せずにソースコード、バイトコード、バイナリを分析 | 外部から稼働中のアプリに攻撃を仕掛ける | アプリをインストルメント化し、テスト中に監視 | アプリに組み込まれ、攻撃をリアルタイムで監視・ブロック |
ソースコードへのアクセス | 必要 | 不要 | 通常は必要 | 必要(アプリ内にエージェントを配置) |
テスト方式 | アプリ内保護 | |||
検出する脆弱性 | コードロジック、安全でない関数、データフロー | 実行時の問題、設定エラー、認証の不備 | コードと実行時の動作 | リアルタイムで悪用可能な攻撃 |
精度 | 誤検知が発生する場合がある | 誤検知は少ないが、コードの深い部分にある欠陥を見逃す場合がある | 精度が高く、誤検知が少ない | 非常に高精度(実際の攻撃を検知) |
検出できる ゼロデイ脆弱性 | いいえ | 場合による | 場合による | はい(悪用行為をブロック) |
攻撃をブロックできるか | ❌ いいえ | ❌ いいえ | ❌ いいえ | ✅ はい |
CI/CDとの連携 | 非常に優れている | 中程度 | 良好(稼働中のアプリとテストが必要) | CI向けではなく、本番環境で実行 |
パフォーマンスへの影響 | 実行時の影響なし | 影響なし(テスト段階のみ) | テスト中に多少のオーバーヘッドが発生 | 本番環境で多少のオーバーヘッドが発生 |
検出に最適な対象 | 開発初期段階のコーディング上の欠陥 | デプロイ済みアプリの脆弱性 | コンテキストに基づく悪用可能な脆弱性 | 進行中の攻撃の試み |
攻撃対象領域のカバレッジ | コードベース全体 | 公開されているエンドポイントのみ | テストで実行されたコードパス | 攻撃者が到達できる範囲のみ |
主な目的 | 早期に脆弱性を防ぐ | リリース前に欠陥を発見する | 実際に悪用可能かを検証する | 本番環境で攻撃を阻止する |
SDLC全体におけるアプリケーションセキュリティテスト
SDLCの段階 | セキュリティツール | 主な目的 |
|---|---|---|
要件定義 | — | セキュリティ基準を定める |
設計 | — | 安全なアーキテクチャを計画する |
開発 | SAST | コーディング上の欠陥を早期に検出する |
開発 | IAST(任意) | 単体テスト・結合テスト中に脆弱性を確認する |
テスト/QA | DAST | 攻撃者の視点から稼働中のアプリをテストする |
テスト/QA | IAST | 機能テスト中に悪用可能性を監視する |
本番移行前 | DAST | ステージング環境でアプリを検証する |
本番移行前 | IAST | 重要なコードパスのカバレッジを確認する |
本番環境 | RASP | リアルタイム攻撃をブロックする |
本番環境 | 監視ツール | 異常や脅威を検知する |
SAST:ソースコードを保護する
開発ワークフローに組み込むと、SASTツールは開発者が変更をコミットする際にコードを調査し、SQLインジェクションの可能性、クロスサイトスクリプティング(XSS)の脆弱性、バッファオーバーフロー、ハードコードされた認証情報、安全でない暗号実装などの問題にフラグを立てます。このコード解析はアプリケーションの実行前に行われるため、修正が最も安価で簡単な段階で早期に修正できます。
SASTの強み:セキュリティを左にシフト
SASTの強みは、SDLCの早い段階にセキュリティを組み込めることです。主なメリットは次のとおりです。
脆弱性を早期に検出:開発段階でセキュリティ上の欠陥を特定します。本番環境の脆弱性を修正する場合と比べ、修正コストを最大100分の1に削減できます
コードを包括的にカバー:動的テストでは見逃される可能性がある、ほとんど実行されない分岐を含め、コードパスの100%を分析します
学習効果:安全なコーディング手法について開発者にすぐにフィードバックを提供し、セキュリティ意識を高め、ソフトウェア全体のセキュリティを向上させます
自動化機能:CI/CDパイプラインにシームレスに統合し、開発速度を落とさず継続的にセキュリティを評価します
SASTはソースコードレベルで脆弱性を特定することで、開発者が安全なコーディング手法を学べるようにし、欠陥のあるコードが本番環境に到達するのを未然に防ぎます。
SASTの限界:実行時の見落とし
強みがある一方で、SASTには大きな限界もあります。実行時のコンテキストがないため、誤検知が多くなります。実際の実行では悪用できない可能性のある脆弱性にもフラグを立てます。たとえば、ユーザー入力から到達できないコードにあるSQLインジェクションの脆弱性を検出することがあります。
SASTでは、設定エラー、デプロイ環境における認証バイパスの問題、実行環境でのコンポーネント間の相互作用から生じる脆弱性など、実行時の脆弱性を検出できません。また、このテスト手法は現代の開発パラダイムの一部にも対応しきれません。動的型付け言語、フレームワーク固有のセキュリティ制御、ビジネスロジックの欠陥は、静的コード解析では見つからないことがよくあります。
こうしたテスト段階での限界があるため、SASTは実際のアプリケーションの動作を検証する実行時テスト手法で補完する必要があります。
AppSecにおけるDAST:攻撃者の視点
DASTツールはアプリケーションのインターフェースをクロールしてフォーム、API、URLパラメーターなどの侵入口を特定し、体系的に脆弱性をテストすることで攻撃をシミュレートします。インジェクション攻撃(SQL、コマンド、LDAP)、認証の弱点、セッション管理の不備、設定エラー、安全でないサーバー設定などを調査します。この実行時分析により、本番環境で攻撃者が実際にどのようにアプリケーションを悪用するかを把握でき、外部の脅威から見た実際のセキュリティ状況を明らかにします。
DASTの強み:実行時の脆弱性を検出
DASTは、静的な手法では検出できない実行時の脆弱性の特定に優れています。設定エラー、認証バイパスの問題、サーバー側の脆弱性、アプリケーションコンポーネント間の連携の問題、環境固有の弱点は、アプリケーションが実行環境で動作して初めて明らかになります。
ペネトレーションテストや正式なセキュリティ評価において、DASTは非常に有用な検証手段です。SASTで特定された理論上の脆弱性が、デプロイ環境で実際に悪用できるかを確認し、アプリケーションの実際の動作をテストすることで誤検知を大幅に減らします。また、ソースコード分析だけでは明らかにならない設定ミスや連携上の問題も検出します。
DASTの限界:コードカバレッジの課題
外部からの視点でテストするDASTには、大きな見落としが生じます。コードカバレッジを把握できないため、DASTがテストできるのは検出してアクセスできるインターフェースに限られます。その結果、特定の認証状態や複雑な複数ステップのワークフロー、スキャナーが到達できない認証済みのシナリオを必要とするコードパスに脆弱性が存在すると、偽陰性が生じます。
DASTはアプリケーションが完全に動作する必要があるため、開発初期段階には適していません。特にエンドポイントの多い大規模なアプリケーションでは、スキャンに時間がかかることがあります。本番環境でのテストは、稼働中のサービスを中断させたり、セキュリティアラートを発生させたり、パフォーマンスを低下させたりするリスクがあります。また、検出した問題が本当に悪用可能かを判断する内部コンテキストがないため、外部スキャンによる誤検知も発生します。
IAST:ハイブリッドアプローチ
IASTは、ソフトウェアのインストルメンテーションを通じて静的テストと動的テストを組み合わせるハイブリッドなテスト手法です。IASTツールはアプリケーションの実行環境にインストルメンテーションエージェントを直接配置し、Webサーバー、コンテナ、アプリケーションフレームワークにセンサーを組み込んで、実行中の動作を監視します。
これらのセンサーは、コードの実行パス、データフロー、HTTPリクエストとレスポンス、セキュリティに関係するイベントをリアルタイムで追跡します。機能テストやQA作業、実運用中にアプリケーションが実行されると、IASTは汚染解析を行います。この手法では、信頼できない入力を侵入口からアプリケーション内へと追跡し、変数、関数、コンポーネント間を流れるデータを監視します。
IASTの強み:コンテキストを考慮した脆弱性検出
IASTは、ホワイトボックスのコード可視性と実行時の検証を組み合わせることで、単独のSASTやDASTよりも高い精度を実現します。主なメリットは次のとおりです。
誤検知を削減:実際の実行コンテキストで脆弱性を検証し、SASTが不必要に指摘するデッドコードパスを除外します
脆弱性を正確に報告:問題発生時の正確なコード行番号、実行コンテキスト、完全なスタックトレース、アプリケーションの状態を提示します
開発者に役立つフィードバック:CI/CDパイプライン内で、すぐに実行できる修正方法を提示し、修正までの時間を短縮します
ビジネスロジックの欠陥を検出:複数ステップのワークフロー、状態管理の問題、複雑なデータフローから生じる脆弱性を特定します
IASTは、悪用可能性の確認とコンテキストに基づく判定によって誤検知を最小限に抑え、より広いカバレッジによって偽陰性も減らします。このハイブリッドなアプローチにより、従来のテスト手法で問題となる両方のエラーを大幅に減らせます。
IASTの限界と導入時の考慮事項
IASTは実行環境とソフトウェアのインストルメンテーションに依存するため、運用上の制約があります。アプリケーションを実際に稼働させて操作する必要があるため、実行前のコードレビューだけでは問題を検出できません。インストルメンテーションエージェントによってパフォーマンスのオーバーヘッドが発生する場合がありますが、最新のIASTツールでは、センサーの効率的な設計と選択的な監視によって影響を最小限に抑えています。
IASTは、テストカバレッジが十分に確保されたDevOpsのセキュリティワークフローに組み込むと、最も効果を発揮します。自動テストスイートがアプリケーションの機能を実行し、IASTセンサーがセキュリティ上の影響を分析します。そのため、頻繁に更新されるアジャイル開発環境での継続的なテストに特に有用です。
適切な計装エージェントの設定やテストフレームワークとの統合が必要となるため、SASTやDASTよりセットアップが複雑になる場合があります。しかし、アプリケーションセキュリティの包括的な実現に取り組む組織にとって、精度と実用的な知見の向上という成果は、初期投資に見合うものです。
RASP:本番環境でのアクティブな防御
RASPは、脆弱性の検出から、脅威の検知と防止へと重点を移します。開発者が修正すべき欠陥を特定するテスト手法とは異なり、RASPはアプリケーションの実行環境に直接組み込まれ、実行時の挙動を監視し、リクエストをリアルタイムで分析して、被害が発生する前に悪意あるアクティビティをブロックします。
RASPツールはアプリケーションサーバーと連携し、すべての関数呼び出し、データアクセス、システムとのやり取りを監視します。動作分析と実行時のコンテキストを用いて、正当なアプリケーションの挙動と攻撃の試みを見分けます。SQLインジェクション、コマンドインジェクション、不正なデータアクセスなどの悪用を検知すると、通常のアプリケーション機能を継続させながら、悪意あるリクエストを直ちにブロックします。
RASPの強み:脅威を即座に軽減
RASPの最大の特長は、本番環境で攻撃を積極的に防止できることです。SAST、DAST、IASTが開発者による修正を前提に脆弱性を特定するのに対し、RASPはゼロデイ攻撃や未修正の脆弱性から、アプリケーションをリアルタイムで保護します。この実行時のアプリケーション自己保護は、すぐにパッチを適用できない場合に非常に有効です。修正不可能なセキュリティ上の欠陥があるレガシーアプリケーションにも、防御機能を提供します。
最新のRASPソリューションでは、AIと機械学習を活用した適応型の脅威分析により、動作プロファイリングを通じて誤検知を減らし、実行時のパターンに基づくプロアクティブな脆弱性検知を実現します。最新の調査によると、機械学習モデルは通常のアプリケーション動作からの逸脱を検知することでゼロデイ攻撃を特定し、シグネチャベースの手法を超える保護を提供します。
RASPは動作分析によって高い精度と低い誤検知率を実現し、アプリケーションのパフォーマンスを維持しながら攻撃を積極的に防止します。
RASPの制約:パフォーマンスと適用範囲
RASPは実行時のすべての処理を検査するため、パフォーマンスに影響を与える可能性があります。最新の実装では、最適化されたセンサーや選択的な監視によって影響を最小限に抑えていますが、リソースを大量に消費するアプリケーションでは、遅延が測定可能なレベルで発生することがあります。組織はセキュリティ上のメリットとパフォーマンス要件のバランスを取る必要があります。
さらに重要なのは、RASPではデプロイ前に脆弱性を特定したり修正したりできないことです。既存の欠陥に対する悪用の試みを軽減するにとどまります。本番環境に依存するため、デプロイ前のセキュリティ検証は行えません。そのため、開発やテストの段階で脆弱性を特定して修正するには、引き続きSAST、DAST、IASTが必要です。
包括的なアプリケーションセキュリティの実現に向けた導入の推奨事項
多層的なセキュリティテスト戦略の構築
多層的な戦略を採用すれば、特定のセキュリティテストツールを、SDLCの各段階や組織の成熟度に合わせて適切に活用できます。
段階的な導入アプローチ:
基盤フェーズ:まず、SASTをバージョン管理とCI/CDパイプラインに統合します。セキュリティポリシーの基準を定め、開発者にセキュアコーディングを教育し、検出結果を担当チームに割り当てる修正ワークフローを構築します。
検証フェーズ:ステージング環境にDASTスキャンを追加します。SASTで特定された脆弱性がデプロイ環境で実際に悪用可能かを検証し、静的解析では検出できない実行時の設定上の問題を発見します。
強化フェーズ:十分なテストカバレッジがある重要度の高いアプリケーションにIASTを導入します。コンテキストを考慮した分析で誤検知を減らし、正確で実用的なガイダンスを開発者に提供して、修正を迅速化します。
保護フェーズ:ゼロデイ攻撃やレガシーの脆弱性に対するアクティブな防御が必要な重要アプリケーションの本番環境に、RASPを導入します。コードの変更が不可能、または遅れている場合の最終的なセキュリティ層として活用します。
この段階的なアプローチにより、開発チームやセキュリティリソースに過度な負担をかけずに、セキュリティ機能を着実に強化できます。
DevOpsセキュリティの統合と自動化
セキュリティテスト手法の有効性は、自動化とDevOpsとの統合に大きく左右されます。DevSecOpsでは自動化が中心的な役割を果たします。パイプラインに組み込まれたツールがリアルタイムのフィードバックとポリシー適用を行い、セキュリティ上のチェックを回避できないようにします。
脆弱なコードがデプロイパイプラインを先に進まないよう、セキュリティゲートを設定します。悪用可能性、実行時のコンテキスト、ビジネスへの影響に基づいて検出結果の優先順位を付け、脆弱性のトリアージを自動化します。これによりノイズを減らし、セキュリティチームが真のリスクに集中できるようになります。
CI/CD統合のベストプラクティス:
SASTをプルリクエストの検証に統合し、重大または高深刻度の問題が検出された場合はマージをブロックする
IASTを自動テストの実行に組み込み、テストのたびにセキュリティ分析を実施する
本番前のデプロイ検証の一環として、DASTスキャンをスケジュールする
明確な修正ガイダンスとSLAの要件を添えて、検出結果を開発チームに届けるフィードバックループを確立する
アプリケーションセキュリティツールの選定基準
アプリケーションセキュリティのテスト手法やツールを評価する際は、次の主な基準を重視します。
言語とフレームワークのサポート:最新のフレームワーク、動的型付け言語、クラウドネイティブアーキテクチャを含め、自社の技術スタックに対応していることを確認する
統合機能:GitHub、GitLab、Jenkins、コンテナ化プラットフォームなど、既存のCI/CDやDevOpsセキュリティツールチェーンとシームレスに統合できることを確認する
精度の指標:自社を代表するアプリケーションで概念実証テストを行い、誤検知率と見逃し率を評価する
開発者の使いやすさ:修正ワークフローの効率、検出結果の実用性、開発プロセスに生じる摩擦を評価する
拡張性:ツールがボトルネックにならずに、アプリケーションの規模やデプロイ頻度に対応できることを確認する
すべてのアプリケーションセキュリティのニーズに対応できる単一のテスト手法はありません。包括的に脆弱性を検知するには、相互補完的なアプローチを組み合わせ、それぞれの強みでほかの手法の弱点を補う必要があります。シームレスに統合し、セキュリティテストのライフサイクル全体で検出結果を共有し、アプリケーションセキュリティ戦略の継続的な改善を可能にするツールに投資しましょう。
SnykでAI駆動型・AIネイティブアプリケーションをセキュアに
最新のアプリケーションセキュリティは、SAST、DAST、IAST、実行時保護を組み合わせるだけではありません。ソフトウェアがAI駆動型になり、エージェント型の仕組みが広がるにつれ、セキュリティは個別のチェックポイントではなく、継続的に機能する必要があります。
Snykは、SDLC全体に信頼を組み込む統合型のコードファーストプラットフォームを通じて、AI Security Fabricを提供します。最初のコミットから実行時まで、独自のコード、オープンソースの依存関係、コンテナ、インフラを保護し、セキュリティシグナルへの信頼を取り戻すとともに、バックログになる前にノイズを減らします。
チームがAIコーディングアシスタントを導入する中、Snykは開発ワークフローにガードレールを直接組み込むSecure at Inceptionを実現し、リスクが本番環境に到達する前に防ぎます。
AIネイティブアプリケーションには、Evo by Snykがさらに広範な保護を提供します。Evoは、AIコンポーネントを検出し、進化する脅威をモデル化し、攻撃者視点のテストを実行し、ポリシーを適用して、検出結果を修正につなげるエージェント型セキュリティオーケストレーションシステムです。これらすべてを統合されたエクスペリエンスで実現します。その結果、継続的な可視性、実効性のあるガバナンス、AIのスピードに対応するセキュリティが得られます。
SAST、DAST、AIセキュリティを統合するGorilla Guideを入手して、AI駆動型開発に向けたアプリケーションセキュリティの最新化について学びましょう。ガイドをダウンロードして、テスト、防止、オーケストレーションを1つのプラットフォームで統合する方法をご覧ください。
eBook
AI時代におけるSASTとDASTの統合に関するGorilla Guide®
AIを活用したSASTとDASTを組み合わせ、アプリケーションセキュリティテストを統合的に行う必要性について解説します。