Dynamic Application Security Testing (DAST)
ELI5 Explanation
DAST tests your running app like an attacker would. Instead of reading code, it checks behavior through real HTTP requests.
Technical Explanation
DAST identifies runtime vulnerabilities such as insecure headers, broken authentication flows, reflected XSS, and weak session handling. It is typically run against QA or staging deployments and complements SAST by validating exploitable behavior.
Visual
Hands-on Commands
veracode dast scan create --name orders-staging
veracode dast target set --scan orders-staging --url https://staging.orders.example.com
veracode dast credentials set --scan orders-staging --profile qa-login
veracode dast run --scan orders-staging
veracode dast findings --scan orders-staging --severity high,criticalDebugging Scenario
DAST reports broken auth after SSO change. Investigation shows scanner login profile expired. Updating auth script and session cookie handling restores accurate results.
Interview Questions
Beginner
- What is DAST?
- How is DAST different from SAST?
- Why run DAST in staging?
- What kind of issues can DAST find?
- Can DAST see source code?
Intermediate
- How do you handle authenticated DAST scans?
- How do you reduce false positives in DAST?
- When should DAST block release?
- How do you tune scan scope for large apps?
- How does API testing fit into DAST strategy?
Scenario-based
- DAST misses a known URL path. What configuration do you inspect?
- Scan time exceeds deployment window. How do you adapt pipeline design?
- Critical DAST finding appears only in prod-like traffic. What next?
- Authenticated scan keeps logging out. How do you stabilize session flow?
- DAST blocks releases too often. How do you calibrate policy?
Real-world Use Case
A banking app caught missing security headers and open redirect risk in staging through DAST before a major customer release.
Summary
DAST validates runtime security posture and complements code-level analysis. Next lesson covers SCA to manage open-source dependency risk.