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

TL;DR

• Dynamic Application Security Testing (DAST) evaluates running applications to uncover vulnerabilities that only appear at runtime. A typical DAST process involves scoping the app, configuring authentication, crawling APIs, running attack payloads, verifying findings, and exporting actionable reports into Continuous Integration and Continuous Delivery (CI/CD) pipelines.
• Traditional scanners often overwhelm teams with low-value alerts, making it hard to focus on what really matters. Platforms now use contextual intelligence to highlight only exploitable and business-impactful risks, cutting through the noise and improving developer velocity.
• Powered by VibeSec™, OX Security unifies DAST, SAST, Software Composition Analysis (SCA), and Infrastructure as Code (IaC) scanning into comprehensive application security testing tools within one Active ASPM platform. This allows enterprises to view and eliminate risks across the entire software supply chain, from code to runtime.
• This guide focuses on the 5 best DAST tools for enterprise security in 2026 OX Security, Burp Suite Enterprise Edition, OWASP ZAP, StackHawk, and Acunetix, focusing on scalability, open-source flexibility, API-first development, and compliance-ready reporting.
• Gatekeeper security is obsolete. In AI-driven development, security must live inside the workflow, acting autonomously and enforcing policies before vulnerabilities even exist.

DAST estimates a running application by sending test inputs and noticing 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 highlights 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, Active ASPM platforms like OX use autonomous prevention to stop 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, VibeSec™ reuses this authentication context to ensure policies are enforced on protected endpoints automatically.

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 API highlight. 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 also run scans locally with the OX CLI to test their code, dependencies, or IaC files before committing changes, providing fast feedback without waiting for the CI pipeline.

# Ensure OX CLI is installed and configured
ox-cli config set api-key $OX_API_KEY

# Scan the current repository (or a specific directory) for high/critical issues
ox-cli scan ./my-project --severity Critical,High --format json

# Optionally filter for changed files only
ox-cli scan --severity Critical,High --format json --git-remote-name origin

This finds open-source code, secrets, IaC, and dependency issues.

CI/CD Integration Example: GitLab CI

Here’s a sample .gitlab-ci.yml snippet using OX Security in a GitLab CI/CD pipeline:

This job turns OX into a security gate inside CI/CD. It ensures that insecure code never makes it past the pipeline stage into production. For enterprises, that means automated enforcement of AppSec policies and fewer high-risk deployments.

stages:
  - test

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

• This job uses the OX image for “block mode” scanning to enforce a policy.
• If blocking issues are found, it can fail the pipeline (based on configuration).

Docker Image Scanning Example

When you build container images during CI, you can also scan them with OX before pushing to a registry:

image_scan:
  stage: scan
  image: oxsecurity/ox-image-scanner:latest
  variables:
    OX_API_KEY: $OX_API_KEY
    OX_ARTIFACT_NAME: my-app-container
    OX_ARTIFACT_TAG: latest
    DOCKER_HOST: unix:///var/run/docker.sock
  script:
    - scan-image

• This uses OX’s Docker image scanner.
• It assumes that your CI runner can access the Docker daemon (mounting the socket or otherwise) to inspect the built image.

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 an Active ASPM platform built for the AI-driven era of development. It defines a new security model, one that prevents rather than reacts. Gatekeeper security is obsolete. OX replaces it with VibeSec™, its autonomous AI security agent that lives inside IDEs, pipelines, and runtime environments, enforcing rules and fixing vulnerabilities in real time. Instead of isolated scanning, OX all the time streams live security context into developer tools, ensuring vulnerabilities are prevented, prioritized, and remediated before production.

Key Features

• VibeSec™: Security Inside the Flow: Traditional tools react after deployment. VibeSec™ works inside your workflow, proactively blocking vulnerabilities while enforcing organizational security policies, your rules, agentically enforced.
• Secure From Code to Runtime: OX protects the full lifecycle:
  • Code: Finds and prevents flaws as developers write them.
  • APIs and Cloud: all the time models threats across your cloud-native stack.
  • Runtime: Keeps defenses aligned with how the app actually behaves in production.
• AI-Driven Prioritization: Most tools swamp teams with irrelevant alerts. OX uses contextual AI to decide which risks are exploitable and business-critical, so engineers focus on the five percent of issues that matter instead of wasting cycles on noise.
• Policy Enforcement and Automation: Security policies can be enforced automatically, OX can block risky builds, open tickets, or trigger alerts when critical issues appear. No-code workflows let teams embed guardrails without slowing releases.
• Deep CI/CD Integrations: With native connectors for GitHub Actions, GitLab CI, Jenkins, Azure DevOps, and more than 100 open-source and enterprise tools, OX plugs directly into existing workflows. Scans run per branch and per environment, giving visibility into how risk changes from development to production.
• Visibility at Enterprise Scale: Every branch is treated as its own environment. This lets teams see how vulnerabilities grow as code moves closer to release, while governance and compliance checks ensure large organizations can keep pace with AI-powered development.

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. From the left pane of the OX Security platform, select Settings > API Key Settings.
2. In the API Key Settings window, select CREATE API KEY.
3. In the Create API Key dialog, set the following:

API Key Name: Add a meaningful name that is easy to identify. It is good practice to include the key’s intended purpose in the name.

API Key Type: Select IDE Integration.

Expiration Date: Until when you can use this key.

4. Select CREATE. The key appears.

5. Copy and save the API Key Secret to be used when connecting to APIs. This is the only opportunity to view and copy the key.
6. Select CLOSE. The new key is displayed on the API Key Settings page.

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 the Marketplace, search for OX Security.

2. Select Install. The OX icon appears in the left bar, and a welcome page appears.

3. In the Welcome to OX Security page, select Open settings. The Settings tab opens on the right.

4. Add the API key that you generated in the OX Security platform. The message No issues detected yet appears on the left, and the OX icon appears on the sidebar.

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

• Prevents vulnerabilities before they exist with real-time, inline enforcement.
• Unified visibility across code, cloud, and runtime artifacts.
• Contextual AI reduces alert fatigue by up to 60 percent.
• Native automation and Active ASPM workflows streamline governance at scale.

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.

Moving Beyond Traditional DAST: Context and Unified Security with OX

Traditional DAST tools still help identify runtime issues, but they focus on detection, not prevention. OX redefines this model through its Active ASPM architecture and VibeSec™ AI agent, which enforces policies autonomously inside developer workflows.

OX’s autonomous, context-driven prevention ensures teams fix the few vulnerabilities that truly matter. Beyond prioritization, OX provides full-supply-chain visibility, combining SAST, SCA, IaC, secrets, container, and runtime data into a regularly updated PBOM and OSC&R system. 

OX addresses this challenge through context-driven prioritization. Instead of treating every vulnerability as equal, OX evaluates whether an issue is exploitable, reachable in the production environment, and likely to impact the business. This filtering ensures that teams spend time fixing the five percent of vulnerabilities that actually matter, not the ninety-five percent that never pose a realistic threat.

Equally important, OX is also CI/CD-native. It integrates directly with current engineering workflows, including GitHub Actions, GitLab, Jenkins, and Azure DevOps. With multi-branch and multi-repo scanning support, OX adapts to real development patterns, providing fast feedback loops without slowing down releases.

For enterprises, this combination of breadth and workflow alignment makes OX a natural fit. Automation, policy enforcement, and a unified dashboard give security and development teams a shared view of risk. Instead of operating as an isolated tool, OX integrates into development workflows, providing enterprises with security coverage without slowing down delivery.

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 see faster remediation, fewer false positives, and ongoing protection from code to runtime, powered by VibeSec™ ‘s AI-driven enforcement.