5 Best DAST Tools for Enterprise Security in 2026: Scaling Beyond Basic Web App Scans

DAST estimates a running application by sending test inputs and observing its behavior to reveal vulnerabilities that manifest only at runtime, such as authentication flaws, misconfigured endpoints, or input validation issues. Different from SAST, which analyzes the code before execution, DAST provides a view from the outside in, exposing attack surface gaps that external scanners often miss.

In 2026, enterprises progressively depend on applications composed of APIs, microservices, containers, and serverless components. Runtime issues in these environments, especially around authentication flows or third-party integrations, can lead to serious breaches if not caught early. Basic web app scanning alone is no longer enough.

Over 23,667 CVEs were disclosed in the first half of 2025, a 16% increase over the same period in 2024. Of those, many vulnerabilities were remotely exploitable with minimal authentication, highlighting how swiftly risk highlights grow and the urgent need for tools that can help prioritize what is truly important. 

In this blog, we’ll inspect why traditional web app scanning falls short, outline the key capabilities enterprises should expect in current DAST tools, and review the five best options for 2026, from open-source solutions to enterprise-grade platforms like OX Security.

Running a DAST Scan: Steps From Setup to Integration

DAST inspects running applications, like single-page or browser-based apps, from the outside, identifying vulnerabilities that only emerge once code executes in real environments. But while traditional tools stop at scanning, platforms like OX go beyond detection to prevent issues before they reach runtime. (for example, authentication flaws, misconfigurations, and input-validation bugs).

Step 1: Define Scope And Target Environment

Define which environment to test (usually staging or isolated test), specify hostnames, paths, and exclusions, and capture authentication needs early. Active ASPM tools use this context to model risk automatically before the scan begins.

Step 2: Configure Authentication And Session Handling

If using OAuth, tokens, or SSO, configure the scanner to authenticate properly. In OX, policy enforcement applies automatically to protected endpoints based on your configured workflows.

Step 3: Discovery (Crawling And API Import)

The scanner performs a crawl or spider to enumerate pages, endpoints, links, and parameters. For API-first apps, import OpenAPI/Swagger or GraphQL schemas so the scanner knows the full API surface. This step builds the attack highlight that the tool will test. For short scans, use a baseline crawl; for deeper assessment, use a full crawl plus AJAX or headless browser crawling.

Step 4: Active Testing (Attack Generation / Fuzzing)

The tool issues crafted payloads against discovered inputs to trigger vulnerabilities (for example, injection payloads, cross-site scripting payloads, or logic tests). Active scans attempt to verify findings rather than only flag suspicious patterns; this is often the longest phase.

Step 5: Verification And False-Positive Reduction

Enterprise-ready tools replay requests and correlate runtime signals to confirm real threats. With OX, this verification is autonomous, cutting alert fatigue by up to 60%.

Step 6: Reporting And Remediation Guidance

The scanner produces machine-readable and human-readable reports (JSON, SARIF, HTML) with: request/response pairs, location of the issue, reproducible steps, severity, and suggested fixes. Exported results should be machine consumable so CI pipelines or vulnerability management platforms can act on them.

Step 7: Integration And Orchestration (CI/CD, Issue Tracking)

Schedule scans in pipelines (for example, nightly or on release branches), upload results to tracking tools, and (optionally) feed findings into a central platform that deduplicates and prioritizes issues across SAST, SCA, and runtime signals. Many organizations centralize DAST output into an APSM platform for contextual prioritization.

Practical Example: Using OX Security in a CI Pipeline

OX Security provides tools such as the OX CLI and Docker image scanners, along with official integrations for platforms like GitHub Actions, GitLab CI, Jenkins, and Azure DevOps, so developers can embed security checks directly into their pipelines.

Local / Pre-commit Scan with OX CLI

Developers can run scans locally with the OX CLI to check their code, dependencies, or IaC files before committing changes, fast feedback without waiting for the CI pipeline.

npm install -g @oxappsec/ox-cli

# Configure with your API key
ox-cli config set api-key $OX_API_KEY

# Scan a directory for critical and high issues
ox-cli scan ./my-project --severity Critical,High --format json

# Compare local changes against a specific git remote
ox-cli scan --severity Critical,High --format json --git-remote-name origin

Note: OX CLI scans only local modifications, not the entire repository. The scanned repository must already exist in your OX organization.

CI/CD Integration Example: GitLab CI

Here’s a sample .gitlab-ci.yml snippet using OX Security in a GitLab CI/CD pipeline. This turns OX into a security gate; insecure code cannot pass the pipeline stage into production.

yamlstages:- test

ox_security_scan:
  stage: test
  image: oxsecurity/ox-block-mode:latest
  variables:
    OX_API_KEY: $OX_API_KEY
    # OX_OVERRIDE_BLOCKING: false
    # OX_TIMEOUT: 20
    # OX_FAIL_ON_TIMEOUT: false
    # OX_FAIL_ON_ERROR: false
  script:
    - ox-block-mode
  allow_failure: false

If blocking issues are found, the pipeline fails based on your configured policy, enforcing AppSec rules automatically without manual review gates.

Docker Image Scanning Example

When you build container images during CI, you can scan them with OX before pushing to a registry, catching vulnerabilities at the earliest possible stage, before the image reaches any runtime environment.

Note: Docker image scanning is currently in Early Access (EA) and is not generally available. To request access, contact OX technical support.

Prerequisites before adding this step:

• OX CI/CD integration key configured in your pipeline
• Docker image name and tag available as pipeline variables
• CI/CD environment that supports mounting the host’s Docker socket into the container

GitLab CI example:

image_scan:
  stage: scan
  image: oxsecurity/ox-image-scanner:latest
  variables:
    OX_API_KEY: <your_api_key>
    OX_ARTIFACT_NAME: <image_name>
    OX_ARTIFACT_TAG:  <image_tag>
    DOCKER_HOST: <docker_host_url or path_to_socket, defaults to unix:///var/run/docker.sock>
  script:
    - scan-image

The scanner uses the Docker socket to inspect the built image directly. If your runner accesses the Docker daemon remotely, replace the DOCKER_HOST value with your TCP address, for example, tcp://192.168.1.100:2375.

After adding the pipeline step, configure the workflow inside OX:

• Go to Pipeline Workflows in the OX platform
• Drag the Container Security policy from the left panel into your active workflow
• Define actions based on severity, alert, block the pipeline, or both
• Save the updated workflow

Key Capabilities to Look for in an Enterprise DAST Tool

1. Advanced Authentication Support

• Enterprise pain point: Many scanners stop at the login page. Large organizations often use SSO, OAuth2, or multi-step authentication flows. If a tool cannot handle these, security coverage is incomplete, and important workflows like payment processing or user management never get tested.
• What to look for: A DAST tool that records login macros, supports token injection, or integrates with identity providers to simulate real user flows.

2. API and Microservices Testing

• Enterprise pain point: Legacy scanners were built for web pages, not APIs. Generally, most enterprise attacks now target APIs or microservices. If your scanner only crawls HTML, it misses key vulnerabilities in REST, GraphQL, or gRPC endpoints.
• What to look for: Tools that import API specs (OpenAPI, GraphQL schema) and handle structured requests, so coverage extends to microservices and back-end systems, not just the front-end.

3. CI/CD and DevSecOps Integration

• Enterprise pain point: Security that lives outside the pipeline slows releases and frustrates engineers. Manual scans delay deployments, so teams often skip them. This creates a gap where applications ship untested.
• What to look for: Native integration with Jenkins, GitHub Actions, GitLab CI, or Azure DevOps. The best tools run automatically with every push or release branch, producing artifacts that developers can review without leaving their workflow.

4. Scalability and Coverage

• Enterprise pain point: A single app might be easy to test, but enterprises manage hundreds of repos and multiple environments. Running scans one-by-one does not scale. Without distributed scheduling and centralized management, teams cannot keep up.
• What to look for: Multi-branch scanning, distributed agents, scan scheduling, and compliance-focused reporting. These features ensure broad coverage across an entire app portfolio without creating bottlenecks.

5. Risk Prioritization and Reporting

• Enterprise pain point: Security teams swamped in false positives and generic “possible issue” alerts. Developers often push back because fixing every low-priority finding is unrealistic. This leads to alert fatigue and unpatched vulnerabilities.
• What to look for: Reporting that emphasizes exploitability, reachability, and business impact, so teams fix what matters most. Integration with dashboards and issue trackers ensures findings are not just reported but actually remediated.

Top 5 DAST Tools for Enterprise Security in 2026

1. OX Security
2. Burp Suite Enterprise Edition
3. OWASP ZAP (Zed Attack Proxy)
4. StackHawk
5. Acunetix (by Invicti)

From open-source projects to enterprise-grade platforms, these five DAST tools represent the most effective options for securing current applications in 2026:

1. OX Security

Overview

OX Security is a complete unified platform that secures applications from AI coding to runtime. It defines a new security model, one that prevents rather than reacts. Gatekeeper security is obsolete. OX replaces it with VibeSec™, which embeds security into AI coding assistants like Cursor and Copilot, stopping insecure code at the point of creation, before it ever reaches a pipeline. Instead of isolated scanning, OX continuously streams live security context into developer tools, ensuring vulnerabilities are prevented, prioritized, and remediated before production.

Key Features

• VibeSec: Analyzes the developer’s prompt and sends security guidance to AI coding agents such as Cursor or Claude Code before code is generated, preventing vulnerabilities at creation rather than after.
• Code-to-Runtime Coverage: OX covers the full lifecycle, detecting flaws at the code layer, identifying runtime vulnerabilities via OX Cloud, and keeping defenses aligned with how the app behaves in production.
• OX Agentic Pentester (Early Access): OX’s native DAST capability. Discovers exposed web app targets, triggers DAST scans, and reports exploitable findings in Active Issues, with each finding traced back to the exact repository and file. (Note: scans are manual-trigger-only and target only the web application. Contact OX support to request access.)
• AI-Driven Prioritization: Every finding is evaluated against reachability, exploitability, and business impact, so engineers fix what can actually be weaponized, not everything that gets flagged.
• Policy Enforcement and Automation: Policies run natively in CI/CD, blocking risky builds, opening tickets, or triggering alerts automatically without manual review gates.
• CI/CD Integrations: Native connectors for GitHub Actions, GitLab CI, Jenkins, and Azure DevOps, with scans running per branch and per environment. See the full connectors list.

Hands-on Example

Below is a step-by-step walkthrough of generating an API key, setting up the extension in your editor, and running scans to review and fix issues inline with your code.

Step 1: Before You Install The Extension, You Need To Generate An Api Key.

To Generate An Api Key:

1. In the OX Security platform, go to Settings > API Key Settings
2. Select CREATE API KEY
3. Set the following:

• API Key Name: A meaningful name that identifies its purpose
• API Key Type: Select IDE Integration
• Expiration Date: Set the validity period

4. Select CREATE, copy, and save the key immediately. This is the only opportunity to view it.

Step 2: Installing The OX IDE Extension

You can install the OX IDE Extension from your IDE marketplace.

Note: If your environment blocks marketplace access, for example, offline or restricted networks, contact OX technical support.

To install the IDE extension and run a security scan:

1. In your IDE Marketplace, search for OX Security
2. Select Install, the OX icon appears in the left sidebar

3. In the Welcome page, select Open Settings

4. Add the API key you generated, a nd the message No issues detected yet confirms the connection.

Step 3: Running A Scan And Analyzing The Results

After installing the OX IDE extension and setting it up, you can start running security scans.

When viewing scan results, you can select an issue to navigate directly to the relevant line in the code. This allows you to understand and resolve issues without leaving the OX IDE extension.

To run a scan:

• Click the triangle button at the top. The scan runs, and then the results appear, along with a direct link to the specific location in the code that contains a security risk and remediation recommendations.

Each issue in the list includes the following:

• Severity label
• Short description
• Category
• Status
• Reference to the affected code line
• Suggested fix

Your scan results will appear on the screen.

Pros

• VibeSec prevents insecure code at the point of creation, before it reaches the pipeline.
• x-cli config set api-key $OX_API_KEY
• Risky builds can be blocked automatically inside CI/CD pipelines, no manual review gates needed.
• DAST, SAST, SCA, and pipeline findings unified in one Active Issues view, one policy engine.

Cons

• Requires initial policy configuration to align with enterprise standards.
• Legacy systems may need additional onboarding for full context.

2. Burp Suite Enterprise Edition

Overview

Burp Suite is one of the most widely recognized tools in the field of application security. While the Community and Professional editions are aimed at individual testers, the Enterprise Edition extends Burp’s capabilities to automated, large-scale deployments. It is designed for organizations that need ongoing scanning of multiple web applications within CI/CD pipelines.

Key Features

• Automated Scanning: Schedule recurring scans across multiple applications without manual intervention.
• CI/CD Integrations: Plugins and API support for Jenkins, TeamCity, Azure DevOps, and other pipeline tools.
• Broad Vulnerability Coverage: Detects issues such as SQL injection, XSS, and misconfigurations with strong active and passive scanning capabilities.
• Centralized Management: Web-based dashboard for managing scans, reports, and team-wide access.

Hands-on Example

Trigger Burp Suite Enterprise scans from CI (for example, Jenkins) via its REST API to automate authenticated, scheduled scans and export actionable reports for triage.

Step 1: Install Burp Suite On Your Machine

Download the latest installer for your platform from PortSwigger’s downloads page, selecting either Professional or Community as applicable. Run the installer for your OS and follow the installer prompts.

Step 2: Launch Burp Suite And Skip Initial Project Setup

When Burp starts, it asks about project files and configuration; click Next, then Start Burp to skip project setup if you’re just getting started.

Step 3: Activate Your Professional License

If you installed Burp Suite Professional, enter your license key when prompted. If you don’t have a key yet, subscribe or request a free trial via PortSwigger.

Step 4: Verify Basic Operation By Intercepting Traffic

Burp Proxy lets you intercept HTTP requests and responses sent between Burp’s browser and the target server. This allows you to study how the website behaves when you perform different actions.

Launch Burp’s browser

Go to the Proxy > Intercept tab.

Set the intercept toggle to Intercept on.

Click Open Browser. This launches Burp’s browser, which is preconfigured to work with Burp right out of the box.

Position the windows so that you can see both Burp and Burp’s browser.

Intercept A Request

Using Burp’s browser, try to visit https://portswigger.net and observe that the site doesn’t load. Burp Proxy has intercepted the HTTP request that was issued by the browser before it could reach the server. You can see this intercepted request on the Proxy > Intercept tab.

The request is stored here so that you can review it and potentially modify it before forwarding it to the target server.

Forward The Request

Click the Forward button to send the intercepted request. Click Forward again to send any subsequent requests that are intercepted until the page loads in Burp’s browser. The Forward button sends all the selected requests.

Switch Off Interception

Due to the number of requests browsers typically send, you often won’t want to intercept every single one of them. Set the intercept toggle to Intercept off.

Return to the browser and confirm that you can now interact with the site as usual.

View The HTTP History

In Burp, go to the Proxy > HTTP history tab. Here, you can see the history of all HTTP traffic that has passed through Burp Proxy, even while the intercept was switched off.

Click on any entry in the history to view the raw HTTP request, along with the corresponding response from the server.

This lets you inspect the website as normal and study the interactions between Burp’s browser and the server afterward, which is more convenient in many cases.

Pros

• Highly trusted in the AppSec community with a long track record of vulnerability detection.
• Comprehensive scanning engine with frequent updates for new vulnerability classes.
• Enterprise dashboard simplifies the management of multiple applications and scheduled scans.

Cons

• Scans often require tuning to minimize false positives and maximize performance.
• Licensing costs can be significant for organizations with many applications.
• API-driven automation may require extra scripting compared to newer “pipeline-native” tools.

3. OWASP ZAP (Zed Attack Proxy)

Overview

OWASP ZAP is one of the most widely used open-source DAST tools. Maintained by the OWASP Foundation, it provides a comprehensive feature set for scanning web applications and APIs, supported by a large and active community. Because it is free, extensible, and frequently updated with community plugins, ZAP is often the first choice for teams beginning with automated dynamic testing.

Key Features

• API Scanning Add-ons: REST and GraphQL testing via schema imports and dedicated plugins.
• Automation Hooks: Baseline and full scan modes designed for CI/CD integration.
• Scripting Support: Extendable with Python, Groovy, or JavaScript scripts for custom payloads and reporting.
• Dockerized Distribution: Official Docker images make it simple to run scans inside pipelines or isolated environments.

Hands-on Example

Automate ZAP baseline or full scans using the official owasp/zap2docker-stable image in CI (Docker/Jenkins/GitHub Actions)

Step 1: Install Zap

The first step is to install ZAP on the system you intend to perform penetration testing on. Download the appropriate installer from the Download page.

Once the installation is complete, launch ZAP and read the license terms. Click ‘Agree’ if you accept the terms, and ZAP will finish installing. Then, ZAP will automatically start.

Step 2: Persisting a Session

When you first start ZAP, you will be prompted to save the ZAP session. By default, ZAP sessions are always recorded to disk in an HSQLDB database with a default name and location. If you do not persist the session, those files are deleted when you exit ZAP.

If you choose to persist a session, the session information will be saved in the local database, allowing you to access it later. Additionally, you will be able to provide custom names and locations for saving files.

For now, select No, I do not want to persist this session at this moment in time, then click Start. The ZAP sessions will not be persisted for now.

Step 3: ZAP Desktop UI 

The ZAP Desktop UI is composed of the following elements:

1. Menu Bar: Provides access to a range of automated and manual tools.
2. Toolbar: Includes buttons that provide easy access to the most commonly used features.
3. Tree Window: Displays the Sites tree and the Scripts tree.
4. Workspace Window: Displays requests, responses, and scripts and allows you to edit them.
5. Information Window: Displays details of the automated and manual tools.
6. Footer: Displays a summary of the alerts found and the status of the main automated tools.

Step 4: Running an Automated Scan

The easiest way to start using ZAP is via the Quick Start tab. Quick Start is a ZAP add-on that is included automatically when you install ZAP.

To run a Quick Start Automated Scan :

1. Start ZAP and click the Quick Start tab of the Workspace Window.
2. Click the large Automated Scan button.
3. In the URL to attack the text box, enter the full URL of the web application you want to attack.
4. Click the Attack

ZAP will proceed to crawl the web application with its spider and passively scan each page it finds. Then ZAP will use the active scanner to attack all of the discovered pages, functionality, and parameters.

Step 5: Interpret Your Test Results

As ZAP spiders your web application, it constructs a map of your web application’s pages and the resources used to render those pages. Then it records the requests and responses sent to each page and creates alerts if there is something potentially wrong with a request or response.

Step 6: See Explored Pages

To inspect a tree view of the explored pages, click the Sites tab in the Tree Window. You can expand the nodes to see the individual URLs accessed.

Step 7: View Alerts and Alert Details

The left-hand side of the Footer contains a count of the Alerts found during your test, broken out into risk categories. These risk categories are:

To view the alerts created during your test:

1. Click the Alerts tab in the Information Window.
2. Click each alert displayed in that window to display the URL and the vulnerability detected on the right side of the Information Window.
3. In the Workspace Windows, click the Response tab to see the contents of the header and body of the response. The part of the response that generated the alert will be highlighted.

Pros

• Free and open-source, with no licensing costs.
• Extensible via community plugins, scripts, and automation features.
• Widely adopted, with extensive documentation and active community support.
  

Cons

• Requires expertise and tuning to scale effectively in enterprise environments.
• Performance and coverage may not match commercial enterprise-grade scanners.
• Reporting features are limited compared to paid solutions.

4. StackHawk

Overview

StackHawk is a developer-first DAST tool purpose-built for current engineering teams. Different from traditional scanners that target legacy web applications, StackHawk emphasizes APIs, microservices, and cloud-native environments. It is optimized run smoothly within CI/CD pipelines, providing developers with fast, actionable feedback during the build process.

Key Features

• CI/CD Integrations: Native support for GitHub Actions, GitLab CI, Jenkins, and other pipelines.
• Automated Scans: Quick runtime testing with automated baseline and targeted scans.
• YAML-Based Configuration: Simple configuration files define targets, authentication, and scan settings, making it easy to version control security tests.
• API Testing: Strong focus on REST, GraphQL, and microservices endpoints.
  

Hands-on Example of Using Hawk to Scan Your Pipeline

Invoke Hawk scans in your pipeline (GitHub Actions/GitLab CI) with the stackhawk action/CLI and a stackhawk.yml config to run fast API/microservice scans and publish scan results.

Step 1: Install HawkScan

Step 2: Verify Installation and Initialize the Scanner

To verify the StackHawk CLI is installed, check your terminal for the hawk command version:

$ hawk version
v4.6.0

Once you’ve installed the StackHawk CLI, the next step is to initialize it with your StackHawk API Key.

During account creation, an API key was generated for you. If you need to generate a new key, navigate to Settings > API Keys.

$ hawk init

Please enter a StackHawk API key: hawk.xXXxxXXXXxXX.xXXxxXXXXxXX

Authenticated!

Step 3: Configure Your Application

First, you’ll need to provide an existing StackHawk Application ID or create a new one. You can do this from the StackHawk platform, or simply create a new Application from the StackHawk CLI using the following command:

$ hawk create app
Application Name: <your app name>

KaaKaww! Here is your new application ID:
XXxxXXXX-xXXX-xxXX-XXxX-xXXxxXXXXxXX

Before moving on, you’ll need to provide a stackhawk.yml configuration file, which tells the scanner what type of app you have, where it is located, and how to best scan it. A basic configuration file should look something like this:

app:
  # ID of an Application in your StackHawk account
  applicationId: XXxxXXXX-xXXX-xxXX-XXxX-xXXxxXXXXxXX
  # Environment name for the scan
  env: Development
  # URL to a running instance of your application
  host: https://localhost:3000

Step 4: Run a Scan

From the root folder of your project (containing the stackhawk.yml configuration file), we’re now ready to run our first scan:

$ hawk scan

Step 5: View Scan Results

Once the scan has completed, you should see results in your terminal similar to this:

StackHawk 🦅 HAWKSCAN - v4.6.0
* app id:              xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx
* env:                 Development
* scan id:             xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx
* scan configs:        ['stackhawk.yml']
* app host:            https://localhost:3000
* graphql:             False

Passive scanning complete
Active scan of https://localhost:3000 complete
Scan results for https://localhost:3000
------------------------------------------------------------
Criticality: New/Triaged
   High: 0/1    Medium: 32/0    Low: 22/0
------------------------------------------------------------

View on StackHawk platform: https://app.stackhawk.com/scans/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx

Pros

• Excellent for current stacks with APIs and microservices.
• Developer-friendly design with pipeline-native workflows.
• YAML-based configuration makes it easy to manage and version.
• Quick feedback helps developers catch vulnerabilities early.

Cons

• Less suited for legacy web applications compared to tools like Burp or Fortify.
• May require multiple runs for deep scans across complex environments.
• Smaller ecosystem and community compared to long-established tools.

5. Acunetix (by Invicti)

Overview

Acunetix, now part of Invicti Security, is a commercial DAST solution aimed at enterprises that require both automation and compliance features. It supports a broad range of web applications and APIs, and is recognized for its detailed reporting, which helps organizations comply with regulatory frameworks such as PCI DSS, HIPAA, and ISO.

Key Features

• API Testing: Scans REST, SOAP, and GraphQL APIs with schema imports.
• Authenticated Scans: Handles multi-step logins, cookies, and token-based authentication.
• Compliance Reporting: Generates detailed reports aligned with industry standards and regulatory requirements.
• Integration Options: Works with CI/CD platforms and vulnerability management tools.

Hands-on Example

Kick off Acunetix scans from CI (Azure DevOps, Jenkins) via its API or CLI to perform authenticated and API scans, generating compliance-ready reports for security teams.

Step 1. Install the Acunetix Plugin for Jenkins

1. In the Jenkins UI, click on the Manage Jenkins menu option.
2. On the Manage Jenkins page, click on the Manage Plugins option. This will open the Jenkins Plugin Manager page.
3. On the Jenkins Plugin Manager page, click on the Available tab.
4. In the Filter field, type Acunetix.
5. Click on the checkbox next to the Acunetix plugin.
6. Click on the Install without restart button.
7. When the installation is complete, click on the checkbox next to Restart Jenkins when installation is complete and no jobs are running.

Step 2. Find the Certificate Store Path

You need the certificate store path to install the Acunetix SSL certificate into the Jenkins CA store.

The default certificate store path is JAVA_HOME_FOLDER\lib\security\cacerts. You need to identify the JAVA_HOME_FOLDER for the Java binary running your Jenkins service. Keep in mind that your machine may have multiple installations of different Java versions.

To determine which Java installation is used by the Jenkins service, open the jenkins.xml file in the Jenkins installation directory and locate the executable tag. For example:

<executable>%BASE%\jre\bin\java</executable>

The %BASE% variable refers to the Jenkins installation directory. For Jenkins 2.222.4 (32-bit), the installation directory is C:\Program Files (x86)\Jenkins. Therefore, the Java executable is C:\Program Files (x86)\Jenkins\jre\bin\java.

To find the java.home directory for the Java instance running the Jenkins service, run the following command:

"C:\Program Files (x86)\Jenkins\jre\bin\java" -XshowSettings:properties -version 2>&1 | find "java.home"

The output will show you the relevant java.home directory:

java.home = C:\Program Files (x86)\Jenkins\jre

Since the certificate store file is JAVA_HOME_FOLDER\lib\security\cacerts, we now know that in this example, we need to use the certificate store file C:\Program Files (x86)\Jenkins\jre\lib\security\cacerts.

Step 3. Install the Certificate into Your Java Keystore

Run the following command from the command prompt:

keytool -import -trustcacerts -alias AcunetixCA -keystore "C:\Program Files (x86)\Jenkins\jre\lib\security\cacerts" -file C:\ProgramData\Acunetix\certs\ca.cer

Confirm that you have successfully installed the certificate on Windows:

keytool -list -keystore "C:\Program Files\Java\jre1.8.0_251\lib\security\cacerts" -alias AcunetixCA

The Result

If the certificate was successfully installed, you will see the AcunetixCA details, for example:

Enter keystore password:
AcunetixCA, 15 May 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): E6:01:86:F3:43:33:97:25:71:B9:4E:BC:D9:08:30:AC:18:75:F6:9A:E6:D0:09:1D:D0:90:DF:2A:1D:8E:97:BA

Step 4. Configure the Integration between Jenkins and Acunetix

1. In the Jenkins UI, click on the Manage Jenkins menu option.
2. On the Manage Jenkins page, click on the Configure System option. Scroll down to the bottom, to the Acunetix section.
   
   
3. Ensure that the Acunetix API URL value is correct. By default, the Acunetix API URL field is based on localhost.
   • The Acunetix CA certificate is issued for the hostname you selected during Acunetix installation. In Jenkins, you have to use the same hostname.
   • If your Jenkins runs on a different host than Acunetix, you need to make Acunetix reachable from hosts other than localhost.
   • If you are using Acunetix Online, use https://online.acunetix.com/api/v1.
4. Click on the Add button next to the Acunetix API Key field and select the Jenkins option.
   
   
5. In the Jenkins Credentials Provider dialog:
   • In the Kind field, select Secret text.
   • In the Scope field, select Global (Jenkins, nodes, items, all child items, etc).
   • Open the Acunetix user interface to retrieve the Acunetix API key:
     • Go to your Profile page (you must be the administrator), and scroll to the bottom.
     • If you don’t have an API key yet, click on the Generate New API Key button.
     • Click on the Copy button to copy the API key to the clipboard.
     • Go back to the Jenkins UI.
   • In the Secret field, paste the Acunetix API key.
   • Click on the Add button to close the Jenkins Credentials Provider dialog.
   • Click on the Apply button to save the Acunetix API key settings.
   • Click on the Test Connection button – you will see the message Connected Successfully.

Step 5. Add an Acunetix Scan as a Build Step in a Jenkins Job

To add an Acunetix scan as a build step in a Jenkins job, navigate to the configuration of an existing job or create a new job. In the Build step, select Acunetix from the Add build step drop-down.

You will see the following options:

• Scan Type: Choose a scan type for the scan. Scan types are used to reduce the scope of tests that the scanner runs during the scan.
• Scan Target: Choose a scan target that you wish to scan. Scan targets are obtained from Acunetix, with the exception of targets that require manual intervention.
• Fail build if threat level is: Choose at which scan threat level to fail the Jenkins build (High, Medium, or Low).
• Stop the scan when build fails: Select this checkbox if you would like to abort the scan when the fail condition in Fail build if threat level is met.
• Generate Report: Choose a report to generate upon completion of the scan. A download link will be provided in the job console output. You can also later access this report in Acunetix.

Pros

• Mature product with years of refinement and enterprise adoption.
• Strong compliance and reporting capabilities.
• Supports authenticated scanning and advanced API testing.
• Backed by Invicti Security, with enterprise support and regular updates.

Cons

• Licensing costs may be prohibitive for smaller teams.
• Complexity in setup and tuning compared to developer-first tools.
• Less flexible than open-source alternatives when customization is required.

Comparison Table: Which DAST Tool Fits Your Enterprise?

This table highlights the focus, strengths, and trade-offs of each DAST tool, helping enterprises quickly identify which solution best matches their environment and security goals.

How Do Security Platforms Take DAST Findings Beyond the Runtime Alert?

Standalone DAST tools are good at finding exploitable risks in running applications. The gap they leave is context; a runtime alert tells you what is vulnerable, but not where in the codebase it came from or which team owns the fix. For large engineering orgs managing hundreds of repositories, that gap turns every DAST finding into a manual investigation before remediation can even start.

Security platforms address this by treating DAST as one signal among many rather than a standalone scan. When dynamic findings surface alongside SAST, SCA, and pipeline signals in a single policy engine like OX Code, teams can correlate a runtime vulnerability to the code that introduced it without switching tools or manually tracing the path.

OX takes this further through the Agentic Pentester (currently in Early Access). It simulates an autonomous penetration test against configured web application targets, triggers DAST scans, and reports exploitable findings directly in Active Issues. OX connects the running target to the source code behind it, discovering exposed endpoints from the application and building an API BOM from connected repositories, then matching the two so findings arrive with source context attached rather than as isolated alerts. Findings are evaluated against reachability, exploitability, and business impact before surfacing, so teams are directed to vulnerabilities that can actually be acted on.

The trade-off is setup complexity. This level of context requires platform onboarding, policy configuration, and connected repositories — overhead that a standalone scanner doesn’t. Teams that need automated DAST running in CI/CD pipelines today will move faster with a dedicated tool. Teams that need runtime findings connected to code and unified across the SDLC will find the setup investment worthwhile.

Conclusion

DAST remains an important layer of enterprise security, but it is not enough to simply pick the most popular tool. Each enterprise has unique requirements, ranging from regulatory compliance to API-heavy architectures, that influence which tool will give the most value.

There is no single “best” DAST tool for every organization. Open-source options, such as OWASP ZAP, are excellent entry points. Developer-first tools, like StackHawk, integrate well into current pipelines. Meanwhile, enterprise platforms like OX Security or Acunetix provide scalability and governance. Ultimately, the right choice depends on your architecture, developer workflows, and compliance priorities.

The most effective strategy blends both open-source and enterprise solutions, while layering contextual prioritization on top. Enterprises adopting OX get runtime findings connected to source code, dynamic testing through the Agentic Pentester, and unified visibility from AI coding through cloud, across OX VibeSec, OX Code, OX Cloud, and OX Agentic Pentester working as a single platform.