Q11 of 24 · Security

What is the difference between SAST and DAST, and where does each fit in a QA workflow?

SecurityMidsecuritysastdastci-cdstatic-analysisdynamic-testing

Short answer

Short answer: SAST (Static Application Security Testing) analyses source code without running it — fast, runs in the IDE or PR gate, but produces false positives. DAST (Dynamic Application Security Testing) tests the running application — slower, fewer false positives, but requires a deployed environment. Neither is sufficient alone.

Detail

SAST operates on source code, bytecode, or binaries without executing them. Tools: Semgrep, SonarQube, Checkmarx, Veracode. It can find:

  • Hardcoded credentials
  • SQL query construction via string concatenation
  • Unsafe deserialization patterns
  • Insecure cryptographic algorithms (MD5, SHA1 for password hashing)
  • Dependency vulnerabilities (when combined with SCA)

SAST runs in the IDE (developer gets instant feedback), in PR CI gates (blocks merge on critical findings), and does not need a running environment. The weakness: high false-positive rate, no runtime context (can't evaluate whether a vulnerable code path is actually reachable), and language-specific tools mean polyglot codebases need multiple tools.

DAST tests the live running application by sending attack payloads and observing responses. Tools: OWASP ZAP, Burp Suite (manual-guided), Invicti, HCL AppScan. It can find:

  • Reflected and stored XSS (by injecting payloads and checking responses)
  • SQL injection (by observing error responses and timing)
  • Security misconfigurations (missing headers, open admin paths)
  • Authentication and authorisation issues at the HTTP level

DAST requires a deployed, accessible application. It runs in staging, typically in a nightly or scheduled job. It finds things SAST misses (runtime behaviour, configuration issues) and produces fewer false positives because results are based on actual responses.

For QA: SAST findings inform security test cases (if the scanner found a potential SQL injection in module X, write a test for it). DAST output should be triaged and high-confidence findings filed as defects.

// WHAT INTERVIEWERS LOOK FOR

Articulates the code-vs-runtime distinction clearly. Knows SAST is for early feedback and DAST is for runtime validation. Can name a tool for each. Understands neither is sufficient alone.