Acunetix and StackHawk are both Dynamic Application Security Testing (DAST) tools. As DAST scanners, both tools help teams find and fix common application security vulnerabilities – like cross site scripting (XSS) and SQL Injection.
With this blog, we will dig into the similarities and differences between the two so you can better understand which is the right tool for your organization.
Acunetix vs. StackHawk Overview
Before we jump into the details of each product below, let's cover the fundamental differences in approach between Acunetix and StackHawk. The differences between the products boil down to when security tests are run, who is using the product, and the architecture of the application.
When DAST Tests are Run (Shifting AppSec Left): Acunetix was built to scan production applications. With the frequency of deployments when Acunetix launched in 2005, this was the right approach. Today, modern software teams deploy frequently and leverage automated testing in CI/CD. While Acunetix can be used to test publicly available staging sites, StackHawk is the only tool on the market truly built for automation in CI/CD. StackHawk does not require a publicly facing application, allowing teams to test earlier in CI/CD or even locally. Additionally, this allows for the testing of each underlying API and microservices independently, which improves performance and accuracy.
Who is Reviewing the Result (Developer-Centric Security): StackHawk is a developer-centric DAST product, built for developers to own the triage and fixes of scanner findings. With StackHawk, developers are alerted of any newly introduced findings and then can leverage a cURL command generator within the StackHawk platform to recreate the finding locally. With StackHawk, security teams provide strategic guidance up front and monitor risk based on activities that developers take. Acunetix takes a different approach with a product built for security teams. With Acunetix, security teams deploy the scan and review the findings themselves, ultimately adding them to an engineering backlog for prioritization.
Architecture of the Application (API Security Testing): Modern applications are built with backing APIs (typically REST or GraphQL). The DAST tool used to test these modern applications must be built to test the underlying APIs. While both tools have functionality that allows for the testing of APIs, a review of the documentation pages for each product will make it clear that StackHawk has best-in-class API testing while Acunetix has built workarounds that allow the scanner to test APIs.
While every software team and company have different needs, as a generalization, StackHawk is a better fit for companies that are embracing DevSecOps and Acunetix is a better fit for more traditional software development orgs.
Below is an overview of the key differences between the products. After that, let’s dive into a bit more detail and see how the two stack up when it comes to scanner fundamentals, application coverage, how they can help security teams scale AppSec, and more.
|Automated Authenticated Scanning|
|Server-side HTML Application Testing|
|Single Page Application Testing|
|SOAP API Testing|
|REST API Testing|
|Technology Specific API Scan Configs|
|Optimized for Fast Scanning in CI/CD|
|No Infrastructure Configuration Required|
|Findings Triage and State Management|
|Finding History and Documentation|
|Docker-Based Scanner to Scan Anywhere|
|Integrations with All Major CI/CD Tools|
|User-First Web Application|
|Simplified YAML Configuration|
|Simplified Fixes with Docs and cURL Command Generation|
|MS Teams Integration|
|OpenAPI Spec Integration for API Testing|
The Basics: Core Product Differences
Both Acunetix and StackHawk have comprehensive scanning engines that find common vulnerabilities in the applications that your team has developed. The two tools have different underlying scanners, and take different approaches when it comes to deployment.
Acunetix has always focused on creating a highly-performant scanner. The company actively maintains the proprietary scanner it developed in 2005. The Acunetix scanner tests network security vulnerabilities as an add-on to its core application security testing. The scanner also permits multiple scanning agents to be deployed concurrently to further accelerate scanning.
To best scan target sites, Acunetix offers two deployment models - a cloud-based scanner and an on-premise scanner (though standard users only have access to on-prem).
For those that prefer to keep all scan data in-house, the on-premise approach can work well. The cloud-based service is a good option for those that prefer to offload infrastructure management and reap the benefits of a SaaS model.
An important note for each deployment model is that for Acunetix to be able to successfully scan a target, the running app needs to be accessible from the hosted/on-prem scanner. For companies using the cloud-based scanner, this means that the application needs to be publicly available, limiting the ability to automate testing in the DevOps pipeline.
StackHawk is built on top of the world’s most widely used vulnerability scanner - ZAP. ZAP was released in 2011, and has been maintained by an active and trusted open source community ever since. StackHawk has made updates to the ZAP scanner to better suit the needs of modern security teams. A few highlights include:
Technology Flags for Scan Scoping. When configuring a scan in StackHawk, users can select the underlying technologies used within the application. This ensures that the scanner only runs relevant tests, reducing scan times and false positives.
Scanner Performance. StackHawk has optimized ZAP’s performance to ensure that tests run quickly and successfully every time.
Results Streaming. Findings are sent to the StackHawk platform as the scan runs so users can begin triaging and fixing vulnerabilities right away.
StackHawk’s scanner is built to test for vulnerabilities before an application is deployed into production, enabling teams to fix findings faster and deliver secure software out of the gate.. With automated testing in CI/CD, StackHawk will alert a developer if she has introduced a new vulnerability, allowing for a fix while that part of the codebase is still fresh in her mind.
The StackHawk scanner is packaged in a Docker container, allowing scans to be run in CI/CD, on a local machine, or against production. Configuration is managed through a yaml code file, allowing for scalability and version control. While the StackHawk scanner runs on a local machine or build server, the product is cloud-based software, with results streaming back to the StackHawk web application.
Support for Modern Applications
Modern App and API Support
Authenticated scanning can be tricky no matter what tool you use. Acunetix has tried to simplify scan authentication through its Login Sequence Recorder.
The Login Sequence Recorder supports different types of authentication. For simple logins, users can have Acunetix auto-login into a target website by saving credential information like username and password in the Acunetix platform.
For instances where users are required to provide a differing variable at each login, like with a CAPTCHA or MFA, users note this in the login recorder. At scan time, Acunetix will pause and prompt the user for a `Manual Intervention Action` to allow the scan to proceed.
The Login Sequence Recorder does support OAuth2. Users are able to provide the platform with access tokens, authorization URLs, and other application identifiers to grant access to an OAuth2 authentication flow.
If you have simple authentication scenarios, the Login Sequence Recorder can be helpful. While the Login Sequence Recorder makes it simple for initial testing, it is built for testing production applications and limits capabilities for DevSecOps automation.
Modern App and API Support
StackHawk was built to test modern applications and APIs, including REST, SOAP, and GraphQL. Rather than relying on a crawl of the application to identify the API routes, StackHawk leverages API documentation (OpenAPI Specification, GraphQL introspection, or WSDL files) to fully test the underlying API.
With StackHawk’s API configuration, the scanner is highly performant and accurate, only running relevant tests based on the technologies used within the application. Additionally, the StackHawk scanner recognizes REST parameters, which allows it to only test the API endpoint once. Scanners that leverage a crawl of the application for API testing are significantly less performant and accurate, testing every path variant for the same underlying API route and sending requests that are not relevant to the specifc technology (E.g., XML requests to REST APIs).
Together, all of these features work to help users get fast and accurate scans, even on complex modern web apps.
StackHawk supports the three most common authentication scenarios:
For all of these scenarios, the user defines the expected experience of an authenticated user in the StackHawk configuration file. Users provide logged in and logged out indicators, the login route, and the credentials for the type of authentication the app requires.
By controlling authentication in the configuration file, StackHawk users get flexibility to fit whatever authentication scenario an app requires. Users can run automated scans that require complex authentication scenarios without having to manually intervene. For companies that already leverage automated test suites, such as integration testing, the same authentication logic can typically be used for StackHawk.
Scaling AppSec Across the Development Org
DAST has begun to shift into the CI/CD pipeline as teams try to make security just another part of code quality. With this model, security teams can work collaboratively with developers to remediate vulnerabilities.
But, successfully making this happen requires that the security tools are developer friendly – meaning they fit into the dev workflow and provide team members with less security experience the ability to make informed decisions when it comes to risk.
Automating in CI/CD
Acunetix has introduced integrations that makes it possible for certain CI/CD systems to kick off a DAST scan as the application enters a publicly available staging or test build. In doing so, security testing can become part of the pre-release checks typically run by a QA team.
As Acunetix states, this approach makes security testing a phase between “test” and “release” in the DevOps pipeline.
It is important to note the limits of this approach:
To automate Acunetix scans in CI/CD, an engineering team must make their staging / test site publicly available. Not only does this introduce additional engineering complexity, but it also means that vulnerabilities must be publicly exploitable before they can be identified.
This approach to security test automation typically results in testing the complete user facing application rather than testing each microservice individually, resulting in longer scan times and difficulty aligning findings with a specific engineering team.
While this testing is automated in CI/CD, it is also late in the delivery lifecycle. The specifics differ based on CI/CD implementation, but oftentimes an engineer has already moved on to a different project by the time Acunetix would find a potential vulnerability.
A final caveat - not every tier of Acunetix includes CI/CD integrations - standard options do not have access to this tooling.
User Experience for Development Teams
Acunetix provides two main ways for security teams to interface with development teams – issue tracker integration and specific developer reports.
With issue tracker integrations, security teams can send findings into tools like Jira or GitLab. In the ticket, Acunetix includes details around the vulnerability like criticality level, a vulnerability description and evidence that the finding exists. Unfortunately, this approach leaves finding and fixing roles divided. This can mean long lead times to get vulnerabilities fixed, as engineering teams try to work security remediation into sprints and developers revisit code they wrote weeks or months ago.
In addition to issue tracking integrations, Acunetix Premium and 360 tiers also provide a ‘Developer Report’ for the engineers fixing vulnerabilities. The report provides information on the files which have a long response time, a list of external links, email addresses, client scripts and external hosts, together with remediation examples and best practice recommendations for fixing the vulnerabilities. This report is aligned with an engineering organization that would appoint a single individual to fix a batch of security issues.
Automating in CI/CD
StackHawk is purpose-built for automation in CI/CD. With the containerized scanner, StackHawk can be run at any stage of the DevOps pipeline. Developers will often configure pre-commit hooks to check their code for new vulnerabilities and engineering teams will instrument StackHawk alongside unit and integration tests in CI/CD.
StackHawk has a comprehensive set of CI/CD integrations, making it easy to add StackHawk to the tooling your company uses. Like all bugs, fixing vulnerabilities earlier in the development cycle is faster and cheaper. Developers are able to quickly remediate without context switching and without sacrificing velocity.
User Experience for Development Teams
StackHawk has optimized its user interface, findings details, and findings recreation to work for both developers and security teams.
When a potential vulnerability is identified, the terminal output and web app UI provides teams with cheat sheets to understand what the vulnerability is and how to fix it. Every finding has request and response details, and the platform provides developers with a cURL command to recreate a vulnerability in their IDE so vulnerabilities can be fixed on the fly.
To keep the vulnerability notifications streamlined, StackHawk does not repeat reporting on triaged findings. Once a finding is handled - either sent to a ticketing system, marked as risk accepted, or marked as a false positive, the scanner will no longer flag this as a new vulnerability, minimizing noise and driving toward action.
The Fine Print
Pricing and Access
Acunetix offers three tiers of its product - Standard, Premium and 360. The primary driver for cost across all three of these tiers is the number of target sites a user would like to scan, with major pricing jumps happening at five sites, 10 sites, and 50 sites.
The three tiers vary in the number of users that have access to the scanner, the types of integrations provided, and reporting capabilities.
Pricing and Access
Like Acunetix, StackHawk has three tiers – the free Developer Plan, the Pro Plan, and the Enterprise Plan.
Engineering teams can get started testing their first application for free. For teams testing multiple applications, StackHawk is priced per user. It is important to note that all tiers include full access to CI/CD integrations.
So Which Tool Should You Choose?
When deciding the right tool for org, it is important to think about how your team wants to approach AppSec more broadly before narrowing in on one tool or another.
We are obviously biased, but think that StackHawk offers teams the most important capabilities to shift AppSec left.