Static and Dynamic Analysis (SAST & DAST)
AZ-400 path: Implement security and validate code bases for compliance — “Validate code” module.
Overview
Covers the two classical code-level security testing techniques used to validate code in CI/CD: static analysis (SAST) that inspects source without executing, and dynamic analysis (DAST) that tests the running application. Both output findings that drive a compliance gate.
Learning objectives
- Distinguish SAST (source inspection, no runtime) from DAST (runtime, black-box).
- Choose the right tool/technique for a given vulnerability class.
- Wire analysis results into a build/release gate so critical findings block shipping.
Units
- What is static analysis (SAST) & what it catches
- What is dynamic analysis (DAST) & runtime-only flaws
- CI vs runtime placement (SAST at PR/build; DAST against deployed app)
- Turning findings into a quality/compliance gate
Concepts introduced
Key terms & commands
SAST · DAST · white-box vs black-box · CodeQL · SonarQube · OWASP ZAP · gate · code coverage
Hands-on
⚠ verify — add an exercise running a SAST tool (e.g. Pylint/Sonar) as a PR check and a gate that fails on critical findings.
Exam focus
- Memorize pairing: SAST = static/source/no-execution · DAST = dynamic/black-box/running app.
- Both feed an automated compliance gate; culprits: SAST→code-level, DAST→runtime/config/endpoint, SCA→dependencies/licenses (next module).
- Understand placement: SAST early (commit/PR), DAST where there’s a runnable env (test/staging).
Related
Path MOC · shift-left-security · dependency-scanning · compliance-and-secret-management