Static vs Dynamic Analysis

SAST vs DAST. Different findings.

SAST: static analysis

SAST analyses source code without running it. Fast feedback in CI catches code-level issues before merge: hardcoded credentials, unsafe deserialisation, SQL-injection patterns, common security anti-patterns.

• Source-code analysis without execution. PR-time static scan. Catches code-level vulnerabilities and bug classes.
• Run in CI on every PR. Gating scan. Fast feedback before merge.
• Tooling options. Semgrep, SonarQube, Snyk Code, GitHub CodeQL. Different strengths per language.
• Per-rule false-positive tuning. Per-repo allowlist. Catches alert fatigue before it disables the gate.

DAST: dynamic analysis

DAST analyses the deployed application from outside. Slower than SAST; finds issues that only exist at runtime: misconfigured CORS, exposed admin endpoints, runtime-only injection vectors.

• Runtime analysis on deployed app. Per-release scan. Catches runtime-only vulnerabilities and configuration mistakes.
• Run in pre-prod per release. Gating scan. Slower; deployed environment required.
• Tooling options. OWASP ZAP, Burp Suite, vendor scanners. Crawls the application from outside.
• Auth-aware crawl. Authenticated crawl coverage per scan. Issues behind login otherwise stay invisible.

They complement each other

SAST and DAST catch different classes of issues. Mature security programs run both because each misses what the other finds. Treating them as substitutes leaves coverage gaps.

• SAST catches code-level issues. Hardcoded credentials, unsafe deserialisation, injection patterns.
• DAST catches deployment-level issues. Misconfigured CORS, exposed admin endpoints, runtime-only vulnerabilities.
• Each misses what the other catches. Both-or-nothing reality. Mature programs run both.
• Documented coverage map. Issue-class to tool mapping per program. Catches coverage gaps explicitly.

Operating both

Running both tools is its own discipline. SAST gates merges; DAST gates releases; quarterly tuning keeps false-positive rates manageable; named tool owners prevent the “everyone’s-and-no-one’s” rot.

• SAST in CI. SAST gate per PR. Blocks merge on critical findings.
• DAST per release in pre-prod. Release gate. Blocks deploy on critical findings.
• Quarterly review. False-positive rates, missed cases, tooling gaps audited. Drives tuning.
• Named owner per tool. Maintaining team explicit. Tooling stops rotting silently.