DAST の OSS ツールを比較する — ZAP・Nuclei・Wapiti・Nikto を DevSecOps パイプラインに束ねる

ソフトウェア開発の高速化とともに、静的コード解析（SAST）やソフトウェア構成分析（SCA）といった「シフトレフト」のアプローチが広く普及しました。しかしコードの静的な状態をスキャンするだけでは、稼働中のランタイム環境に依存する脆弱性を捉えるのは困難です。DAST（動的アプリケーションセキュリティテスト）は、アプリケーションを稼働状態（ブラックボックス）のまま外部から擬似的な攻撃リクエストを送り、その応答挙動を観察することで、SAST では見えないランタイム固有の欠陥を特定します。

先日 Checkmarx を OSS で代替する記事では、AppSec スタックの一角として DAST に軽く触れました。この記事はその DAST 部分を単体で深掘りするものです。結論を先に言えば、OSS の DAST は「1 本で全部やる時代」から「軽量なツールを役割分担させる時代」へと移りました。総合力で群を抜く ZAP を軸に、それ以外を特化型として位置づけると選定の見通しがよくなります。

DAST OSS の現在地

近年の Web システムは、React・Vue.js・Angular といった JavaScript フレームワークによるシングルページアプリケーション（SPA）や、REST・GraphQL・gRPC を主体とする API ファーストのアーキテクチャへ急速に移行しています。この変化は DAST スキャナーに「静的な HTML パースだけでは URL やパラメータを巡回できない」という壁を突きつけます。各 OSS はこの壁に対して、それぞれ異なる設計思想で挑んでいます。

2026 年時点で新規導入の第一候補として検討すべき現役 OSS は、ZAP・Nuclei・Wapiti・Nikto の 4 本です。いずれも直近数か月以内にリリースまたはコミットがあり、開発が活発です。ここに SQLi 特化の sqlmap、XSS 特化の Dalfox という特化型を足し、さらに無料だが厳密には OSS ではない Dastardly・StackHawk を選択肢として押さえておくと、実務での組み合わせが組み立てやすくなります。

総合力の ZAP

ZAP（Zed Attack Proxy）は、世界で最も広く使われている動的スキャナーです。Simon Bennetts 氏によって 2010 年に OWASP プロジェクトとして始まり、2023 年 8 月には Linux Foundation の Software Security Project へ創設プロジェクトとして移籍しました。この移籍でフルタイムのメンテナンス体制が確立され、2024 年にはコア開発チームが Checkmarx に参画して「ZAP by Checkmarx」としてリブランディングされています。ライセンスは Apache-2.0 のまま、コミュニティによるコントロールを維持しつつ商業的なバックアップを得た形です。

ZAP のアーキテクチャは、ブラウザと Web サーバの間に位置する中間者（MITM）プロキシを基礎とします。能動的なアクティブスキャンだけでなく、通信を観察するだけの受動的なパッシブスキャン、そして開発者のブラウザ上に直接セキュリティ情報を描画する Heads Up Display（HUD）機能を備えます。XSS・SQLi・CSRF・各種インジェクション・ヘッダ不備など OWASP Top 10 を広くカバーし、REST（OpenAPI）・SOAP・GraphQL・WebSocket まで単体で扱える唯一の「万能型」です。

スキャン制御は、従来の個別スクリプトから、挙動を YAML で一元定義する Automation Framework へ段階的に移行しつつあり、パイプライン自動化の利便性が大きく高まりました。公式の Docker イメージと GitHub Actions（action-baseline・action-full-scan・action-api-scan）、SARIF 出力にも対応します。強みは無料でフルスタックをカバーすること、弱みは多機能ゆえの設定の重さと、SPA や複雑な認証フローでのチューニング負荷です。迷ったらまず ZAP から始めるのが最も失敗が少ない選択です。

テンプレート駆動の Nuclei

ProjectDiscovery が提供する Nuclei は、従来のクローリング型とは発想が異なる「テンプレートベース・スキャナー」です。YAML 形式のシグネチャ（テンプレート）をロードし、ターゲットに対して特定の HTTP リクエストを高速かつ並行して送信します。コミュニティが管理する 11,000 点超のテンプレートは、最新の CVE・クラウド設定ミス・露出した管理パネルなどを網羅し、新興脆弱性への対応スピードは商用ツールを凌駕します。公開 PoC から数時間でテンプレートが追加される速さが持ち味です。

もともとは既知脆弱性の検知が中核でしたが、近年は「DAST モード（-dast / ファジング）」を実装し、SQLi・XSS・SSRF・SSTI・CRLF・LFI などの動的検査にも対応しました。ライセンスは MIT、CLI 専用で Docker・CI/CD への組み込みが容易です。弱点はクローラーを内蔵しない点で、SPA の網羅的な巡回には同じ ProjectDiscovery の Katana などのクローラーと組み合わせる運用が一般的です。API 中心・大規模・継続運用のスキャンで特に強力な選択肢になります。

軽量 CLI の Wapiti

Wapiti は Python 3 で開発された GPL-2.0 ライセンスのブラックボックス脆弱性ファザーです。対象サイトをクローリングしてパラメータ・フォーム・クッキーを抽出し、それらにペイロードを投入します。技術的な特徴は、セッション追跡と進捗管理に SQLite3 を使う点で、途中で中断したスキャンを任意の時点から正確に再開できます。

スキャンモジュールは個別化されており、sql（エラーベース SQLi）・blindsql（時間差ブラインド SQLi）・xss・permanentxss（格納型 XSS）・exec（リモートコマンド実行）・file（パストラバーサル / XXE）・backup・nikto（既知ファイル探索）など 30 種以上から必要なものだけをロードして実行します。反射型と格納型の XSS を区別できる点も実務で効きます。API に対しては独立ライブラリ wapiti_swagger が Swagger 2.0 / OpenAPI 3.x を解釈し、$ref の再帰参照を安全に解決して仕様に沿った有効なリクエスト雛形を組み立てます。軽量で導入が速く、小規模から中規模チームの実運用に扱いやすい一方、JavaScript 解釈は公式にも「very basic」とあり、複雑な SPA では ZAP に劣ります。

サーバ露出確認の Nikto

Nikto は Chris Sullo 氏が 2001 年から開発を続ける Perl 製の CLI 専用 Web サーバスキャナーです。個別アプリの細かいパラメータファジングよりも、Web サーバ自体の既知の危険なファイルや CGI、サーバソフトの陳腐化、不適切な設定、セキュリティヘッダの欠如を高速（通常 2〜5 分）に網羅することに長けています。8,000 件超のシグネチャで検査し、脆弱性の悪用はせず識別・列挙に特化します。

Nikto は「フル Web アプリ DAST」ではなく、公開面の露出確認に強い補完ツールと位置づけるのが適切です。JavaScript リッチな UI や複雑な状態遷移を持つアプリ診断には向きませんが、ヘッダ・TLS・危険ファイル・Basic/NTLM 認証などの観点で価値が高く、ZAP や Wapiti の前段・補完として有用です。ノイズ（誤検知）は多めなので、偵察・初期監査向けと割り切ります。なお、コードは GPLv3 ですが DB ファイルには別条件が付くため、社内再配布や派生利用の際は法務観点での確認が必要です。

特化型ツール — sqlmap と Dalfox

汎用スキャナーが脆弱性の疑いを検出した後、深掘りと実証に使うのが特化型ツールです。

sqlmap は SQL インジェクションの検出と悪用（DB 乗っ取りまで）を自動化するペンテストツールです。ブールベースブラインド・時間差ブラインド・エラーベース・UNION クエリベース・スタッククエリ・Out-of-Band という 6 種の SQLi 技法を完全サポートし、MySQL・PostgreSQL・Oracle・SQL Server などの伝統的 RDB に加え、Amazon Redshift・Snowflake・ClickHouse といったクラウド DWH までカバーします。ファイルシステムアクセスや OS コマンド実行、Metasploit 連携による権限昇格まで踏み込めるのが強みで、ZAP などが検出した SQLi の疑いを実証する専門ツールとして使います。

Dalfox は HAHWUL 氏が開発した Go 製の XSS 特化スキャナーです。単なるペイロード送信に留まらず、テスト文字を送った際のレスポンスを DOM パーサーと抽象構文木（AST）に基づいて検証し、反射ポイント（HTML 内・JavaScript 文字列内・属性値内など）を精密に判定して最適なペイロードを動的に組み立てます。Interactsh と連携した Out-of-Band 型のブラインド XSS 検証や、WAF 検出時のバイパス追跡といった自動化も備えます。

Dalfox には REST API サーバモード（dalfox server）があり、ここには重要な二次の教訓があります。認証やネットワーク分離が不十分なまま DAST ツールを API サーバ化して常駐させると、ツール自体が侵入経路になり得るという点です。未認証でアクセス可能なポートに常駐させれば、細工したリクエストによる任意コマンド実行や任意ファイル読み書きのリスクが生じます。スキャナーを自動運用する際は、必ず認証を有効化し、到達可能なネットワーク範囲を絞る必要があります。

無料だが OSS ではない選択肢

無料で使えるものの、厳密には OSS ではない DAST も、選択肢として押さえておく価値があります。

Dastardly は Burp Suite を開発する PortSwigger 製の無料軽量 DAST で、Burp Scanner と同じエンジンの縮小版です。公式が掲げるとおりスキャンは 10 分以内に完了し、反射型 XSS・CORS 設定不備・脆弱な JavaScript ライブラリ・Content-Type 未指定など 7 項目について高速なフィードバックを返します。Docker 一発・設定不要・API キー不要・アカウント不要で、ノイズが極めて少ないため PR ゲートに最適です。反面カバー範囲は 7 項目と狭く、認証スキャンや大規模アプリには向きません。より深い検査は Burp Suite の商用版へ移行する設計になっています。

StackHawk は ZAP エンジンをラップした商用 SaaS で、純粋な OSS ではありませんが無料枠があります（条件は流動的なので最新の料金ページで要確認）。REST・GraphQL・SOAP・gRPC をファーストクラスで扱い、SPA フレームワークを認識する Modern AJAX Spider や、ソースコードからの API 発見、BOLA/BFLA といった多ユーザー認可テストまで提供します。stackhawk.yml をリポジトリに置くコード・アズ・コード方式で、開発者体験に優れます。ZAP が「同じエンジンで無料」の対抗馬になります。

OSS DAST の網羅比較

各ツールの技術構成と機能適合度を整理すると、以下のようになります。◎○△の記号は相対的な得意度を示すもので、絶対評価ではありません。

SPA と API への対応技術

DAST スキャナーが現代の Web で直面する最大の壁は、SPA と API の巡回です。ここは各ツールの設計思想がはっきり分かれるところです。

SPA のクローリング

ZAP は静的な Traditional Spider に加え、ヘッドレスブラウザ（Selenium が制御する Chromium または Firefox）をバックグラウンドで起動して実際に JavaScript を評価・実行する AJAX Spider を提供します。DOM 上のイベントハンドラ（onClick や onSubmit など）に対して擬似的なクリックやスクロールをシミュレートし、動的に変化するクライアント側ルーティングを追跡します。Wapiti は簡易的な静的 URL 抽出を試みつつ、本格的な SPA に対しては Firefox のヘッドレスモードを外部から駆動して対処します。Nuclei はクローラーを持たないため、前述のとおり Katana と組み合わせるのが定石です。

REST / GraphQL の走査

API スキャンでは、HTML クローリングの代わりに構造化された API 定義スキーマを正確に解釈することが網羅性に直結します。Wapiti の wapiti_swagger は優れた実装例で、Swagger 2.0 / OpenAPI 3.x の定義を読み込むと、全リクエストのパス・メソッド・スキーマを分解し、ネスト構造の $ref 参照（循環参照を含む）を安全に解決したうえで、データ型・列挙型・最小値/最大値の制約を解釈して有効なリクエストボディの雛形を動的に組み立てます。これをファジングエンジンに供給することで、仕様に合致した擬似正常リクエストを保ちつつ、ピンポイントで悪意あるパラメータを注入します。ZAP も同様に API Scan モジュールで OpenAPI・GraphQL・SOAP 定義を受け取り、攻撃用 HTTP リクエストを生成します。

認証状態の維持

認証の裏側にある API や保護ページをテストするには、ログインセッションを能動的に維持し、失効時に再認証を繰り返す能力が求められます。ZAP は認証コンテキスト設定や、JavaScript / Groovy で書いたカスタムスクリプトでこれを実現し、レスポンス内の認証切れパターン（401 や特定のエラーペイロード）を自動検知して即座にログインマクロを実行し、ヘッダ内のトークンを動的に上書きします。一方 Wapiti は、ログイン用 POST を事前に送ってセッションクッキーを取得する wapiti-getcookie という専用ツールを提供します。取得したクッキーはローカルファイル（cookies.json）に保存され、メインスキャンがそれを引き継いで一定期間セッションを維持します。

DevSecOps パイプラインへの段階的統合

DAST は外部システムを実際に叩くという特性上、SAST より時間がかかり、環境を破壊するリスクを伴います。そのため CI/CD へ組み込む際は、検査の実行頻度と深度を明確にコントロールする必要があります。開発速度を保ちつつセキュリティゲートを担保するには、以下の 3 層防衛モデルが実務的なベストプラクティスとされています。

1. プルリクエスト（PR）フェーズ、高速・非介入スキャン: パッシブスキャンのみ、または極めて高速な特定テンプレートスキャンに絞る。ツールは ZAP Baseline Scan（パッシブ解析のみ、通常 5 分以内）や Dastardly（10 分以内・低ノイズ）。誤検知でパイプラインを止めたくない初期段階に向く。
2. ステージング配備フェーズ、API / 既知 CVE 限定の能動スキャン: 新規デプロイした検証環境の API スキーマに基づくファジングと、危険度の高い新興シグネチャに絞った能動テスト。ツールは ZAP API Scan と Nuclei（重要度 High/Critical かつ既知 CVE タグ指定）。
3. 定時夜間（Nightly）フェーズ、完全アクティブスキャン: 対象への完全なクローリングと全モジュールによる深層ファジング。ツールは ZAP Full Scan（AJAX Spider による動的 DOM 遷移を含む）や Wapiti の全モジュール検査。

以下は GitHub Actions で ZAP と Nuclei をオーケストレーションする標準的な構成例です。

name: Continuous Dynamic Security Testing
 
on:
  push:
    branches: [ main ]
  schedule:
    - cron: '0 2 * * *' # 毎日午前 2 時に夜間フルスキャン
 
jobs:
  dynamic-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout codebase
        uses: actions/checkout@v4
 
      # ZAP API スキャンによる高速 API ファジング
      - name: ZAP API security scan
        uses: zaproxy/action-api-scan@v0.10.0
        with:
          target: 'https://staging.internal/api/v1/openapi.json'
          format: openapi
          token: ${{ secrets.GITHUB_TOKEN }}
          fail_action: true # 重大な脆弱性検出時にジョブを落とす
 
      # Nuclei による重要度 Critical/High 限定の既知脅威スキャン
      - name: Targeted CVE scan with Nuclei
        uses: projectdiscovery/nuclei-action@v3
        with:
          version: latest
          args: -u https://staging.internal -severity critical,high -sarif-export results.sarif
          token: ${{ secrets.GITHUB_TOKEN }}
 
      # 結果を GitHub Security タブへ統合
      - name: Upload security findings
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: results.sarif
          category: nuclei-results

パイプライン統合で順守すべき要点は 2 つあります。第一に、スキャンに使うクレデンシャル（テストアカウントの ID やパスワード）を CI のプレーンテキストとして露出させず、必ず GitHub Secrets などの暗号化変数でマスクすること。第二に、スキャン対象環境のテストユーザーには過剰な管理権限を与えず最小特権で設計することです。アクティブスキャンが意図せず全データ削除のようなアクションを踏んでしまう二次被害を、これが防ぐ壁になります。

誤検知の抑制

DAST 運用で開発者の信頼を最も損なうのは、脆弱性の見逃しではなく「実際には悪用できないノイズ（偽陽性）」の多発です。各ツールには検出感度を最適化する仕組みがあります。

ZAP のアクティブスキャンでは、以前の「Delay When Scanning（ms 単位のディレイ挿入）」は非推奨となり、現在は Network の Rate Limit 機能への一本化が進んでいます。秒間リクエスト数を CLI や設定引数でインプロセス制御することで、テスト環境（コンテナなど）の過負荷による接続エラー（503 やタイムアウト）に起因するタイミングインジェクションの誤検知を大幅に減らせます。また、偽陽性と判定した項目は Automation Framework の Alert Filter 機能で、シグネチャ ID（Plugin ID）・URL パターン・入力パラメータ名をキーに次回以降のレポートから自動的に除外できます。毎回同じ偽陽性をトリアージする無駄な工数がなくなります。

# ZAP のコマンドラインオプションとして直接レート制限を適用する例
-z "-config ratelimit.rules.rule.requestsPerSecond=3 -config ratelimit.rules.rule.groupBy=HOST"

Nuclei は並行処理性能が高い反面、デフォルト設定のままでは高負荷です。システム資源に制約のあるステージング環境（例: RAM 2 GiB 程度の小規模コンテナ）に対しては、-rate-limit 40（秒間 40 件に制限）・-concurrency 10（同時テンプレート数）・-bulk-size 10（同時スキャン対象ホスト数）といったリソースバジェットを設定して、パケットロスやスタックエラーによる不要なアラートを回避します。

Wapiti では、クローラーが「ログアウト」リンクを自らクリックして認証セッションを放棄してしまう、クローリング型に共通の課題があります。-x オプションで除外パターン（例: http://target/logout.php）を確実に設定し、さらに --skip オプションで決済実行や重要データ削除といった副作用を伴うパラメータへの攻撃だけをピンポイントで回避することで、アプリデータの整合性を保ちながらスキャンを完遂できます。

採用を避けるべきレガシー

かつて定番だったツール群の中には、いま新規採用すべきでないものがあります。既存資産の保守や研究用途なら意味はありますが、CI/CD に組み込む主力にはなりません。

• Arachni: Ruby 製で HTML5/DOM/AJAX 対応など当時は先進的でしたが、公式が obsolete と明記し、後継の Ecsypno SCNR へ移行済みで、GitHub リポジトリもアーカイブされています。
• w3af: Python 製で crawl/audit/attack の三相と悪用機能まで持つ旧世代フレームワークですが、2020 年 2 月以降は実質的に停滞し、依存関係も古く、並列スキャンもできません。
• Vega: Java 製の GUI スキャナーですが、公式ダウンロードページに「Vega is discontinued.」と明記され、配布が終了しています。
• Jaeles: 自作シグネチャ運用が魅力の Go 製ツールですが、リポジトリがアーカイブ済みで、シグネチャがローカルでコマンド実行可能という安全運用上の注意も公式が喚起しています。

これらを既存環境で使っている場合は、ZAP または Nuclei への移行を計画するのが妥当です。いずれも新しい脆弱性クラス・最新フレームワーク・現代の認証パターンへの追随が止まっています。

用途別の選定フロー

用途別に第一候補を整理すると、選定で迷いにくくなります。

flowchart TD
    A[対象は何か] --> B{ブラウザ状態や SPA が重要か}
    B -->|はい| C{多様な認証や手動検証も必要か}
    C -->|はい| Z[ZAP を第一候補]
    C -->|いいえ| W[Wapiti を第一候補]
    B -->|いいえ| D{API 定義 OpenAPI/Swagger はあるか}
    D -->|はい| E{CI/CD で高速・大規模運用したいか}
    E -->|はい| N[Nuclei を第一候補]
    E -->|いいえ| Z2[ZAP または Wapiti]
    D -->|いいえ| F{目的はサーバ露出や危険ファイル検査か}
    F -->|はい| K[Nikto を補完導入]
    F -->|いいえ| Z3[ZAP を基準に再検討]

このフローの解釈は単純です。モダン Web の「状態」を読むなら ZAP、API・テンプレート・CI なら Nuclei、軽量 CLI なら Wapiti、サーバ露出面は Nikto を併用、という切り分けです。深掘りの局面では、SQLi は sqlmap、XSS は Dalfox という特化型を足します。CI にとにかく軽く入れたい初期段階は Dastardly、API 中心で開発者体験と予算があるなら StackHawk が選択肢に入ります。

まとめ

OSS の DAST は、静的なコードスキャンでは捉えきれないランタイム固有の「生きた」脆弱性を捉える強力な手段です。Checkmarx と連携して進化を牽引する総合プロキシの ZAP、圧倒的な対応力と低誤検知率を両立するテンプレート駆動の Nuclei、軽量かつセッション永続化に優れた Python 製の Wapiti、サーバの設定不備や陳腐化を瞬時に検証する Nikto。これらはそれぞれ独自の技術基盤を持っています。

重要なのは、これらを単体で「完璧な万能薬」として捉えないことです。各ツールの特性を正確に理解したうえで、PR レベルでの高速パッシブ走査、ステージングでの API 仕様書連携テスト、夜間の重厚なフル能動クローリングという多層的な DevSecOps パイプラインへマッピングすること。これが、持続可能で実効的なセキュリティ自動化への現実的なロードマップです。迷ったら ZAP、API と継続運用なら Nuclei、軽く回すなら Wapiti、補完に Nikto。この基本線を押さえておけば、大きく外すことはありません。

以上、アプリケーションセキュリティに日々向き合う立場から、OSS の DAST ツールの選定と DevSecOps パイプラインへの統合を、現場からお送りしました。