DASTとは？初心者にもわかりやすく仕組み・導入手順を徹底解説！

DASTを導入したい。でもSASTやIAST、ペンテストとの違いが曖昧で、ツール選びや認証付きフローの到達率、誤検知だらけのレポートに悩んでいませんか。

この記事は、DASTの基本から動作原理、選定基準、CI/CD連携、実運用のベストプラクティスまでを一気通貫で解説します。

DASTの基本と定義

1-1. DASTとは何か：概要と目的

動的アプリケーションセキュリティテスト（DAST）は、実行中のアプリケーションに対して外部から疑似攻撃を行い、脆弱性を洗い出すテスト手法です。

つまり、ユーザーや攻撃者と同じ視点でアプリを操作し、入力と応答の振る舞いを観察してリスクを見つけます。

コードを直接読むのではなく挙動を検証するため、「ブラックボックステスト」と呼ばれることもあります。

• 目的
  • 本番に近い環境での実行時リスクを早期に可視化する
  • 実際に悪用可能な脆弱性（再現性のある問題）を優先度高く特定する
  • セキュリティを開発プロセス（DevSecOps）に組み込み、継続的に改善する
• DASTで見つけやすいものの例
  入力検証不備（XSS、SQLインジェクション）、認証・セッション管理の弱点、アクセス制御ミス、設定不備、エラーハンドリングの欠陥など。
• DASTだけでは見えにくいもの
  デッドコード、ハードコーディングされた秘密情報、複雑なビジネスロジック欠陥などは、静的解析（SAST）やコードレビューと併用するのが効果的です。

1-1-1. なぜ今DASTが重要なのか

現在はリリース頻度が高く、APIやマイクロサービス、クラウド構成が複雑化しています。

だからこそ、DASTで「実際の挙動」を継続的に検証し、想定外の組み合わせから生まれる脆弱性を迅速に検出することが欠かせません。

さらに、経営層にとっても、DASTの結果は「実害につながる問題」にフォーカスされやすく、対策の優先順位づけに役立ちます。

1-1-2. DASTとSASTの位置づけ（短い比較）

• SAST：コードを解析し、早期に広範な潜在欠陥を検出。
• DAST：動作中のアプリを検査し、悪用可能性の高い実行時リスクを把握。
  したがって、両者を組み合わせると、設計段階から運用段階までの抜け漏れを減らせます。

---

1-2. DASTの動作原理：どのように脆弱性を検出するか

DASTは「探索（クローリング）→テスト（攻撃シミュレーション）→判定（レスポンス解析）」という流れで進みます。

なぜなら、まず到達できる画面やエンドポイントを把握しなければ、テストの射程が限定されてしまうからです。

1-2-1. クローリングとアタックサーフェスの把握

• 自動でリンクやフォーム、APIエンドポイントをたどり、アプリの地図を作る
• SPAや動的レンダリングの場合、ブラウザエンジンによるレンダリングやハイブラウザモードでDOM変化も追跡
• 認証が必要なエリアは、ログイン手順やトークン付与を設定して探索範囲を拡張

1-2-2. ペイロード注入とレスポンス解析

• 代表的な攻撃パターン（XSS用スクリプト、SQLメタ文字、ディレクトリトラバーサル文字列など）をフォームやパラメータに投入
• レスポンス本文、ヘッダ、ステータスコード、リダイレクト、DOM変化、タイミングなどを観測
• パターンマッチや挙動ベースの検知で「実害が起こり得る」反応を特定

1-2-3. 誤検知を抑える仕組み

• コンテキストに応じた確認リクエスト（再現）で確度を上げる
• 同一症状のグルーピングでノイズを整理
• 環境依存の偽陽性（例：WAFレスポンス）をルールで抑制

1-2-4. CI/CDへの組み込み（自動化のイメージ）

1. Pull Request作成
2. テスト用環境に自動デプロイ（Ephemeral環境）
3. DASTスキャン実行
4. 致命度に応じてビルドを合否判定、チケット自動発行
5. 修正後に再スキャンしてクローズ

1-2-5. 検出技法の早見表

対象リスク	代表的なテスト例	典型的なシグナル	備考
反射型XSS	スクリプト文字列を注入	レスポンス中にスクリプトが実行可能	CSPやエスケープ状況も確認
SQLインジェクション	クオートやOR条件を注入	エラー文言、タイムベース遅延、結果改変	WAFの影響を考慮
認証不備	セッション固定・期限切れをテスト	不適切な再利用、権限昇格	複数ロールで検証
予期せぬ情報露出	不正URL直打ち	デバッグページ/機密レスポンス	404/403挙動も観察

---

1-3. DASTが得意とする領域・対象

DASTは「実行時の振る舞いからリスクを見抜く」ことが強みです。

したがって、ユーザーフローやセッション、設定の組み合わせから生じる問題に特に効果を発揮します。

1-3-1. 適した対象

• Webアプリケーション（サーバーサイドレンダリング、SPAいずれも）
• REST/GraphQLなどのWeb API（スキーマやリクエスト例を与えると効果的）
• 認証・認可が関与するワークフロー（ログイン、決済、パスワードリセット等）

1-3-2. DASTが強いユースケース

• 入力検証不備の可視化：ユーザー入力に連動する欠陥を実挙動で再現
• セッション・権限の欠陥：なりすましや水平・垂直スプーフィングの検出
• セキュリティヘッダや設定ミス：CSP、HSTS、Cookie属性、ディレクトリリスティングなどの不備

1-3-3. 苦手領域と補完策

• クライアントサイドのみのロジック欠陥やソース内の秘密情報漏えいは、SAST/シークレットスキャンで補完
• 非HTTPプロトコルやネイティブアプリは対象外になりやすいので、専用テストやIASTを併用
• 大量の動的UIで到達性が低い場合は、手動探索やテストデータ準備でカバレッジを補強

1-3-4. 手法の使い分け早見表

シナリオ	DASTの適合度	併用推奨
本番に近い環境での最終確認	高い	ペンテスト（悪用シナリオの深掘り）
早期段階での構文・依存性チェック	低い	SAST/ソフトウェア成分表（SBOM）
実行中コードの行単位特定	中	IAST（実行時インスツルメンテーション）
APIの権限・ロール検証	高い	テストデータ設計・契約テスト

DASTで検出できる脆弱性と限界

2-1. 代表的な脆弱性例（XSS, SQLi, CSRF, 認証バイパスなど）

DAST（動的アプリケーションセキュリティテスト）は、実行中のアプリに外部から入力を与え、その応答を観察することで、悪用されやすい挙動を見つけます。

つまり、ユーザー操作に近いシナリオで再現性のある脆弱性を可視化できるのが強みです。

以下は、DASTで検出しやすい代表的なカテゴリです。

2-1-1. XSS（クロスサイトスクリプティング）

• 特徴：不適切なエスケープにより、入力がスクリプトとして解釈される問題。
• DASTの見どころ：入力値がそのまま画面やDOMに反映される挙動。
• 対策の方向性：適切なエンコード、CSP、テンプレートのサニタイズ。

2-1-2. SQLインジェクション（SQLi）

• 特徴：入力を通じてデータベース問い合わせが意図せず変化する問題。
• DASTの見どころ：エラーメッセージ、タイミングの異常、結果の改変。
• 対策の方向性：プリペアドステートメント、ORマッパーの安全設定、エラーハンドリング。

2-1-3. CSRF（クロスサイトリクエストフォージェリ）

• 特徴：ユーザーが意図しない状態変更リクエストが外部から誘発される問題。
• DASTの見どころ：重要操作にCSRFトークンが付与されない、Referer/Origin検証不足。
• 対策の方向性：CSRFトークン、SameSite属性、重要操作の再認証。

2-1-4. 認証・セッション管理不備

• 特徴：セッション固定、トークン失効不備、パスワードリセットの甘さなど。
• DASTの見どころ：期限切れトークンで継続利用できる、Cookie属性の欠落。
• 対策の方向性：適切な有効期限、Secure/HttpOnly/SameSite、MFAの導入。

2-1-5. アクセス制御（認可）不備

• 特徴：水平・垂直権限昇格、ID直指定で閲覧・変更できる問題。
• DASTの見どころ：別ロールでのアクセス試行時のレスポンス差分。
• 対策の方向性：サーバーサイドの一貫した認可チェック、機能単位の権限設計。

2-1-6. セキュリティヘッダ・設定不備

• 特徴：CSP/HSTS/フレーム制御などが未設定または弱い。
• DASTの見どころ：レスポンスヘッダの欠落や不適切なディレクティブ。
• 対策の方向性：標準ヘッダの適用、ベースライン設定の見直し。

2-1-7. 情報露出・エラーメッセージ

• 特徴：デバッグ情報、スタックトレース、ディレクトリリスティング。
• DASTの見どころ：特定URLで意図しない情報が返る、エラー時の詳細漏えい。
• 対策の方向性：本番の詳細ログ抑制、不要エンドポイントの閉塞。

2-1-8. ファイルアップロードや入力検証の不備

• 特徴：想定外の拡張子・サイズ・MIMEでのアップロード処理。
• DASTの見どころ：検証不足による危険な処理フローの兆候。
• 対策の方向性：厳格な検証、サンドボックス、ストレージ直結の回避。

2-1-9. 代表カテゴリの早見表（DAST視点）

脆弱性カテゴリ	DASTでの兆候（例）	予防策の方向性	注意点
XSS	反映後のDOM変化やスクリプト実行の気配	出力エンコード、CSP	SPAではDOM依存の検知が鍵
SQLi	エラー文言、タイミング差、結果改変	プレースホルダ化	WAFの影響で症状が隠れる場合
CSRF	重要操作にトークン欠如	CSRFトークン、SameSite	マルチドメイン構成に配慮
認証/セッション	期限切れでも継続、属性不足	有効期限、Cookie属性	SSO連携時の境界に注意
認可	異ロールでも閲覧可	一貫した権限チェック	業務ロジック絡みは要補完
設定不備	セキュリティヘッダ欠落	ベースライン強化	リバプロやCDN設定も確認
情報露出	デバッグページ応答	本番設定の最小化	キャッシュ経由の露出に注意

---

2-2. DASTの限界と盲点：見逃しやすい脆弱性

DASTは強力ですが、万能ではありません。

なぜなら、実行時の外形的な挙動に依存するため、到達できない画面や複雑な状態管理の裏側までは把握しづらいからです。

したがって、以下の限界を理解したうえで計画することが重要です。

2-2-1. 到達性・カバレッジの限界

• 多段ログイン、MFA、条件分岐の多いフォームでは、クローラが十分に進めないことがある。
• テストデータが不足すると、分岐やエラー経路に到達できない。

2-2-2. ビジネスロジックの欠陥

• 返金計算、割引重複、ワークフローの順序依存などは、単純なペイロード注入では見抜きにくい。
• ロール横断の越権検証は、シナリオ設計と手動の視点が必要。

2-2-3. 非同期・外部連携・アウトオブバンド

• メールリンク経由の確定処理、Webhook、外部ストレージ連携は、応答が非同期でDASTの観測外になりやすい。
• SSRFやDNSベースの検知は、専用の外部観測仕組み（OAST）を用いないと難しい。

2-2-4. タイミング依存・レースコンディション

• 同時実行による競合、順序ズレ、リトライ挙動などは、自動スキャンでは再現しづらい。

2-2-5. 環境・制御の影響

• WAFやレート制限により、症状が表に出ない、あるいは誤検知が増える場合がある。
• ステージングと本番の設定差異が、検出結果の差を生む。

2-2-6. 見逃しやすい具体例（高リスクになり得るもの）

• 高度なアクセス制御の例外条件
• 金額・在庫・ポイント計算などの業務ロジック
• 署名・暗号・リプレイ防止の実装ミス
• 非HTTP領域やクライアント専用の秘匿情報

補足：限界を前提とした運用の工夫

• スコープ設計：URLマップ、ロール、テストデータを事前に定義。
• 観測強化：外部観測（OAST）やログ連携、APMの相関で挙動を補完。
• 結果整合：WAFログと突合し、見えにくい症状を再評価。

---

2-3. 自動 vs 手動 DAST の補完関係

自動DASTは「広く・頻繁に・一貫して」回すのに最適です。

一方で、手動DASTは「文脈理解・創造的な深掘り・誤検知整理」に強みがあります。

だからこそ、両者を計画的に組み合わせると、DASTの価値は最大化します。

2-3-1. 役割分担の考え方

• 自動DAST：回帰チェック、セキュリティヘッダ、一般的な入力検証の劣化検出。
• 手動DAST：複雑なフロー、ロール横断の認可、業務ロジックの破綻、再現の難しい症状の検証。

2-3-2. CI/CDにおけるハンドオフ

1. 自動DASTをプルリクごとに軽量実行（高重大度のみゲート）。
2. デイリー／ナイトリーでフルスキャン。
3. 高重大度アラートは、手動DASTで再現性と影響を評価。
4. 誤検知は抑制ルール化し、次回以降のノイズを削減。

2-3-3. 自動と手動の適材適所（早見表）

タスク	自動DASTが向く理由	手動DASTが向く理由
セキュリティヘッダ・設定の劣化検出	一貫した機械的チェック	例外設計やCDN境界の文脈判断
一般的な入力検証（XSS/SQLi傾向）	大量エンドポイントを高速走査	画面依存やDOM特殊挙動の観察
認可・ロール検証	基本パターンの差分確認	横断シナリオや条件分岐の深掘り
業務ロジック検証	定型化が難しい	人の理解と仮説検証が必須
アウトオブバンド系	自動は限定的	外部観測の連携・手動調整が必要

2-3-4. 運用のベストプラクティス

• 重要度基準の合意：重大度スコアとSLAを事前に定義。
• テストデータ戦略：ロール別アカウント、境界値、期限切れトークンを用意。
• ナレッジ循環：手動で得た洞察を自動ルールに反映し、再発を未然に抑止。
• メトリクス：検出から修正までの平均日数、誤検知率、スキャン到達率を可視化。

他手法との比較：SAST・IAST・ペネトレーションテストとの違い

3-1. SASTとの比較：コード解析と動的解析の使い分け

DAST（動的アプリケーションセキュリティテスト）は「実行中のアプリの振る舞い」を外側から検証します。

一方、SAST（静的アプリケーションセキュリティテスト）は「ソースコード」を内側から読み解きます。

つまり、DASTはユーザー視点、SASTは開発者視点のテストです。したがって、検出できる問題の種類や導入ポイントが異なります。

違いの早見表（SAST vs DAST）

観点	SAST	DAST
主対象	ソースコード	実行中のアプリ（HTTP/API/ブラウザ）
強み	早期に広く潜在欠陥を発見、シークレットやコード規約の違反も検出	実害につながる挙動を再現性高く発見、誤検知が相対的に少ない
弱み	誤検知が増えがち、実行環境依存の問題を捉えにくい	カバレッジは到達性に依存、ビジネスロジック欠陥は苦手
最適タイミング	実装直後〜PR段階	ステージング〜本番相当、回帰・受け入れ前
典型検出例	ハードコード秘密、入力検証漏れの匂い、脆弱ライブラリの使用	XSS/SQLi、セッション/認可不備、設定ミス、情報露出

3-1-1. どちらをいつ使うべきか

• まずSASTで「作り込みのミス」を早期に潰す。なぜなら、修正コストが最小化できるからです。
• 次にDASTで「実行時の危険挙動」を確認する。つまり、ユーザーの操作経路で本当に危ないかを確かめます。
• その結果、SASTで広く、DASTで深く「悪用可能性」を評価でき、修正の優先度付けが明確になります。

3-1-2. DevSecOpsでの併用パターン

• PR作成時：SASTを自動実行（ブロッカーのみゲート）
• テスト環境展開時：軽量DASTで重要エンドポイントを素早く確認
• ナイトリー：フルDASTで回帰と設定劣化を検出
• リリース前：SAST・DASTの結果を合算し、重大度とSLAで承認判断

---

3-2. IAST や RASPとの関係

IAST（Interactive Application Security Testing）は、エージェントをアプリに組み込み、実行トラフィックを横目で見ながらコード位置やデータフローを特定します。

RASP（Runtime Application Self-Protection）は、実行時に攻撃をその場で検知・遮断する「保護」技術です。

ここで重要なのは、DASTは「外部からのテスト」、IASTは「内部からの観測」、RASPは「保護」という役割の違いです。

違いの早見表（DAST・IAST・RASP）

観点	DAST	IAST	RASP
立ち位置	外部から挙動を検証	内部から実行を観測	実行時に検知・遮断
目的	悪用可能性の発見	原因究明とコード特定	攻撃の阻止・緩和
強み	再現性あるリスクを把握	行番号やコンポーネントまで紐づく洞察	即応防御、ゼロデイ緩和
弱み	行単位の根本位置は不明なことも	エージェント導入が前提	誤遮断・性能影響の調整が必要
相性	IASTと併用で再現→原因特定が速い	DASTのトリガで観測が活きる	DASTの検出結果をルール化して活用

3-2-1. DAST×IASTの併用フロー

1. DASTでXSSや認可不備の兆候を再現
2. 同時にIASTがスタックトレースやシンク/ソースを特定
3. 修正チケットに「再現手順＋該当コード位置」を添付
4. 修正後、DASTで回帰確認し、IASTでデータフロー改善を検証

3-2-2. RASPとDASTの住み分け

• RASP：本番での「最後の砦」。だから、未知攻撃への緩衝材として有効。
• DAST：本番相当で「問題を事前に見つける」ためのテスト。
• したがって、RASPは運用防御、DASTは品質向上。両者は競合ではなく補完関係です。

---

3-3. ペネトレーションテストとの関係・使い分け

ペネトレーションテスト（ペンテスト）は、熟練のホワイトハッカーが限られた期間で「現実的な侵入シナリオ」を深掘りします。

DASTが広く自動で挙動を検査するのに対し、ペンテストは仮説駆動で巧妙な手口を試す点が特徴です。

つまり、DASTは継続的・広範囲、ペンテストは重点・深掘りという使い分けになります。

違いの早見表（DAST vs ペネトレーションテスト）

観点	DAST	ペンテスト
目的	継続的な実行時リスクの可視化	実運用想定の侵入成功可否と影響評価
実施者	ツール主体（自動）＋補助的な手動	専門家（手動中心）
範囲	広く・定型的・反復可能	狭く・深く・創造的
タイミング	リリースごと、定期運用	重要リリース前、監査・認証対応時
成果物	再現手順・エンドポイント別の指摘	シナリオ別の侵入経路・業務影響の記述

3-3-1. ペンテストが必要になる場面

• 重大機能（決済、口座連携、eKYC）の初公開前
• 規制/監査対応（SOC 2、ISO 27001 等）
• M&A・大規模改修・重要インフラ接続の直前

3-3-2. DASTで「前処理」しておく理由

• まずDASTで一般的な脆弱性や設定不備を洗い出し、早期に修正する。なぜなら、ペンテストの時間を「高度な攻撃シナリオ」に集中させられるからです。
• その結果、ペンテストの成果が濃くなり、費用対効果も上がります。

3-3-3. 併用時の実務Tips

• スコープを共有：DASTの発見事項、到達率、WAF設定を事前に開示
• データ・ロール準備：テスト用アカウントや限度額、Webhook先を用意
• ナレッジ循環：ペンテストの気づきをDASTのカスタムルールへ反映（次回の自動検出に活かす）

DASTを導入・運用する際のポイント

4-1. 導入ステップ：初期設計から運用開始まで

DAST（動的アプリケーションセキュリティテスト）は、準備八割・運用二割が成功の鍵です。

つまり、最初に「何を・どこまで・どの頻度で」検査するかを明確にしておけば、誤検知や抜け漏れを最小化できます。

4-1-1. 目的と適用範囲の定義

• 目的を数値化：例）重大度高のDAST検出ゼロで出荷、MTTRを10営業日以内
• スコープを明文化：対象URL群、API群、環境（ステージング／本番相当）
• 合格基準：ビルドを止める基準（重大度・エンドポイント・再現性）
  なぜなら、目的と範囲が曖昧だと、DASTの結果が優先順位付けできず、現場が疲弊するからです。

4-1-2. 対象資産とユーザーフローの棚卸し

• URLマップとAPIリストを更新（公開/非公開、内部ツールも含める）
• 重要フロー（ログイン、決済、パスワードリセット）を図式化
• 依存関係（CDN、WAF、外部IDプロバイダ）を整理
  この棚卸しが、DASTの到達性（カバレッジ）を左右します。

4-1-3. 認証・テストデータ設計

• ロール別アカウント（一般、管理、準管理など）を用意
• MFAやSSOの自動ログイン手順をスクリプト化
• テストデータ（在庫、残高、割引、期限切れトークン）を事前に準備
  だから、DASTが本当に危険な操作に到達できます。

4-1-4. 環境準備と安全対策

• ステージングで開始し、本番相当設定を反映
• レート制限・WAFと衝突しないウィンドウを設定
• データ破壊系操作（退会、課金確定）はスコープ外へ
  その結果、DASTが業務を妨げずに安定稼働します。

4-1-5. 初期スキャンとチューニング

• 小さなスコープで試行→誤検知の抑制ルールを作成
• クローラのヒント（スタートURL、フォームの既定値）を追加
• レポート粒度（重複グルーピング、タグ付け）を整備
  つまり、早い段階で“使えるDASTレポート”に育てます。

4-1-6. 運用SLAと責任分担

• RACIの明確化：検出確認はSec、修正はDev、リリース判断はProd
• SLA：重大度Criticalは3営業日、Highは10営業日など
• 連絡経路：アラート→チケット→担当アサイン→再検証→クローズ

導入時チェックリスト（抜粋）

• スコープと合格基準が文書化されている
• ロール別アカウント／MFA手順が自動化されている
• 破壊的操作が除外されている
• 誤検知抑制ルールが1回以上のスキャンで検証済み

---

4-2. CI／CD や DevSecOps との連携方法

DASTは“回し続けて価値が出る”検査です。

したがって、CI／CDに組み込んで、変更のたびに安全性を回帰確認できるようにします。

4-2-1. パイプラインへの組み込みパターン

• PR軽量スキャン：主要エンドポイントのみ、5〜10分程度で完了
• ナイトリーフルスキャン：到達範囲を最大化、誤検知の学習も実施
• リリース前ゲート：重大度高の未解決がゼロで通過

4-2-2. 失敗基準とゲート設計

• 基準例：Critical>0 で失敗、Highは既知例外ルールで許容
• 例外の扱い：有効期限付きの抑制（30日など）を必須化
• ロールバック方針：ビルド失敗時は修正コミット後に再スキャン

4-2-3. エフェメラル環境とシークレットの扱い

• PRごとの短命環境でDASTを実行し副作用を局所化
• テスト用シークレットは専用のボルト保管、ローテーション必須
• Webhookや外部連携はモック先に向け、安全に再現

4-2-4. チケット化と可視化

• DAST検出→自動で課題化（タグ：endpoint、role、severity）
• ダッシュボードでMTTR、誤検知率、到達率を可視化
• ステークホルダー報告：週次で傾向（増減、主要原因）を共有

4-2-5. SAST/IAST/RASPとの連携

• SASTの依存ライブラリ警告とDASTの実害を突合し、優先度を調整
• IASTを併用し、DASTの再現シナリオからコード位置を即時特定
• RASPの検知ログをDASTのペイロードと照合し、ルール最適化

---

4-3. レポートの解釈・優先順位づけ

レポートは“並べ替え”が命です。

つまり、重大度だけでなく「到達性」と「ビジネス影響」を掛け合わせて、DASTの修正順を決めます。

4-3-1. 三軸評価で並べ替える

• 重大度：Critical／High／Medium／Low
• 到達性：匿名到達／認証後到達／特権のみ
• 影響：金銭・個人情報・可用性・法令順守への影響

優先度行列（例）

重大度	到達性	影響	優先度
High以上	匿名到達	個人情報・金銭	最優先で即対応
High	認証後	業務停止・信頼低下	早期対応
Medium	認証後	限定影響	計画的対応
Low	特権のみ	低影響	次回改修で対応

4-3-2. 重複・誤検知の扱い

• 症状が同一の検出はグルーピングして1件に統合
• 再現手順が曖昧なものは「要再現」キューへ
• 誤検知は抑制ルール化し、次回以降のノイズを削減
  その結果、DASTレポートの信頼性が向上します。

4-3-3. 根本原因に紐づけて直す

• 入力検証：共通バリデータ／テンプレートエンジンで横断修正
• 認証・セッション：トークン期限、Cookie属性、再認証ポリシー
• 権限：サーバーサイドの一貫した認可チェックへ集約
  つまり、個別パッチより、共通部品の改修が効果的です。

4-3-4. SLAとエスカレーション

• 例：Criticalは3営業日、Highは10営業日、Mediumは30営業日
• 期限超過は自動でリマインド、次レベルの責任者へエスカレーション
• 重大度再評価は、緩和策（WAF、一時無効化）を考慮して都度見直し

4-3-5. メトリクスで継続改善

• MTTR（検出から修正までの平均日数）
• 誤検知率（抑制件数／総検出）
• 到達率（到達URL／公開URL）
• 再発率（同型の再出現）
  DASTの価値は“改善の速度”で測れます。

---

4-4. スケジュール設計・スキャン頻度最適化

リリース頻度、トラフィック、規制要件によって、DASTの回し方は変わります。

したがって、リスクベースで頻度とスコープを調整しましょう。

4-4-1. リスクベースで頻度を決める

• 変更が多い領域（認証、決済、公開API）は高頻度でスキャン
• 変更が少ない領域は月次〜四半期で十分
• 規制・監査前は臨時の強化スキャンを追加

4-4-2. 時間短縮のテクニック

• スコープ分割：公開サイト、管理画面、APIを別ジョブで並列
• 差分スキャン：直近変更のURLを優先
• シードURL・サイトマップ・APIスキーマ（OpenAPI）で探索を加速

4-4-3. ロール別・機能別の回し方

• 匿名、一般、管理の3ロールで個別にDASTスキャン
• 重要機能（支払い、設定変更、退会）は毎回含める
• 逆に、破壊的操作は常に除外し安全弁を確保

4-4-4. 本番影響を避ける工夫

• 夜間帯や低負荷時間にDASTを実行
• 同時接続とリクエストレートを制限
• 外部連携先はモック／サンドボックスに向ける

4-4-5. 標準的な実行カレンダー（例）

頻度	スコープ	目的
PRごと	重要エンドポイントの軽量DAST	早期回帰検知
毎日	主要フローの認証付きDAST	劣化・設定ミス検出
毎週	全体フルスキャン（匿名＋認証）	網羅性の担保
毎月	API重点スキャン（権限別）	認可の抜け漏れ確認
四半期	本番相当強化スキャン＋レポートレビュー	監査・経営報告向け

DASTツール / 製品比較・選定基準

5-1. 主な商用／オープンソースツール紹介

まず、DAST（動的アプリケーションセキュリティテスト）の主要ツールを、利用シーンごとに整理します。

目的は「自社の開発・運用フローに最も馴染むDAST」を短時間で見極めることです。

5-1-1. オープンソース系：OWASP ZAP

OWASP ZAPは、世界的に利用されているオープンソースDASTです。

学習コストが低く、拡張や自動化の情報も豊富なため、まずはZAPで仕組みを作り、必要に応じて商用に移行する組み立てがしやすい点が強みです。

5-1-2. 商用：Burp Suite（Enterprise / DAST）

Burpは手動テストで著名ですが、EnterpriseやDASTエディションでは大規模スキャンやCI/CD連携、レポーティングに最適化されています。

さらに、OAST（アウト・オブ・バンド検知）などの先進機能がスキャナに統合され、検出幅を拡げられます。

5-1-3. 商用：Invicti / Acunetix

AcunetixとInvicti（旧Netsparker）は同一グループに属し、ミッドマーケットからエンタープライズまで幅広く使われています。

使いやすいUIやCI連携、誤検知低減の工夫などが評価される一方、エディションや提供形態（SaaS/オンプレ）で選択肢が分かれます。

5-1-4. 商用：Rapid7 InsightAppSec

Rapid7のInsightAppSecは、モダンなJSフレームワークやAPIも視野に入れたDASTです。認証の自動化やスケジュール実行、脆弱性の優先順位づけなど、運用面の工夫が充実しています。

5-1-5. クラウドネイティブ／Dev向け：GitLab DAST、StackHawk、Detectify

• GitLab DAST：CI/CDに密接に統合され、APIスキャンのドキュメントや認証方法のガイドが充実。プラットフォーム内で結果管理まで完結させやすいのが利点です。
• StackHawk：開発者主導のDASTを掲げ、パイプライン実行とAPIフォーカスを強調。ドキュメントやCLIも整備されています。
• Detectify：外部攻撃面（ASM）とアプリケーションスキャンを組み合わせ、最新の研究知見を取り込むSaaS志向が特徴です。

5-1-6. クイック比較（抜粋）

ツール	提供形態の例	強みの例	向いている組織像
OWASP ZAP	OSS（自己ホスト）	学習・拡張性、コスト最小	小規模〜中規模、まずは仕組み化
Burp Suite DAST/Enterprise	SaaS/オンプレ	大規模スキャン、OAST、CI連携	中規模〜大規模、複数サイト運用
Invicti / Acunetix	SaaS/オンプレ	使いやすさ、統合、誤検知対策	中規模〜エンタープライズ
Rapid7 InsightAppSec	SaaS中心	JS/SPAやAPI対応、運用機能	セキュリティ運用を成熟させたい組織
GitLab DAST	GitLab統合	Devワークフロー直結	GitLab中心のDevSecOps
StackHawk	SaaS/コンテナ	開発者主導、API強化	API開発が活発なチーム
Detectify	SaaS	ASM×DAST、最新知見の反映	外部攻撃面の可視化を急ぐ組織

---

5-2. 選定時のチェックポイント（カバレッジ、誤検知率、統合性など）

次に、DASTの選定基準を「到達できる範囲」と「運用で回せるか」の二軸でチェックします。なぜなら、検出力が高くても運用に乗らなければ成果が出ないからです。

5-2-1. カバレッジ（到達性・対象）

• SPAやモダンJS（React/Angular）のレンダリング追跡が可能か
• 認証方式（SSO/MFA/CSRFトークン）や多ロールにどこまで対応できるか
• API（REST/GraphQL）のスキーマ連携（OpenAPI等）やシナリオ指定ができるか
• OASTや外部観測機構があるか（SSRF等の検知幅に影響）

5-2-2. 品質（誤検知率・再現性）

• 再現手順の自動生成や、同一症状のグルーピングがあるか
• 誤検知抑制ルールの柔軟性（期限付き抑止、タグ付け）
• 修正確認（再スキャン）の自動化が可能か

5-2-3. 統合性（DevSecOps適合）

• CI/CDへの組み込み例・公式ガイドの厚み（GitLab/Actions/Jenkinsなど）
• 課題管理（Jira等）や通知（Slack等）との連携
• API/CLIで設定・運用をコード化できるか（「IaC」的に管理）

5-2-4. 運用機能（スケジュール・認証の自動化）

• 認証手順の自動ログイン、トークン更新、複数ロール切替の扱いやすさ
• スケジュール実行、ダッシュボード、承認ゲートの有無

5-2-5. セキュリティ・コンプライアンス

• データ取り扱い（SaaSの場合の保護・保存期間・所在）
• 監査用レポートやOWASP Top 10等へのマッピング

5-2-6. スコアリング例（重み付けの考え方）

観点	重み（例）	質問例
カバレッジ	35	SPA/API/認証多様性に到達できるか
Dev統合	25	CI/CD・課題連携・APIで自動化できるか
品質	20	誤検知対策・再現性・レポート粒度
運用性	10	スケジュール・ロール管理・ダッシュボード
セキュリティ/法務	10	データ保護・監査レポート

---

5-3. コスト対効果・運用負荷も考慮した選び方

最後に、DASTの選定では「ツール価格」だけでなく「運用にかかる人件費」と「修正までの時間短縮効果」を合わせて評価することが重要です。つまり、TCO（総保有コスト）とROIの両面で比較します。

5-3-1. TCOの内訳（見落とされがちな要素）

• 導入準備：スコープ定義、認証シナリオ作成、テストデータ整備
• 運用：スキャン時間、誤検知の整理、再スキャンの自動化
• 連携：CI/CD・課題管理・通知の統合作業
• インフラ：自己ホストの場合はサーバー・保守、SaaSの場合はデータ取り扱い確認

5-3-2. ROIの考え方（定性的評価でも十分）

• 開発フローに自然に溶け込み、修正までの平均日数（MTTR）を縮められるか
• 重要機能の回帰で早期に検出し、後戻りコストを抑えられるか
• OASTやAPI強化などで「本来見えない脆弱性」を拾えるか（リスク低減幅）

5-3-3. 組織規模・体制別のおすすめ戦略

• 小規模〜初期導入：ZAPで自動化の型を作り、パイプライン連携を固める。その後、必要に応じて商用へ段階的に拡張。
• 中規模：Burp DAST/EnterpriseやInvicti/Acunetix、InsightAppSecなどから、CI連携や運用機能を軸に比較。
• Dev主導・API中心：GitLab DASTやStackHawk、外部攻撃面も含むならDetectifyを検討。

5-3-4. 評価手順（現場で失敗しない進め方）

1. 重要フローとAPIを含む「小さな現実的スコープ」で2〜3製品を並行PoC
2. CI/CD連携、認証自動化、誤検知率、再スキャンの容易さをメトリクス化
3. 結果をスコアリング表に落として合意形成
4. 本番相当環境での安全運用ルールを整備し、ロールアウト

導入成功事例と実践ベストプラクティス

6-1. 実際の導入事例：課題と改善点

DAST（動的アプリケーションセキュリティテスト）は、導入の“型”さえ掴めば効果が継続します。ここでは実務でよくある3パターンを、課題・打ち手・結果の流れで整理します。つまり、明日から真似できる要点に絞って解説します。

6-1-1. 事例A：ECサイトでのDAST内製化——MTTRを半減

• 課題
  • 新機能の追加が週次で発生し、目視チェックに限界。
  • 認証後フロー（カート→決済）にDASTが到達できず、検出漏れが多い。
• 取り組み
  • テスト用アカウントをロール別（匿名・一般・管理）で用意し、ログイン手順をスクリプト化。
  • 重要URL（決済、返品、ポイント）をシードとして登録し、差分スキャンをPRごとに実行。
  • DAST結果を自動チケット化し、「重大度×到達性×影響」で優先順位を自動付け。
• 結果（3か月）
  • 平均修正日数（MTTR）：14日→6日に短縮。
  • 到達率：認証後エンドポイント到達が60％→88％に向上。
  • リリース後の緊急対応件数：月3件→月1件。

6-1-2. 事例B：Fintech APIでの認可不備を再発防止——契約テストとDASTの併用

• 課題
  • APIのバージョンアップ時に水平権限昇格が散発。手動検証では拾い切れない。
• 取り組み
  • OpenAPIスキーマをDASTに連携し、認可ロール（一般・管理・外部パートナー）でのリクエスト差分を自動検査。
  • 同時に契約テスト（Contract Test）をCIに組込み、「許可されない操作」をユニットレベルで明示化。
  • 重大度High以上はゲートでブロック、例外は30日で失効する期限付き抑止に統一。
• 結果（2リリース）
  • 認可起因のバグ再発率：50％以上削減。
  • レビュー時間：人手検証の平均45分→10分へ。

6-1-3. 事例C：B2B SaaSの多テナント/SSO対応——誤検知を運用で“潰す”

• 課題
  • 多テナント構成とSSOで、DASTが意図せぬテナント越境を誤検知。
• 取り組み
  • テナントIDを固定するプリセットヘッダをDASTに付与。
  • SSO後のセッション維持をリフレッシュトークンで自動更新。
  • 誤検知は「根拠付き」テンプレートで抑止登録（理由、ログ、再現不可条件を必須）。
• 結果（初回スキャンから6週間）
  • 誤検知率：35％→12％。
  • 実質的な修正着手までの平均所要：2日→当日。

Before/After早見表（例）

指標	導入前	導入後
認証後到達率	60％	85〜90％
MTTR	14日	5〜7日
誤検知率	30％超	10〜15％
リリース後Hotfix	月3件	月1件以下

---

6-2. 運用継続のコツ：定着させるための工夫

DASTは“回し続けて価値が出る”仕組みです。

したがって、技術だけでなく運用設計とチームづくりが決め手になります。

6-2-1. 定着を阻む壁と対策（現場あるある対応表）

よくある壁	具体例	効く対策	なぜ効くか
到達できない	MFA/SSOでログイン失敗	認証スクリプト化、トークン自動更新	カバレッジが安定する
誤検知が多い	WAF応答で誤判定	抑止テンプレ+期限、WAFログ突合	ノイズ削減で集中できる
修正が滞る	どこから直すか不明	「重大度×到達性×影響」で自動ソート	優先順位が明確になる
長く回らない	スキャンが重く遅い	差分・並列・時間帯分散	デリバリーを阻害しない
ナレッジが属人化	ツール担当の負荷集中	チャンピオン制度＋手順内製化	継続可能な体制になる

6-2-2. チャンピオン制度と“内製チュートリアル”

• 各プロダクトチームから1名ずつ「DASTチャンピオン」を選出。
• 30分の“標準リプレイ手順”動画と、再現手順テンプレートを内製し、オンボーディングを短縮。
• 月次レビューで「検出トップ3と教訓」を共有し、次のルール改善に反映。
  つまり、属人化せず、誰でも同じ品質で回せる状態を作ります。

6-2-3. レポートは“開発が読める言語”に翻訳する

• レポートには必ず「再現URL・リクエスト例・期待/実際の挙動・修正の起点コード（推定）」を記載。
• 可能ならサンプルPR（CSP強化、エスケープ共通化など）を添付。
  その結果、DASTの指摘がすぐ修正タスクに変換され、MTTRが短縮します。

6-2-4. 健全なゲート設計と例外運用

• 基本方針：Criticalは常時ブロック、Highは期限付き例外で可。
• 例外には期限・担当・緩和策（WAF/Feature Flag）を必須化。
• リリース前は「未解決High以上ゼロ」を合格基準としつつ、商用影響が大きい時は緩和策併用で段階的に解消。
  したがって、スピードと安全性のバランスが取れます。

6-2-5. ダッシュボード指標テンプレート（“見える化”が継続を支える）

• 到達率（匿名/認証/管理）
• 重大度別オープン件数と推移
• MTTR・再発率・誤検知率
• スキャン時間・レート制限発生回数
• ルール改善によるノイズ削減貢献（抑止件数）
  これらを週次で可視化すると、DAST運用の健康状態が一目で分かります。