---
title: "DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説"
url: "https://www.issoh.co.jp/tech/details/15882/"
published: 2026-07-29
updated: 2026-10-12
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説

DAST（Dynamic Application Security Testing／動的アプリケーションセキュリティテスト）は、稼働しているアプリケーションに外部から擬似的な攻撃リクエストを投げ、その応答から脆弱性の有無を判定する検査手法です。ソースコードを参照しないため実装言語に依存せず、コードだけを見ていては気づけないミドルウェアの設定不備やセッション管理の穴まで検出範囲に入ります。

一方でDASTは「クローラが到達できた画面しか検査できない」という制約を抱えており、導入したのに検出率が上がらない現場は、たいてい認証設定とクロール到達率でつまずいています。この記事では検査原理と守備範囲、SASTや手動診断との役割分担、ツール選定、CI/CDへの配置、採用と見送りの判断基準を実装の解像度で整理しました。

## まとめ：DASTの守備範囲と導入判断の要点

- **DASTは動いているアプリを外側から叩く検査**。言語に依存せず、実行環境の設定不備やセッション周りの欠陥まで届きます。
- **検出範囲を決めるのはクロール到達率**。ログイン後の画面に入れていなければ、検査対象はトップページ周辺だけで終わります。
- **アクセス制御と業務ロジックの欠陥は原理的に苦手**。OWASP Top 10:2025で1位のA01は、取りこぼす前提で設計します。
- **CI/CDではPR単位で回さない**。フルスキャンは数十分から数時間かかるため、ナイトリーとリリース前に配置します。
- **見送るべき現場もある**。公開面がごく狭い、リリースが四半期に1回、検査用ステージングを用意できない——いずれかなら手動診断が優位です。

## DASTの定義と検査原理｜稼働中アプリへ擬似攻撃を投げて応答から判定する

設計の出発点は「何を入力として、何を根拠に脆弱性と判定しているか」です。ここが曖昧なままツールを選ぶと、検出漏れを性能不足と誤診して乗り換えを繰り返します。

### DASTの定義とブラックボックス検査の前提｜ソースコードを見ずに何を判定するか

DASTはブラックボックス検査に分類されます。ツールが持つ情報は対象のURLと、そこへ投げたリクエストへの応答だけ。判定の根拠は次の3種類に絞られます。

- **応答内容の変化**：ペイロードが応答HTMLに反映されればXSSの疑い、SQLエラーが返れば注入欠陥の疑いと判定する。
- **応答時間の変化**：時間遅延を伴うペイロードを投げ、応答の遅れで盲目的な注入欠陥を推定する。
- **帯域外の通信**：ツールが用意した外部サーバへアプリから通信が飛んだかを観測し、SSRFやXXEを判定する。

ここから導かれる帰結は明快で、**応答に痕跡が残らない欠陥はDASTからは見えません**。逆にTLS設定の不備やセキュリティヘッダの欠落、管理画面の露出はDASTのほうが確実に拾えます。対になる静的側の手法は[SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説](https://www.issoh.co.jp/tech/details/15880/)にまとめました。

### クロールとアクティブスキャンの2段構え｜検査範囲を決めるのは到達率

DASTツールの動作は2段階に分かれます。この構造を知らないまま導入すると、検出件数が0件だったときに原因を切り分けられません。

1. **クロール（探索）段階**：巡回してURL・パラメータ・フォームの一覧を作ります。ZAPならSpiderとAJAX Spider（JavaScript実行後のDOMを追跡）の2種類。SPAはHTMLリンクが無いため、後者を有効にしないと1画面も見つかりません。
2. **アクティブスキャン（攻撃）段階**：一覧に対しパラメータごとにペイロードを注入し、応答を判定します。所要時間は「パラメータ数 × 有効なスキャンルール数」でほぼ決まる。

押さえるべきは**検出率の8割方が段階1で決まる**点です。ルールをいくら増やしても、見つかっていない画面には1発も撃たれません。実務ではクロール結果のURL一覧をルーティング定義と突き合わせて被覆率を数字で確認し、到達していない画面は認証・JavaScript描画・POST専用画面のどれが原因かに切り分けます。それでも上がらないなら、ブラウザのプロキシをZAPに向けた手動操作やE2Eテストの通信履歴を検査対象として登録しましょう。

### 検出できる脆弱性と原理的に苦手な領域｜アクセス制御と業務ロジックの壁

| 領域                 | 検出力  | 理由                |
| ------------------ | ---- | ----------------- |
| 反射型XSS・SQLインジェクション | 高い   | 反射やエラー応答を観測できる    |
| 設定不備・情報露出          | 高い   | 応答ヘッダや列挙で確認できる    |
| 認証・セッション管理の欠陥      | 中〜高  | Cookie属性は応答から判定可能 |
| アクセス制御（権限昇格）       | 低い   | 正解を機械が知らない        |
| 業務ロジックの欠陥          | ほぼ不可 | 金額計算や承認フローは仕様依存   |

注目したいのは、2025年12月公開のOWASP Top 10:2025で1位に置かれたA01 Broken Access Controlが、この表では最も苦手な側に入る点です。複数ロールのアカウントで権限越えを突き合わせる機能はありますが、権限マトリクスを人が定義する前提であり、放り込めば判定してくれるものではありません。

## DASTとSAST・脆弱性診断の違い｜検査時点と責任範囲の分担

DASTは単独で成立する手法ではなく、他の検査と穴を埋め合う前提で設計されています。実装前の設計段階で攻撃経路を洗い出す工程は[脅威モデリングによる設計時の脅威抽出](https://www.issoh.co.jp/tech/details/16226/)が担当し、実装後の検査では拾えない権限設計の穴をここで潰します。役割分担を先に決めれば、どこまでをツールに任せるかの線が引けます。

### DASTとSASTの違い｜指摘の粒度と修正コストで役割が分かれる

| 観点       | SAST       | DAST             |
| -------- | ---------- | ---------------- |
| 検査対象     | ソースコード     | 稼働中のアプリケーション     |
| 実行環境     | 不要         | 必須（動くステージングが要る）  |
| 実施タイミング  | コーディング〜PR時 | ステージング以降〜リリース前   |
| 指摘の粒度    | ファイル名と行番号  | URLとリクエスト内容      |
| 誤検知／検出漏れ | 誤検知が多め     | 検出漏れが多め（未到達は素通り） |
| 実行時間     | 数分〜十数分     | 数十分〜数時間          |

実務上の含意は2つ。誤検知と検出漏れが逆方向に振れるため、SASTは「あるはずのない指摘」を潰す運用コストがかかり、DASTは「報告されなかった安心」を疑い続ける必要があります。加えて**修正着手までの距離**が違い、DASTの「あるAPIのidパラメータで注入が成立」という指摘からコードの該当行に至るにはルーティングを追う作業が挟まる。開発者に直接修正させたい欠陥はSAST側で先に拾い、DASTは統合後の環境固有の問題に集中させる配分が機能します。性質差は[静的解析と動的テストの違いとは｜検出できるバグ・代表ツール・使い分けを比較](https://www.issoh.co.jp/tech/details/5254/)でも扱っています。

### 手動の脆弱性診断・ペネトレーションテストとの違いと自動化できる範囲

DASTは自動化された動的検査であり、専門技術者が手を動かす診断とは目的が重なりません。線引きは「仕様理解を要するか」です。

- **DAST（自動）**：既知パターンの網羅が担当。毎晩でも回せる反復性が価値で、仕様を理解しないため金額改ざんや権限越えは対象外。
- **手動の脆弱性診断**：診断員が画面仕様を読み、業務ロジックとアクセス制御まで検証する。頻度は低いが深度が出ます。
- **ペネトレーションテスト**：脆弱性の列挙ではなく「侵入して目的を達成できるか」の検証。前提となる欠陥は潰れた状態から始めます。

この3層は代替ではなく積み上げの関係にあり、**DASTで既知パターンを先に潰すほど、手動診断の工数を業務ロジック側へ振り向けられます**。内側からデータフローを観測する[IAST](https://www.issoh.co.jp/tech/details/16210/)は、DASTが無反応だった欠陥を拾える一方でエージェント常駐の制約が重く、検討は後回しで足りるでしょう。外注判断は[脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)、使い分けは[ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](https://www.issoh.co.jp/column/details/13440/)、開発プロセスへの組み込み方は[DevSecOpsとは？DevOpsとの違い・ライフサイクル・導入判断を実装視点で解説](/tech/details/13538/)にまとめました。

## 主要DASTツールの比較軸｜ZAP・Burp・Nucleiと商用製品の選び分け

DASTツールは「何を検出できるか」より「自社の認証方式とCI環境で回り切るか」で差が出ます。画面を持たないAPIサーバはクローラが機能しないため、OpenAPI定義を読み込ませてエンドポイント一覧を与える方式に切り替えます。

### OSSのDASTツール｜ZAPとNucleiで守備範囲がどう分かれるか

| 比較軸                | ZAP                      | Nuclei             |
| ------------------ | ------------------------ | ------------------ |
| 版・ライセンス（2026年7月時点） | 2.17系・Apache 2.0         | 3.8系・MIT           |
| 得意領域               | Webアプリの網羅的な動的検査          | 既知CVE・設定露出の照合      |
| クロール機能             | Spider / AJAX Spider を内蔵 | 持たない（対象URLを与える）    |
| 検査ロジック             | 内蔵スキャンルール＋アドオン           | YAMLテンプレート（9,000超） |
| 認証済み検査             | ブラウザベース認証に対応             | ヘッダ固定など簡易な範囲       |
| 実行時間               | 長い（数十分〜数時間）              | 短い（数分規模も可能）        |

整理すると、**ZAPは「自社が書いたアプリの穴」を探す道具、Nucleiは「世に知られた穴が自社に空いていないか」を照合する道具**です。Nucleiは実行が速くPRごとの軽量ゲートに置きやすい一方、クロールを持たないのでアプリ固有のパラメータ注入検査には向きません。ZAPは2024年にCheckmarxがコアチームを迎えて「ZAP by Checkmarx」名義となった後もApache 2.0のままです。診断項目の中身は[OWASP ZAPの診断項目とは？検出できる脆弱性一覧と使い方](https://www.issoh.co.jp/tech/details/2958/)で確認できます。

### 商用DASTを選ぶ判断材料｜認証対応・検出品質・レポート出力の3点

商用製品に費用を払う価値が出るのは、次の3点でOSSが力尽きたときです。第一に**認証方式の複雑さ**で、SAML・OIDCの連鎖や多要素認証でセッションを維持できないと検査が成立しません。第二に**検出品質**——再現用のHTTPリクエストと修正指針が付くかでトリアージ工数が変わります。第三に**レポート出力**で、横断的な進捗管理や監査で提出できる形式が要るかどうか。

代表例のPortSwigger製品は、Burp Suite Enterprise Editionが2025年4月に「Burp Suite DAST」へ改称し、DockerイメージからJenkinsやGitHub ActionsなどのCIで実行できます。価格は個別見積で、手動検証用のBurp Suite Professionalは年475ドル（2026年7月時点）。位置づけは[Burp Suiteとは何か？Webアプリ脆弱性診断のプロキシツール解説](https://www.issoh.co.jp/tech/details/9699/)にまとめました。

## CI/CDへのDAST組み込み設計｜スキャン時間と実行タイミングの現実解

導入が頓挫する典型は、PRごとにフルスキャンを回そうとして待ち時間に耐えられず、無効化される流れです。実行時間の桁がSASTと違う点を踏まえた配置が要ります。

### PR時に回さない設計｜ナイトリーとリリース前でスキャンを配置する

| タイミング     | 回す検査           | 目安時間    | 失敗時の扱い     |
| --------- | -------------- | ------- | ---------- |
| PR作成時     | SAST差分スキャン・SCA | 数分      | 基準超過でマージ阻止 |
| ステージング反映後 | DAST軽量スキャン     | 10〜20分  | 通知         |
| 毎晩（ナイトリー） | DASTフルスキャン     | 数十分〜数時間 | チケット自動起票   |
| リリース前     | フルスキャン＋レビュー    | 同上＋人手   | 高リスク検出で保留  |

勘所は**DASTの結果を同期的なゲートにしない**点にあります。ナイトリーで検出したものは翌朝チケット化して開発サイクルへ乗せ、リリース保留の判断だけを人が持つ。マージを止めて即修正を求める運用は反発を招き、結局スキャンをスキップする文化が定着します。CI/CD全体の設計思想は[CI/CDとは？仕組み・パイプライン・導入すべき企業の判断基準を解説](https://www.issoh.co.jp/column/details/13002/)を参照してください。

### ZAPのAutomation Framework｜スキャン計画をYAMLでコード化する

ZAPのAutomation Frameworkは、対象URL・コンテキスト定義・認証情報・スキャンポリシー・合否閾値を1本のYAMLで宣言する仕組みです。GUI設定が個人の環境に閉じる問題を避けられ、スキャン設定をリポジトリで版管理できます。

- **env（環境）**：contexts配下に対象URLの範囲、technology指定、認証設定を書く。管理者用の削除系パスはここで除外します。
- **jobs（実行順）**：passiveScan-config → spider → spiderAjax → activeScan → report の順に列挙。SPAでなければspiderAjaxを外せます。
- **閾値とレポート**：activeScanの最大実行時間とリスク別アラート件数上限で非ゼロ終了を制御。SARIF出力にすればSASTの結果と同じ画面へ集約できます。

実行はDockerイメージまたは公式のGitHub Actionから行い、CI側ではYAMLとレポート出力先だけを渡す構成にすると、スキャン内容の変更がアプリ開発者のPRとして流れます。2.17系ではブラウザベース認証が強化され、多画面ログインやTOTPフィールドへの対応が入りました。

フルスキャンが時間内に終わらない場合は、ID違いで無限に増えるURLの正規化、静的アセットの除外、使っていない技術向けルールの無効化という順で削ります。攻撃強度を下げるのは検出力も落ちるため最後の手段で、その前に機能単位でYAMLを分けて並列に回すほうが先。順序を逆にすると「速く終わるが何も見つからないスキャン」が出来上がります。

## DAST運用でつまずく3点｜認証・検査環境・WAFの干渉と対処

ツール選定よりも、この3つの設定で成否が決まります。いずれも「スキャンは正常終了したのに検出0件」という同じ症状を出すため、切り分けの手順が要ります。

### 認証済み画面を検査する設定｜セッション維持の可否が検出率を左右する

業務アプリケーションでは、検査したい画面のほぼ全てがログイン後にあります。スキャナがログイン状態を維持できていなければ、検査対象はログイン画面とエラーページだけ。設定後は次を確認します。

- **ログアウト誘発の抑止**：ログアウトリンクを踏むとセッションが切れるため、除外パスに指定するのが最初の一手。
- **セッション切れの自動検知**：「ログイン中のみ表示される文字列」を指定し、切れたら再ログインする挙動にします。
- **被覆率の実測**：サイトツリーにログイン後の主要画面が並んでいるかを確認する。件数ではなくURL一覧で見ます。
- **アカウントロックの回避**：連続した認証失敗でロックされる実装だと途中で検査不能に陥ります。

切り分けは、スキャン後のログでHTTP 302の比率を見るのが手早い方法です。多くがログイン画面へリダイレクトされているなら、認証設定が効いていない証拠になります。

### 検査環境の用意｜本番環境へ撃たない前提とテストデータ破壊の防止策

DASTは実際に攻撃リクエストを送るため、実行環境の準備が前提条件です。本番へ向けたときの事故は、ペイロード投入による不正レコードの大量生成と削除系エンドポイント経由の実データ消失、メールやSMSの誤送信、応答劣化という形で現れます。

用意すべきは、本番と同じ構成でデータだけがテスト用のステージング環境です。外部連携はモックへ差し替え、検査前後でデータベースをスナップショットから復元する手順を整えておけば、毎晩回しても壊れません。**「検査用環境を用意できない」は、DAST導入を見送る正当な理由になります**。

### WAF・レート制限との干渉｜遮断されたスキャンは何も見ていない

検査対象の手前にWAFやCDNのセキュリティ機能が入っていると、攻撃リクエストがアプリに届く前に遮断されます。この状態のスキャンは「WAFのルールを検査しただけ」であり、アプリ自体の脆弱性は評価できていません。対処は検査対象環境でWAFを迂回する経路を用意することで、オリジンへ直接アクセスできるURLを開けるか、送信元IPを許可リストに入れます。アプリ側のレート制限も同様に、検査用IPを除外しないと大半が429で弾かれるでしょう。

ただしWAF有効時の検査に意味がないわけではありません。**アプリ直接とWAF経由の2本を回して差分を見る**ことで、WAFが実際に何を止めているかを実測できます。

## DASTを導入すべき現場と見送る現場｜受託開発での採用条件と判断基準

ここまでの制約を踏まえると、投資に見合う現場とそうでない現場ははっきり分かれます。判断は条件で切ります。

### DASTを採用する条件｜公開面の広さとリリース頻度から見る目安

次の条件を3つ以上満たすなら、導入で得られるものが運用コストを上回ります。

- **公開している画面・APIが20以上ある**：対象が広いほど、人手で全数を追う限界が早く来ます。
- **リリース頻度が月1回以上**：反復して回せることがDASTの価値そのもので、変更のたびに検査できる意味が出る。
- **ステージング環境を常時維持できる**：検査対象がいつでも立っている状態が前提条件です。
- **複数の言語・フレームワークが混在している**：SASTは言語ごとに設定が要りますが、DASTは横断的に回せます。
- **個人情報や決済情報を扱う**：検査記録を継続的に残せること自体が、監査や取引先への説明で機能する。

これらを満たす現場で年1回の手動診断だけに頼ると、残る11か月は無検査で走ることになります。

### DASTが過剰になる場面｜見送るべき3条件と典型的な失敗の型を整理

次のいずれかに該当するなら、導入は見送って別の手段へ予算を回すほうが合理的です。

1. **公開面が管理画面1つ、かつIP制限済み**：外部から到達できない資産へのスキャンは投入工数に見合いません。
2. **リリースが四半期に1回以下**：反復性が価値の源泉である以上、年4回なら手動診断のほうが深度で勝る。
3. **検査用のステージング環境を用意できない**：本番へ撃つ運用は事故が前提のため、環境整備が先です。

典型的な失敗の型は3つ。**認証設定が未完成で実質トップページだけを毎晩検査していた**型は、被覆率の実測を運用に入れていないと半年気づきません。**検出0件を安全の証明として報告した**型では、対象外の領域を報告書に明記しない限り受け手が全面的な安全確認と誤読します。**ナイトリーの失敗通知が放置され3か月スキャンが止まっていた**型を防ぐには、検査ジョブ自体の死活監視も要ります。

### 受託開発でのDAST運用｜納品前検査と契約上の責任範囲の線引き

受託開発では、DASTの位置づけを契約段階で言語化しておくと後の争点が減ります。第一に**検査範囲の明示**で、アクセス制御・業務ロジック・未到達画面は対象外である旨を検査レポートの前提条件として書き添えます。第二に**実施タイミングの合意**。ステージング完成後にフルスキャンを1回、修正後に再スキャンを1回という2回構成を見積に含めておけば、末期に検査時間を捻出できない事態を避けられます。第三に**継続検査の主体**で、顧客側のCIへ引き渡すならYAMLと認証設定をリポジトリに残し、実行手順書を添えるところまでが納品物になります。

業務ロジックやアクセス制御まで含めた深度の検査が要件に入るなら、自動スキャンとは別枠で専門の診断を組み合わせる必要があります。一創では[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)として、自動検査で押さえる範囲と手動検証が要る範囲を切り分けたうえでの実施をご提案しています。DASTの結果レポートを持ち込んで「どこまで潰せていて、どこが残っているか」を整理するところからでもご相談ください。

## よくある質問

### DASTは無料で始められますか？

始められます。ZAPはApache 2.0ライセンスで有料階層がなく、機能制限もありません（2026年7月時点で2.17系）。NucleiもMITライセンスで無償です。費用が発生するのは検査用ステージング環境の維持と、検出結果をトリアージする工数のほうになります。

### DASTを入れれば手動の脆弱性診断は不要になりますか？

なりません。DASTが検出できないアクセス制御と業務ロジックの欠陥は、OWASP Top 10:2025でA01が1位に置かれている通り実害の大きい領域です。DASTは既知パターンを継続的に潰す装置と捉え、手動診断の工数を仕様依存の検証へ振り向けてください。

### スキャンで検出0件でした。安全と判断してよいですか？

判断を急がないでください。まず被覆率として、サイトツリーにログイン後の主要画面が並んでいるか、HTTP 302が異常に多くないかを見ます。次に意図的に脆弱な検証用アプリへ同じ設定でスキャンを向け、ツールが検出できる状態かを確かめる。この2点を通過して初めて、0件という結果に意味が生まれます。

### 本番環境に対してDASTを実行してもよいですか？

推奨しません。攻撃リクエストによる実データの改変、メールやSMSの誤送信、負荷による応答劣化のリスクがあります。本番でしか再現しない構成なら、受動スキャン（通信を観測するだけのモード）に限定し、アクティブスキャンは検査用環境で回す切り分けが現実的でしょう。

### SPAやReactで作った画面でもDASTは効きますか？

効きますが設定が要ります。通常のクローラでは画面を発見できないため、JavaScript実行後のDOMを追跡するAJAX Spiderを有効にしてください。それでも被覆率が上がらない場合は、E2Eテストの通信をプロキシ経由で記録し、その履歴をスキャン対象として登録する方式に切り替えます。

## 関連記事

- [SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説](https://www.issoh.co.jp/tech/details/15880/)
- [OWASP ZAPの診断項目とは？検出できる脆弱性一覧と使い方](https://www.issoh.co.jp/tech/details/2958/)
- [Burp Suiteとは何か？Webアプリ脆弱性診断のプロキシツール解説](https://www.issoh.co.jp/tech/details/9699/)
- [DevSecOpsとは？DevOpsとの違い・ライフサイクル・導入判断を実装視点で解説](/tech/details/13538/)
- [静的解析と動的テストの違いとは｜検出できるバグ・代表ツール・使い分けを比較](https://www.issoh.co.jp/tech/details/5254/)
- [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)
- [ペネトレーションテストと脆弱性診断の違い｜目的・費用・使い分けを発注前に整理](https://www.issoh.co.jp/column/details/13440/)

---

出典: [DASTとは？SASTとの違い・ZAPでのCI/CD組み込みと導入判断を実装視点で解説](<https://www.issoh.co.jp/tech/details/15882/>)（株式会社一創）