Security isn’t a final audit — it’s built in throughout. Bake threat modeling, automated testing, and dependency scanning into the pipeline so flaws are caught before release.
Why: finding a vulnerability in design costs far less than finding it in production, so security is woven through the whole lifecycle — threat model in design, secure coding and review in development, automated testing in CI, monitoring in production. When: build security into every phase rather than bolting on a pentest at the end. Where: this is the difference between preventing flaws and discovering them after a breach.
DESIGN threat model (STRIDE) — what can go wrong, what we'll do about it
│
DEVELOP secure coding, code review, secrets scanning
│
BUILD/CI SAST (code) + SCA (dependencies) + DAST (running app) -> gate release
│
DEPLOY hardened config, least privilege, TLS
│
OPERATE logging, detection, incident response (SIEM / DFIR courses)
Cheapest to fix on the left; most expensive (a breach) on the right.Why: manual review does not scale, so automated tools run on every change — SAST reads your source for risky patterns, SCA checks dependencies for known CVEs, and DAST attacks the running app — catching regressions before they ship. When: gate the pipeline on these; a new high-severity finding fails the build. Where: they complement each other (code, dependencies, runtime), so use all three.
# A security gate in the CI pipeline (fail the build on high-severity findings):
semgrep --config auto --error # SAST — static analysis of your code
npm audit --audit-level=high # SCA — known CVEs in dependencies
# DAST — attack the running app (OWASP ZAP baseline scan):
zap-baseline.py -t https://staging.example.com -I
# Same idea as the eval/quality gates in other tracks: block regressions
# automatically, before they reach production.Why: the OWASP Top 10 is the industry’s consensus list of the most critical web risks, and this course walked the practical core of it — knowing the categories lets you reason about coverage and talk to other engineers. When: use it as a checklist during design and review. Where: it evolves, so treat it as a living reference, not a one-time exam.
OWASP Top 10 (2021) — the categories to design and review against:
A01 Broken Access Control A06 Vulnerable/Outdated Components
A02 Cryptographic Failures A07 Identification & Auth Failures
A03 Injection (SQLi, XSS, cmd) A08 Software & Data Integrity Failures
A04 Insecure Design A09 Security Logging & Monitoring Failures
A05 Security Misconfiguration A10 Server-Side Request Forgery (SSRF)
Prevent in code, verify in CI, detect in production. Security is a process.