Code Review, SAST and DAST

What it is

Three complementary ways to find defects before exploit: SAST analyzes source statically for vulnerable patterns; DAST sends traffic to a running application to confirm exploitable behavior; human review reasons about high-risk logic and data flow.

Why it matters

Each technique has blind spots: SAST produces false positives but broad coverage; DAST validates real reachability but needs a live environment; review matches business risk. Layered coverage is measurably better than any single tool.

How it works

• SAST: parse + dataflow to flag injection, unsafe sinks, weak crypto (see security:cryptography), broken auth patterns.
• DAST: fuzz/scan endpoints for OWASP Top 10 classes on a review environment.
• Review: focus review on auth/authz, input parsing, deserialization, and dependencies (see security:authentication-authorization, security:http-sessions-cookies).

Detection

• SAST/DAST findings mapped to CWE; prioritize those touching authentication, object-reference and deserialization paths.
• A security review finding with a reachable exploit on a production route → treat as severity high.

Mitigation

• Run SAST/SCA on every PR; run DAST before merge; require human review of high-risk diffs (see security:devsecops).
• Triage by reachability + exploitability, not just tool severity.

Investigation

Validate a reported finding by reproducing the reachable path (DAST), reading the vulnerable source (SAST CWE), and confirming the affected version against CVE data (guides:tool-cve-guide).