Index · TL;DR

1 min read
20 min read
Rapid overview

TL;DR

Security is not a feature you add at the end — it is a property you build in at every phase of the software development lifecycle (SDLC), from design through build, deploy, and run. Bolting a scanner or a WAF on after the fact catches a fraction of the problems and none of the structural ones: a flaw in the design (a missing trust boundary, an absent rate limit on a money-moving endpoint, an authentication step that was never required) cannot be patched away with a code fix because there is no incorrect line of code to correct — the control was simply never specified. A secure SDLC threads concrete activities through each phase: threat modeling and abuse cases at design time (OWASP A04 Insecure Design); hardened, minimal, secrets-free configuration at deploy time (A05 Security Misconfiguration); dependency and SBOM scanning to keep known-vulnerable libraries out (A06 Vulnerable & Outdated Components); a tamper-evident, signed CI/CD pipeline so attackers can't inject malicious code into your build or updates (A08 Software & Data Integrity Failures); server-side request controls so a fetch you initiate can't be steered at internal metadata endpoints (A10 SSRF); and pervasive logging and monitoring so that when something does get through you can detect and respond (A09). The unifying idea is shift left — move security checks earlier and automate them in the pipeline — backed by secure defaults and defense in depth so that a single missed control is contained, not catastrophic.

See also