Comparing Open-Source DAST Tools — Binding ZAP, Nuclei, Wapiti, and Nikto into a DevSecOps Pipeline

As software delivery has accelerated, “shift-left” approaches such as static analysis (SAST) and software composition analysis (SCA) have become widespread. But scanning only the static state of code makes it hard to catch vulnerabilities that depend on the running runtime environment. DAST (dynamic application security testing) sends simulated attack requests to an application from the outside while it runs (as a black box) and observes its response behavior, pinpointing runtime-specific defects that SAST cannot see.

In an earlier article on replacing Checkmarx with open source, I touched on DAST lightly as one slice of the AppSec stack. This article drills into that DAST slice on its own. The conclusion up front: open-source DAST has moved from “one tool does everything” to “divide the work among lightweight tools.” Placing the standout all-arounder ZAP at the center and treating everything else as a specialist makes selection much clearer.

Where open-source DAST stands today

Modern web systems have rapidly moved to single-page applications (SPAs) built on JavaScript frameworks like React, Vue.js, and Angular, and to API-first architectures centered on REST, GraphQL, and gRPC. This shift confronts DAST scanners with a wall: you cannot crawl URLs and parameters by static HTML parsing alone. Each OSS tool tackles this wall with a different design philosophy.

As of 2026, the current-generation OSS tools to consider first for new adoption are four: ZAP, Nuclei, Wapiti, and Nikto. All have had a release or commit within the past few months and are actively developed. Add the SQLi specialist sqlmap and the XSS specialist Dalfox, and keep the free-but-not-strictly-OSS Dastardly and StackHawk on the shortlist, and the combinations you need in practice fall into place.

The all-arounder: ZAP

ZAP (Zed Attack Proxy) is the most widely used dynamic scanner in the world. Started by Simon Bennetts in 2010 as an OWASP project, it moved to the Linux Foundation’s Software Security Project as a founding project in August 2023. That move established a full-time maintenance team, and in 2024 the core dev team joined Checkmarx, rebranding it as “ZAP by Checkmarx.” The license stays Apache-2.0, keeping community control while gaining commercial backing.

ZAP’s architecture is built on a man-in-the-middle (MITM) proxy sitting between the browser and the web server. Beyond an active scanner, it has a passive scanner that only observes traffic, and a Heads Up Display (HUD) that renders security information directly in the developer’s browser. It broadly covers the OWASP Top 10 (XSS, SQLi, CSRF, various injections, header issues) and is the only “all-in-one” that can handle REST (OpenAPI), SOAP, GraphQL, and WebSocket in a single tool.

Scan control is gradually shifting from individual scripts to the Automation Framework, which defines behavior in one YAML file, greatly improving pipeline automation. It also supports official Docker images, GitHub Actions (action-baseline, action-full-scan, action-api-scan), and SARIF output. Its strength is covering the full stack for free; its weakness is the configuration weight that comes with all those features, and the tuning burden for SPAs and complex auth flows. When in doubt, starting with ZAP is the least likely to go wrong.

Template-driven: Nuclei

Nuclei, from ProjectDiscovery, is a “template-based scanner” with a different premise from traditional crawling scanners. It loads YAML-format signatures (templates) and sends specific HTTP requests to targets in fast, parallel bursts. The community-maintained set of over 11,000 templates covers the latest CVEs, cloud misconfigurations, exposed admin panels, and more, and its response speed to emerging vulnerabilities outpaces commercial tools. Templates get added within hours of a public PoC.

Its core was originally known-vulnerability detection, but it has since implemented a “DAST mode” (-dast / fuzzing) that also handles dynamic checks for SQLi, XSS, SSRF, SSTI, CRLF, LFI, and more. It is MIT-licensed, CLI-only, and easy to slot into Docker and CI/CD. Its weakness is the lack of a built-in crawler, so for exhaustive SPA crawling the common pattern is to pair it with a crawler like ProjectDiscovery’s own Katana. It is an especially strong choice for API-centric, large-scale, continuous scanning.

Lightweight CLI: Wapiti

Wapiti is a black-box vulnerability fuzzer written in Python 3 under the GPL-2.0 license. It crawls a target site to extract parameters, forms, and cookies, then injects payloads into them. A technical hallmark is that it uses SQLite3 for session tracking and progress management, so it can accurately resume a scan interrupted midway from any point.

Its scan modules are individualized: sql (error-based SQLi), blindsql (time-based blind SQLi), xss, permanentxss (stored XSS), exec (remote command execution), file (path traversal / XXE), backup, nikto (known-file discovery), and 30-plus more, loading only the ones you need. It can also distinguish reflected from stored XSS, which matters in practice. For APIs, the standalone library wapiti_swagger interprets Swagger 2.0 / OpenAPI 3.x definitions, safely resolves recursive $ref references, and interprets data types, enums, and min/max constraints to dynamically assemble valid request bodies. It is lightweight and quick to adopt, easy to run in practice for small to mid-size teams; but its JavaScript interpretation is, per the docs, “very basic,” so it trails ZAP on complex SPAs.

Server-exposure checks: Nikto

Nikto is a Perl-based, CLI-only web server scanner that Chris Sullo has developed since 2001. Rather than fine-grained per-app parameter fuzzing, it excels at quickly (typically 2–5 minutes) sweeping a web server for known dangerous files and CGIs, outdated server software, improper configuration, and missing security headers. It checks against 8,000-plus signatures and specializes in identifying and enumerating, not exploiting.

Nikto is best positioned not as a “full web app DAST” but as a complementary tool strong at checking the exposed surface. It is not suited to diagnosing JavaScript-rich UIs or apps with complex state transitions, but it is valuable for headers, TLS, dangerous files, and Basic/NTLM auth, and useful as a front-end or complement to ZAP and Wapiti. It is noisy (many false positives), so treat it as a recon and initial-audit tool. Note that while the code is GPLv3, the DB files carry separate terms, so review the licensing from a legal standpoint before internal redistribution or derivative use.

Specialists: sqlmap and Dalfox

Once a general-purpose scanner flags a suspected vulnerability, specialists are what you use to dig in and prove it out.

sqlmap automates the detection and exploitation of SQL injection (up to full database takeover). It fully supports six SQLi techniques (boolean-based blind, time-based blind, error-based, UNION query-based, stacked queries, and out-of-band), and covers traditional RDBs like MySQL, PostgreSQL, Oracle, and SQL Server as well as cloud data warehouses like Amazon Redshift, Snowflake, and ClickHouse. Its strength is that it can go as far as file-system access, OS command execution, and privilege escalation via Metasploit integration; use it as the specialist that proves out an SQLi that ZAP and the like have flagged.

Dalfox is a Go-based, XSS-focused scanner developed by HAHWUL. Rather than just firing payloads, it verifies the response to test characters against a DOM parser and abstract syntax tree (AST), precisely determining reflection points (inside HTML, inside JavaScript strings, inside attribute values) and dynamically assembling the optimal payload. It also automates out-of-band blind-XSS verification via Interactsh and bypass tracking when a WAF is detected.

Dalfox has a REST API server mode (dalfox server), and there is an important second-order lesson here: if you turn a DAST tool into a resident API server without adequate authentication and network isolation, the tool itself can become an intrusion path. Leaving it resident on an unauthenticated, reachable port invites risks of arbitrary command execution and arbitrary file read/write via crafted requests. When automating a scanner as a service, always enable authentication and tightly scope the reachable network.

Free but not open source

Tools that are free to use but not strictly OSS are still worth keeping on the shortlist.

Dastardly is a free, lightweight DAST from PortSwigger, maker of Burp Suite; it is a reduced version of the same engine as Burp Scanner. As the vendor states, scans complete in ten minutes or less and return fast feedback on seven security issues (reflected XSS, CORS misconfiguration, vulnerable JavaScript libraries, missing Content-Type, and more). It runs from a single Docker command with no configuration, no API key, and no account, and its noise is extremely low, making it ideal for a PR gate. On the flip side its coverage is narrow at seven items, and it is not suited to authenticated scans or large apps. Deeper inspection is designed to migrate to the commercial Burp Suite.

StackHawk is a commercial SaaS that wraps the ZAP engine; it is not pure OSS but has a free tier (terms are fluid, so check the current pricing page). It treats REST, GraphQL, SOAP, and gRPC as first-class, and offers a Modern AJAX Spider that recognizes SPA frameworks, API discovery from source code, and multi-user authorization tests such as BOLA/BFLA. Its config-as-code approach, placing a stackhawk.yml in the repo, delivers a strong developer experience. ZAP is the “same engine, free” rival to weigh against it.

A cross-tool comparison of OSS DAST

Organizing the tools by technical makeup and functional fit yields the following. The ◎○△ marks indicate relative strength, not an absolute rating.

SPA and API coverage techniques

The biggest wall a DAST scanner hits on the modern web is crawling SPAs and APIs. This is where each tool’s design philosophy diverges most clearly.

Crawling SPAs

Beyond a static Traditional Spider, ZAP offers an AJAX Spider that launches a headless browser (Chromium or Firefox driven by Selenium) in the background to actually evaluate and execute JavaScript. It simulates pseudo-clicks and scrolls against DOM event handlers (onClick, onSubmit, and so on) to follow client-side routing that changes dynamically. Wapiti attempts basic static URL extraction while handling full SPAs by driving Firefox headless mode externally. Nuclei has no crawler, so as noted the standard is to pair it with Katana.

Scanning REST / GraphQL

For API scans, accurately interpreting a structured API definition schema, in place of HTML crawling, directly drives coverage. Wapiti’s wapiti_swagger is a fine example: reading a Swagger 2.0 / OpenAPI 3.x definition, it decomposes every request’s path, method, and schema, safely resolves nested $ref references (including circular ones), and interprets data types, enums, and min/max constraints to dynamically assemble valid request bodies. Feeding these to the fuzzing engine keeps requests spec-compliant and normal-looking while injecting malicious parameters at pinpoint spots. ZAP likewise takes OpenAPI, GraphQL, and SOAP definitions in its API Scan module and generates attack HTTP requests.

Maintaining authenticated state

Testing APIs and protected pages behind auth requires the ability to actively keep a login session alive and re-authenticate when it expires. ZAP achieves this through authentication-context settings and custom scripts written in JavaScript or Groovy, auto-detecting session-expiry patterns in responses (a 401 or a specific error payload) and instantly running a login macro to dynamically overwrite the token in the header. Wapiti, by contrast, provides a dedicated tool called wapiti-getcookie that sends a login POST up front to obtain a session cookie. The captured cookie is saved to a local file (cookies.json), and the main scan inherits it to hold the session for a period.

Phased integration into a DevSecOps pipeline

Because DAST actually hits an external system, it takes longer than SAST and carries a risk of destroying the environment. So when integrating it into CI/CD, you must clearly control the frequency and depth of scanning. To keep delivery speed while enforcing a security gate, the following three-tier defense model is the practical best practice.

1. Pull request (PR) phase, fast and non-intrusive: restrict to passive scanning only, or a very fast targeted-template scan. Tools: ZAP Baseline Scan (passive-only, typically under 5 minutes) or Dastardly (under 10 minutes, low noise). Suited to the early stage when you do not want false positives stopping the pipeline.
2. Staging-deploy phase, active scan limited to APIs and known CVEs: fuzzing based on the freshly deployed environment’s API schema, plus active testing narrowed to high-risk emerging signatures. Tools: ZAP API Scan and Nuclei (severity High/Critical with known-CVE tags).
3. Nightly scheduled phase, full active scan: full crawling of the target and deep fuzzing with all modules. Tools: ZAP Full Scan (including dynamic DOM transitions via the AJAX Spider) or Wapiti’s full-module scan.

Below is a standard GitHub Actions configuration that orchestrates ZAP and Nuclei.

name: Continuous Dynamic Security Testing
 
on:
  push:
    branches: [ main ]
  schedule:
    - cron: '0 2 * * *' # Nightly full scan at 2 AM daily
 
jobs:
  dynamic-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout codebase
        uses: actions/checkout@v4
 
      # Fast API fuzzing via ZAP API Scan
      - 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 # Fail the job on a critical finding
 
      # Known-threat scan limited to Critical/High severity via Nuclei
      - 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 }}
 
      # Integrate results into the GitHub Security tab
      - name: Upload security findings
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: results.sarif
          category: nuclei-results

Two points matter most in pipeline integration. First, never expose the credentials the scan uses (test-account IDs and passwords) as CI plaintext; always mask them with encrypted variables like GitHub Secrets. Second, design the test users in the target environment with least privilege rather than excessive admin rights. That is the wall that prevents secondary damage if an active scan inadvertently triggers an action like deleting all data.

Suppressing false positives

What most erodes developer trust in DAST operations is not missed vulnerabilities but a flood of noise (false positives) that cannot actually be exploited. Each tool has mechanisms to tune detection sensitivity.

In ZAP’s active scan, the old “Delay When Scanning” (inserting a delay in ms) is deprecated, and the current direction consolidates on the Network Rate Limit feature. Controlling requests per second in-process via the CLI or config arguments sharply reduces false positives in timing injections caused by connection errors (503s and timeouts) from overloading a test environment (a container, say). You can also auto-exclude items you have judged as false positives from future reports via the Automation Framework’s Alert Filter feature, keyed on signature ID (Plugin ID), URL pattern, and input parameter name. That eliminates the wasted effort of triaging the same false positive every time.

# Applying a rate limit directly as a ZAP command-line option
-z "-config ratelimit.rules.rule.requestsPerSecond=3 -config ratelimit.rules.rule.groupBy=HOST"

Nuclei has strong concurrency, but its defaults are heavy. For a resource-constrained staging environment (say, a small container with about 2 GiB RAM), set a resource budget such as -rate-limit 40 (cap at 40 requests per second), -concurrency 10 (concurrent templates), and -bulk-size 10 (concurrent target hosts) to avoid needless alerts from packet loss and stack errors.

With Wapiti, there is a challenge common to crawling scanners: the crawler clicks a “logout” link itself and abandons the authenticated session. Reliably set an exclusion pattern with the -x option (for example, http://target/logout.php), and use the --skip option to pinpoint-avoid only attacks against side-effecting parameters such as payment execution or important-data deletion. That lets you complete the scan while preserving the integrity of the app’s data.

Legacy tools to avoid adopting

Among once-standard tools are some you should not adopt anew today. They still make sense for maintaining existing assets or for research, but not as the main engine you wire into CI/CD.

• Arachni: a Ruby-based scanner, advanced in its day with HTML5/DOM/AJAX support, but the project now marks itself obsolete, has migrated to its successor Ecsypno SCNR, and its GitHub repository is archived.
• w3af: a Python-based, older-generation framework with crawl/audit/attack phases and even exploitation, but it has been effectively stalled since February 2020, has old dependencies, and cannot run parallel scans.
• Vega: a Java-based GUI scanner, but its official download page states plainly “Vega is discontinued,” and distribution has ended.
• Jaeles: a Go-based tool attractive for custom-signature operation, but its repository is archived, and the project itself warns of a safety concern: signatures can execute commands locally.

If you use these in an existing environment, planning a migration to ZAP or Nuclei is the sensible move. All of them have stopped keeping pace with new vulnerability classes, the latest frameworks, and modern authentication patterns.

A use-case-based selection flow

Organizing first choices by use case makes selection less prone to second-guessing.

flowchart TD
    A[What is the target] --> B{Is browser state or SPA important}
    B -->|Yes| C{Need diverse auth and manual verification too}
    C -->|Yes| Z[ZAP as first choice]
    C -->|No| W[Wapiti as first choice]
    B -->|No| D{Is there an API definition OpenAPI/Swagger}
    D -->|Yes| E{Want fast large-scale CI/CD operation}
    E -->|Yes| N[Nuclei as first choice]
    E -->|No| Z2[ZAP or Wapiti]
    D -->|No| F{Is the goal server exposure or dangerous-file checks}
    F -->|Yes| K[Add Nikto as a complement]
    F -->|No| Z3[Reconsider with ZAP as the baseline]

Reading this flow is simple. If you need to read the modern web’s “state,” pick ZAP; for APIs, templates, and CI, Nuclei; for a lightweight CLI, Wapiti; and complement server exposure with Nikto. In the deep-dive phase, add the specialists: sqlmap for SQLi, Dalfox for XSS. For the early stage when you just want something lightweight in CI, Dastardly fits; for API-centric work with the developer experience and budget for it, StackHawk enters the picture.

Summary

Open-source DAST is a powerful way to catch the “living,” runtime-specific vulnerabilities that static code scanning cannot reach. The all-around proxy ZAP, whose evolution Checkmarx now backs; the template-driven Nuclei, which balances overwhelming coverage with a low false-positive rate; the Python-based Wapiti, lightweight and strong at session persistence; and Nikto, which instantly checks server misconfiguration and obsolescence. Each rests on its own distinct technical foundation.

The key is not to treat any of these as a “perfect cure-all” on its own. Understand each tool’s characteristics accurately, then map them onto a multi-layer DevSecOps pipeline: fast passive scans at the PR level, API-spec-driven tests at staging, and heavy full active crawling overnight. That is the realistic road to sustainable, effective security automation. When in doubt, ZAP; for APIs and continuous operation, Nuclei; for a light loop, Wapiti; and Nikto as a complement. Hold to this baseline and you will not go far wrong.

That’s a field note, from someone who works with application security day to day, on selecting open-source DAST tools and integrating them into a DevSecOps pipeline.