DevSecOps Automation II: A Deep Dive into DAST

#devsecops #dast #security #automation

In the first part of this series, we looked at Static Application Security Testing (SAST) — scanning source code without executing the application; a pre-staging step.

Dynamic Application Security Testing (DAST) is a step further to securing your application after SAST. It is black-box testing that crawls your running application then sends malicious payloads in the same way an attacker would to find vulnerabilities in the application, if any. DAST sends requests and analyses responses to detect various vulnerabilities such as cross-site scripting injection (XSS), SQL injection, broken authentication and authorization flow, etc.

Difference between SAST and DAST

Neither SAST nor DAST should replace one another but both should be used at each stage of its usefulness. A standard DevSecOps pipeline runs both — SAST early in the commit/PR stage, DAST later against a running build (staging, or increasingly, production with safe rules of engagement). Let's look at the areas where both automations come into play:

SAST	DAST
Insecure code patterns	Runtime misconfigurations
Hardcoded secrets in code repository	Exposed secrets in live responses/headers
Vulnerable logic before compilation	Broken auth/session handling

How to Get Started with DAST

There are various technological tools that help to automate dynamic security scanning test. Some are:

OWASP ZAP: This is a free open source software, excellent for CI/CD (Docker images, GitHub Actions).
Nuclei: A good template-driven tool. It's fast and supports YAML templates. It's free and open source.
StackHawk: This is a commercial tool built on top of ZAP. It's CI-native and designed for automated authentication in pipelines.

Running ZAP with Docker images

Zed Attack Proxy (ZAP) is a free, open-source penetration testing tool designed specifically for testing web applications. ZAP has installers for Windows, Linux, and macOS, but for this article we will make use of the Docker image (easy-peasy...).

Download the ZAP Docker image (stable version)

docker pull ghcr.io/zaproxy/zaproxy:stable
docker pull zaproxy/zap-stable

Mount the working directory

docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable zap.sh ...

Perform API scanning

docker run -t zaproxy/zap-stable zap-api-scan.py \ 
  -t https://example.com \                
  -f openapi \      
  -r zap-report.html

NOTE: zap-api-scan.py is the wrapper script that calls zap.sh internally. https://example.com is the URL of our live application; ensure you are authorized to perform scanning on a website before you scan it. zap-report.html tells the location file for the report output while openapi tells the format — either OpenAPI, SOAP, or GraphQL.

A typical report sheet looks like this:

This report sheet summarizes the scan done and it provides valuable insights to better secure your live application. This is a great tool to explore!

GitLab vs GitHub: Native DAST Support

GitLab provides support for DAST on the fly with a simple YAML template. It handles pulling the scanner image, running it, and publishing results to the Security Dashboard and merge request widget automatically. GitHub's version takes more YAML and more of your own auth/context scripting, but you can point it at literally any DAST product of your choice. Let's breakdown the distinction between the two products:

Gitlab	Github
Native DAST support built into CI/CD	No native DAST product.
Include one template	Write your own workflow
Separate `DAST API` template for API-specific scans	Same ZAP `zap-api-scan.py` approach, just self-orchestrated

Where This Fits in the Bigger Picture

Neither SAST nor DAST alone gives you real coverage. A pipeline that's actually doing DevSecOps well typically looks like:

SAST: Setup on every PR gives fast, source-level feedback before merge.
SCA (software composition analysis): This scans dependencies for known CVEs.
DAST: Run scans against staging environment on every merge (baseline) and periodically (nightly/weekly) — catching what only shows up at runtime.
IAST: It combines elements of SAST and DAST into a hybrid approach.

Conclusion

DAST functions in its place in the DevSecOps pipeline precisely because it focuses on what the application does at runtime. It's running, reachable, and being hit with the same kind of traffic a real attacker would send. That's a different purpose compared to SAST, and in a world of API-first architectures, drifting cloud configs, and release cycles measured in hours rather than quarters, it's a step you can't afford to skip.
SAST catches what's wrong before you ship it. DAST catches what's wrong after shipping to production/staging. Together, they cover far more ground than either does alone, and that pairing is really the core idea this whole series is building toward.