SAST / DAST

SAST and DAST are the two families of automated application security testing: the first analyzes the code from the inside (white box), the second attacks the running app from the outside (black box). They complement each other: neither alone finds everything.

SAST (Static Application Security Testing)

What      analyzes source/bytecode WITHOUT running it (white box)
Finds     injection, XSS, hardcoded secrets, insecure patterns, dangerous data flows
When      in the IDE, in the PR, and in CI (shift-left, fast feedback)
Limitation  doesn't see runtime/config flaws; generates FALSE POSITIVES (needs tuning)

DAST (Dynamic Application Security Testing)

What      attacks the RUNNING application from outside (black box), like an attacker
Finds     observable runtime flaws: config, auth, exploitable injection, headers
When      in staging/QA (and controlled in prod); slower, less code coverage
Limitation  doesn't see the code; coverage depends on being able to "walk" the whole app (crawl/auth)

IAST and comparison

IAST   instruments the app (agent) and observes during tests -> combines advantages
       fewer false positives, but requires instrumentation
SAST  white box, early, lots of code, more FP
DAST  black box, late, real runtime, fewer FP but less coverage
-> use BOTH + SCA (dso-deps) + secrets (dso-secrets) in the pipeline

Tools

SAST   Semgrep (rules, fast), CodeQL (powerful queries), SonarQube, Bandit (py), gosec
DAST   OWASP ZAP (open-source), Burp Suite (see tool-burp), Nuclei (see tool-nuclei)
IAST   commercial agents (Contrast, etc.)

Integration and tuning

- SAST in the PR: diff only (new code) so you don't drown in historical debt
- custom rules (Semgrep) for the organization's own patterns
- false-positive triage; mark and suppress with justification and expiry
- authenticated DAST (with test credentials) to cover areas behind login

Blue Team / AppSec

SAST early (IDE/PR) + DAST in staging + IAST where it helps; never a single technique.
Tune false positives aggressively: a noisy SAST ends up ignored.
Custom rules (Semgrep/CodeQL) for the code’s specific risk patterns.
Integrate with SCA (Dependencies & SCA) and secrets (Secrets management) as part of the CI gate (CI/CD security).

CVEs and real-world cases

CodeQL has found entire vulnerability classes (variant analysis) in large open-source projects.
Semgrep is standard for secure-coding rules in pipelines due to its speed and low FP.
Runtime/config flaws SAST doesn’t see (headers, auth) are what DAST catches in staging.

Testing checklist

SAST in IDE/PR (diff) and in CI with a gate
Custom rules (Semgrep/CodeQL) for own patterns
DAST in staging, authenticated to cover behind login
IAST where instrumentation helps
Triage and suppress false positives with expiry
Combine with SCA (Dependencies & SCA) and secrets (Secrets management)
Results in the PR (feedback) and posture dashboard