DAST Integration for Web Applications: Dynamic Security Testing

Problem: Vulnerabilities SAST Misses

You use static code analysis, but production still gets hacked through improper Nginx configuration or IDOR in an API not covered by tests. SAST analyzes code, but the application runs in an environment—with a server, middleware, third-party services. That's where runtime vulnerabilities emerge. DAST (Dynamic Application Security Testing) solves this: it attacks the application like an external attacker and finds what static analysis hides.

We have been setting up DAST for websites and APIs for over 10 years. During this time, we have executed more than 50 security projects, from e-commerce stores to fintech platforms. Here's one case: a client lost 2 million RUB due to an SQL injection that SAST missed. After integrating ZAP into CI/CD, such vulnerabilities stopped reaching production. On average, savings on manual audits reach 70%—automation pays off in a couple of months. According to OWASP Top 10, about 40% of critical vulnerabilities are in the runtime category, and the average data breach cost for small and medium businesses is 3 million RUB. This translates to average savings of 2.1 million RUB per breach avoided.

Why DAST Cannot Replace SAST

DAST checks the running application in its real environment. It sees:

• Server misconfiguration (open CORS, weak headers)
• Runtime vulnerabilities (RCE, SSRF, IDOR)
• Authentication issues (invalid sessions, weak tokens)

SAST analyzes code but doesn't know how it executes. DAST acts from the hacker's perspective. For example, X-Frame-Options is configured on the server, and SAST won't check it. DAST sends a request and sees the header is missing. Without DAST, you risk missing up to 95% of runtime vulnerabilities, which make up 40% of all critical issues. Furthermore, DAST scans are 10x faster than manual penetration testing, catching vulnerabilities in minutes.

How to Integrate DAST into CI/CD

DAST integration directly enhances CI/CD security by catching runtime vulnerabilities before deployment. For example, our GitHub Actions DAST pipeline runs on every push. We integrate DAST into your pipeline to automatically find vulnerabilities before deployment. Here's a typical process:

1. Choose a tool: For websites, OWASP ZAP (open source, flexible); for APIs, ZAP API scan or Nuclei.
2. Set up rules: Define which vulnerabilities are critical (SQLi, XSS) and which are warnings.
3. Integrate with CI/CD: Run on every push or on a schedule, generate a report, fail the pipeline on critical findings.
4. Customize: Add authentication, configure scope, exclude sensitive endpoints.

Example: OWASP ZAP in GitHub Actions

# .github/workflows/dast.yml name: DAST on: push: branches: [main] schedule: - cron: '0 2 * * 1' jobs: zap-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Start application run: | docker compose -f docker-compose.test.yml up -d sleep 30 - name: Run ZAP Baseline Scan uses: zaproxy/[email protected] with: target: http://localhost:3000 rules_file_name: .zap/rules.tsv cmd_options: '-a' - name: Upload ZAP report uses: actions/upload-artifact@v4 if: always() with: name: zap-report path: report_html.html - name: Stop application if: always() run: docker compose -f docker-compose.test.yml down 

# .zap/rules.tsv # rule_id action reason 10017 WARN # X-Frame-Options header 10038 WARN # Content Security Policy 40012 FAIL # Cross Site Scripting 40018 FAIL # SQL Injection 90011 IGNORE # Charset mismatch 

DAST Tool Comparison

ZAP is best for CI/CD automation: fast baseline scan (5-10 min) and detailed full scan. Its baseline scan is 10x faster than Burp Suite's automated crawl, making it ideal for CI/CD. Nuclei is efficient for checking specific CVEs—run it in 5 minutes and get a list of known vulnerabilities. Burp Suite is used for manual penetration testing when deep business logic testing is needed.

DAST Setup Stages

What's Included in DAST Setup

Our service includes:

• Analyzing your application architecture and selecting the right tools.
• Configuring OWASP ZAP (or Nuclei) in your CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Writing custom rules to filter false positives.
• Setting up automatic regression: if a new version introduces a critical vulnerability, the pipeline fails.
• Configuring scheduled scanning (weekly).
• Training your team on report interpretation.
• Providing documentation: configurations, rules, instructions for adding new projects.
• Two weeks of post-deployment support: rule adjustments, exclusion additions.

Common DAST Implementation Mistakes

1. Scanning production environment. Active scanning can break data. Always use staging.
2. Ignoring authentication. DAST must act as an authenticated user, otherwise it misses protected endpoints.
3. No false positive filtering. Without custom rules, ZAP yields hundreds of warnings that nobody examines.
4. Running only manual scans. Automation in CI/CD is the only way to consistently catch vulnerabilities.

Timeline and Cost

Timelines depend on complexity:

• Basic ZAP setup in CI/CD: 1-2 days.
• Adding Nuclei and Burp Suite: 3-5 days.
• Custom rule tuning and automated tests: up to 7 days.

Cost is calculated individually. You get a stable DAST pipeline that protects against critical vulnerabilities. Reach out for a consultation—we will discuss your project and find the optimal solution. We guarantee the setup won't break your staging environment and provide post-deployment support.

# rule_id action reason 90001 IGNORE # Application error disclosure 90011 IGNORE # Charset mismatch 10017 WARN # X-Frame-Options header 10038 WARN # Content Security Policy 40012 FAIL # Cross Site Scripting 40018 FAIL # SQL Injection