While next-generation DAST tools are far better than their traditional counterparts at scanning web applications and APIs for vulnerabilities, they aren’t perfect. This piece details
the key features to look for in a DAST tool and offers recommendations for choosing the right tool for your environment.
What are DAST Tools?
DAST tools were originally designed to crawl and scan web applications using HTML form-based requests. However, web applications today are breaking up into single-page applications (SPAs) and hundreds (or thousands) of microservice endpoints. Traditional
DAST tools were struggling to make the transition, which requires parsing the SPA’s endpoints, discovering parameters and invoking the scanner. In recent years, these tools have been reinvented with new capabilities to overcome these challenges,
including:
- Automation: DAST tools were originally designed for security auditors, not for automated scanning in continuous integration/continuous deployment (CI/CD) pipelines. Early DAST tooling required security engineers to manage scans from a user interface
(e.g., a web console), a setup that cannot scale in microservice environments. Today, no enterprise should purchase a DAST tool that cannot be automated through a REST API or command-line interface (CLI).
- Configuration capabilities: DAST tools are complex to configure. Engineers must spend time learning the configuration options for crawling, authenticating, scoping parameters and suppressing false positives for each application. Ensure the DAST
tool’s documentation clearly describes how to configure a scan, ideally, using a machine-readable configuration file syntax (e.g., JSON, YAML, etc.) that can be stored in a version control system.
- Web services support: Crawling SPAs and parsing API endpoints is complex, slow and often inaccurate. To fully support scanning web services, DAST tools must be able to import API documentation (e.g., OpenAPI, WSDL) to discover routes, parameters
and responses.
- Integrations: The days of exporting DAST scan PDF reports for delivery to development teams are behind us. DAST tools must make vulnerability data accessible programmatically through the REST API or CLI. Machine-readable formats, such as JSON or
SARIF, allow DAST results to be integrated with vulnerability management and ticketing systems. Bonus points are awarded for plugins integrating directly with CI/CD systems (e.g., Jenkins,
Azure DevOps, GitHub Actions, GitLab CI/CD) and ticketing systems (e.g., GitHub, GitLab, Jira, ServiceNow).
- Quick-scan support: Full DAST scans can take several hours to complete, which is too slow for fast-moving development teams. DAST tools should also provide configuration options for lightweight quick scans. Security teams can run lightweight DAST
scans and provide fast feedback during development cycles. Full DAST scans can then be run on a schedule (e.g., weekly) and results published to the development team’s backlog.
READ: Secure Coding Basics for Developers
Tips for Choosing a DAST Tool
Next-generation DAST tools are designed specifically to uncover vulnerabilities in today’s web application and APIs. However, some are difficult to configure, lack automation capabilities, fail to integrate with other tools, produce false positives
and cannot crawl SPAs. To ensure the tool you use works as expected:
- Beware of vendors that do not provide a trial license: Do not evaluate products with a vendor’s demo application. Ensure the product is tested in your environment against real-world systems.
- Spend time on the scan configuration: Ensure DAST tool performance meets your speed requirements. Fine-tune scan configurations to disable rules, time-box the scanner and suppress false positives.
- Focus on workflow integration: Use a CI/CD system to start a scan and programmatically read vulnerability findings, and practice pushing the vulnerability findings into the development team’s backlog and a vulnerability management system.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.