Dynamic Application Security Testing (DAST) integrates into CI/CD pipelines to detect vulnerabilities early, supporting regulatory compliance like DORA. Complementary tools like SAST and SCA enhance security, but challenges include alert overload and the need for unified reporting dashboards.

Richard Seidl Software Testing

This is the other podcast on Software Testing by Richard Seidl, the episodes are in spoken German but the show notes and site are written in English. Our summaries are generated from AI transcript translations.

• https://www.richard-seidl.com/en/blog/tag/podcast-software-testing
• https://www.richard-seidl.com/en/

Episode Details

• Show Notes: https://www.richard-seidl.com/de/podcast/dast-sicherheitstests-dora
• Published: 2026-10-20T04:00:00Z
• Duration: 00:20:04
• Author: Richard Seidl - Experte fur Software-Entwicklung und Testautomatisierung

Overview

The podcast discusses the integration of Dynamic Application Security Testing (DAST) into the software development lifecycle, particularly in response to regulatory requirements like the EU’s Digital Operational Resilience Act (DORA). DAST is used to automatically detect vulnerabilities such as SQL injection and cross-site scripting by running attacks against applications in test environments. This approach supports a “shift-left” strategy, enabling early and continuous security testing by integrating DAST into CI/CD pipelines using tools like Jenkins, rather than relying solely on late-stage penetration testing.

The discussion also covers complementary security testing methods, including Static Application Security Testing (SAST) for source code analysis and Software Composition Analysis (SCA) for identifying vulnerabilities in third-party libraries. Open-source tools such as ZAP and Burp Suite Community Edition are highlighted for their role in DAST, with automation achieved through proxy-based traffic recording and attack simulation. Challenges include managing the volume of security alerts and the lack of centralized reporting across tools, prompting a need for unified dashboards to consolidate findings from DAST, SAST, SCA, and infrastructure scans to improve developer efficiency and compliance.

What If

• What if you automated DAST scans in your CI/CD pipeline using open-source tools like ZAP?

  • Move: Integrate OWASP ZAP into your Jenkins or GitHub Actions workflow to run automated DAST scans after each pre-production deployment, using API traffic from existing Playwright or Selenium regression tests to seed the explore phase.
  • Why Now?: Regulatory standards like DORA now require early and repeated security testing; delaying integration increases compliance risk and technical debt, especially as solo developers face growing scrutiny over application security.
  • Expected Upside: Catch critical vulnerabilities (e.g., SQLi, XSS) before production, reduce reliance on costly pentests, and build compliance-ready processes that scale without adding team members.

• What if you replaced manual security checks with a shift-left combo of SAST, SCA, and DAST in your development cycle?

  • Move: Set up a three-layer security scan in your local dev environment: use SonarLint (SAST) for real-time code analysis, Snyk (SCA) to flag vulnerable dependencies, and ZAP (DAST) in proxy mode during automated UI testing to detect runtime flaws.
  • Why Now?: With DORA and similar regulations pushing security left, waiting for final pentests creates bottlenecks; solo developers must bake in security early to avoid last-minute rework and failed audits.
  • Expected Upside: Reduce post-deployment fire drills by 60 - 80%, minimize duplicate alerts through layered tooling, and maintain development velocity while meeting compliance requirements.

• What if you built a unified security dashboard to consolidate findings from DAST, SCA, and SAST tools?

  • Move: Use ZAP’s JSON/XML export, Snyk CLI reports, and SonarQube webhooks to push all scan results into a lightweight dashboard (e.g., using Python Flask + SQLite or Notion DB), tagging duplicates and prioritizing by severity and exploitability.
  • Why Now?: Scattered reports lead to alert fatigue and missed vulnerabilities - especially dangerous for solo operators who can’t afford oversight - while upcoming audit cycles demand clear, traceable remediation records.
  • Expected Upside: Cut time spent triaging alerts by 50%, improve fix rates for high-risk issues, and create a single source of truth that simplifies compliance reporting and developer accountability.

Takeaway

• Integrate DAST tools like OWASP ZAP into your CI/CD pipeline using Jenkins to automatically run security tests after deployment to pre-production environments.
• Use existing functional test suites (e.g., Playwright or Selenium) to drive the DAST tool’s explore phase, reducing manual setup and increasing test coverage.
• Configure DAST tools with custom attack profiles (e.g., database-specific rules) and provide API specifications (OpenAPI, GraphQL) to target relevant vulnerabilities efficiently.
• Adopt a shift-left approach by combining DAST with SAST and SCA in your development workflow to catch security issues early and avoid last-minute compliance surprises.
• Consolidate security tool outputs (DAST, SAST, SCA, etc.) into a centralized reporting system or dashboard to reduce duplicate alerts and streamline developer remediation efforts.