Dynamic application security testing (DAST) is a crucial security approach that analyzes a running application to uncover vulnerabilities and weaknesses. Think of it as a live fire drill for your application, stress-testing its defenses in realistic conditions. Unlike static application security testing (SAST), which analyzes source code, DAST interacts directly with a live application to identify vulnerabilities that SAST might miss.
Because DAST evaluates an application in a real-world setting, it generally produces fewer false positives than SAST, although some can still occur. This allows engineers to focus on real threats more efficiently.
In the software development life cycle (SDLC), DAST takes place once an application is running in a staging or testing environment. However, modern DevSecOps practices, such as those promoted by Red Hat, encourage earlier adoption in continuous integration and continuous delivery (CI/CD) workflows. This allows security assessments before deployment, uncovering runtime issues such as authentication flaws and security misconfigurations. DAST is a valuable complement alongside other security testing activities, providing a more comprehensive security assessment.
Is DAST automated or manual?
DAST can be both! Automated tools simulate various attacks and are the foundation of many DAST processes, making them ideal for CI/CD integration and continuous security testing. Manual testing provides a deeper, more creative exploration of potential weaknesses and is especially useful for identifying complex logic flaws that automated tools might overlook.
What is RapiDAST?
RapiDAST is an open source dynamic application security testing tool developed by the Red Hat Product Security team and is currently being used by various Red Hat engineering teams. RapiDAST initially focused on web apps and API security. It has now evolved to offer broader test coverage, automating and streamlining vulnerability scanning to ensure ease of use.
RapiDAST offers key features such as automated HTTP/API scanning, Kubernetes operator security testing, and integration with tools like Nessus. The tool also provides customizable configurations, multi-format reporting, and integration with cloud storage and platforms like OWASP DefectDojo to simplify vulnerability management.
How RapiDAST works
A typical use case for RapiDAST is web scanning, as it automates security vulnerability detection for web applications and APIs. It seamlessly integrates with OpenAPI (formerly Swagger) specifications, which provide a structured way to define API details. If a project lacks an OpenAPI definition, RapiDAST can still scan applications by crawling HTML pages using Spider to discover and analyze URLs dynamically.
A practical example: Scanning a movie rating application with RapiDAST
Let's scan a local movie rating app to identify potential vulnerabilities using RapiDAST. Since this application exposes an OpenAPI file, we can efficiently scan it using the following steps. Let's dive in.
Step 1: Setting up RapiDAST
There are two ways to run RapiDAST:
- Cloning the GitHub repository and running from source.
- Using a pre-built RapiDAST container image maintained by the Red Hat Product Security team.
To keep things simple, we’ll proceed with the second method. Before you begin, ensure that Podman is installed on your system. We recommend using version 3.0.1 or later.
Step 2: Creating the RapiDAST configuration file
Before running RapiDAST, you need to create a configuration file. This file defines the target endpoint, along with other settings and authentication, such as OAuth2, basic auth, cookie, HTTP headers, or browser authentication. If you want RapiDAST to export scan results to external services like DefectDojo or Google Cloud Storage, those services must be specified in the configuration file.
The sample configuration file below defines these parameters appropriately:
# filename: rapidast-config.yaml
config:
configVersion: 6
googleCloudStorage:
keyfile: "<keyfile>"
bucketName: "<bucket_name>"
directory: "<directory_name>"
application:
shortName: "vuln MDB 1.0"
url: "http://127.0.0.1:5000"
scanners:
zap_authenticated:
authentication:
type: "cookie"
parameters:
name: "auth_id"
value: "<authentication_token>"
apiScan:
apis:
apiUrl: "http://127.0.0.1:5000/openapi.json"
passiveScan:
disabledRules: "2,10015,10027,10096,10024,10098,10023"
activeScan:
policy: "API-scan-minimal"
report:
format: ["json", "html"]
miscOptions:
updateAddons: falseStep 3: Launching a scan and retrieving results
Execute the following podman command:
podman run \
-v ./rapidast-config.yaml:/opt/rapidast/config/config.yaml:Z \
-v ./results/:/opt/rapidast/results/:Z \
quay.io/redhatproductsecurity/rapidast:latestThis command runs RapiDAST in a container using a pre-built image, with the configuration and results directories mounted into the container. Once the scan is complete, the results directory will contain artifacts such as zap-report.json and human-readable reports like zap-report.html, providing valuable insights into the identified vulnerabilities.
# cat ./results/zap/zap-report.json | grep 'alert'
"alerts": [
"alertRef": "10105-1",
"alert": "Authentication Credentials Captured",
"alertRef": "10111",
"alert": "Authentication Request Identified",
"alerts": [
"alertRef": "40018",
"alert": "SQL Injection",
"alertRef": "10055-4",
"alert": "CSP: Wildcard Directive",
"alertRef": "10055-10",
"alert": "CSP: script-src unsafe-eval",
"alertRef": "10055-5",
"alert": "CSP: script-src unsafe-inline",
"alertRef": "10055-6",
"alert": "CSP: style-src unsafe-inline",
"alertRef": "10111",
"alert": "Authentication Request Identified",Interpreting RapiDAST results
Since RapiDAST leverages ZAP (Zed Attack Proxy) as its core scanning engine in this example, the generated HTML and JSON reports are the ZAP reports. As Figure 1 shows, these reports contain detailed insights, including a list of detected security vulnerabilities, HTTP request and response details showing how the scan interacted with the application, and risk categorization across different risk levels.
While DAST scans generally produce fewer false-positives than SAST, each reported finding should be carefully reviewed and addressed accordingly.
Defining production-ready DAST strategies
Actual CI/CD implementations should perform tests before every release and continuously to make sure that there is no degradation in the system. What if a security control suddenly stops working? Security controls should be tested automatically and continuously to make sure they are accomplishing their roles at every moment. A security control failure could increase the likelihood of an attack, potentially leading to data compromise, reputational damage, and loss of customer trust.
The RapiDAST team has made a significant effort to simplify the setup process, enabling seamless integration into various pipelines. The RapiDAST GitHub repository contains examples of the most used implementations, such as GitHub and Jenkins, allowing quality engineering teams to quickly integrate basic scans into their infrastructure.
Best practices with RapiDAST from Red Hat security experts
Here are key recommendations to maximize the effectiveness of RapiDAST in your security workflows.
Trust, but verify
It is a common development practice to use a staging environment where changes are deployed and tested before reaching production. This approach helps prevent denial of service issues and system regressions. While users might be tempted to use RapiDAST in production machines, we strongly advise against this, as users can impact the performance of real-life systems. Therefore, we encourage teams to adjust their testing instances to match production and avoid unwanted surprises.
Defense in depth
Security in depth is a broadly followed security principle where multiple layers of security controls are placed to provide redundancy in case one of them fails. When performing DAST, we should always consider that one of the defense mechanisms might fail, making external dynamic testing essential. This ensures our requests go through all network components, including firewalls, CDNs, and Web Application Firewalls (WAF). Additionally, have internal scanners in place to understand the risk we face if some of our security controls start failing and consider implementing compensatory measures.
Unauthenticated and authenticated scans
Sensitive API endpoints should always be protected with authentication and authorization. In the same way, we test all of our security controls by performing internal and external tests. We should also perform authenticated and unauthenticated scans to ensure unprivileged users cannot access restricted resources.
RapiDAST for security researchers and enthusiasts
We’ve discussed how RapiDAST is useful for developers and QE engineers to identify and fix security problems in their internet-exposed deployments, but RapiDAST can also be very useful for security researchers, bug bounty hunters, and security enthusiasts.
Many companies use open source projects or expose their OpenAPI specification files, enabling researchers to automate their processes for finding security flaws.Additionally, because of the tool’s simplicity, cybersecurity beginners can use RapiDAST to start learning how the interactions between a client and a server interact: web requests, cookies, and APIs. By highlighting a more simplified user interface for understanding requests and flaws, and providing information about how to solve the vulnerability, newcomers can have an accessible path to web security.
RapiDAST and AI
There are several ways we can use RapiDAST to enhance our workflow and increase our testing coverage by adding AI capabilities. On the one hand, we can extend RapiDAST to analyze the response of large language models (LLM) models to make sure that they cannot produce dangerous output that could affect the security and safety of our products.
On the other hand, we could use LLM models to enhance the following reporting capabilities:
- Analysis of results: LLMs could be used by security researchers to help them analyze the results and determine false positives more quickly.
- Report generation: Currently, the results from different tools are shown in very simple formats, such as .TXT and .JSON, per tool. Having an LLM to analyze and parse all results to generate automated reports will help security researchers present findings in a more organized manner.
Interested in contributing to RapiDAST?
There are several ways to get involved in contributing to RapiDAST:
- Add a new integration for a pipeline. Red Hat’s open source DAST tool is simple to use, making the addition of a new pipeline integration straightforward and easy to share with the community. Sharing that integration with the community can foster the adoption of that pipeline, and you will benefit from enhancements from other open source adopters.
- Integrate a new tool. If you want to extend RapiDAST with a tool you use daily, incorporating new tools into RapiDAST can increase product coverage. With a simple scan, you will get results from various scans at the same time. This will increase vulnerability detection and reduce the attack surface of your product.
We highly encourage collaboration and contribution to RapiDAST. Whether you’re fixing bugs, adding features, enhancing documentation, or refining automation, even small improvements count. Your ideas and involvement can make a significant impact!
Wrap up
RapiDAST simplifies and streamlines DAST, making it accessible to security researchers, bug bounty hunters, and development teams. Automating security scans helps identify vulnerabilities in the development lifecycle, reducing risks and improving application security.
Red Hat performs DAST as part of the SDLC using RapiDAST, ensuring continuous security testing and proactive risk management across its products. To learn more, check out An Overview of Red Hat’s Secure Development Lifecycle (SDLC) practices.
Whether you are a security enthusiast exploring DAST or an enterprise integration security into your CI/CD pipeline, RapiDAST offers a powerful and flexible solution that can be customized for your own needs.
