security-development-lifecyclelisted

# Security development lifecycle Microsoft's SDL exists because security defects found at release are the ones that were never designed against. The framework spreads specific obligations across the phases, from requirements to response, so each gate catches a class of flaw at the point where fixing it is cheap. Run it as a checklist at the end and it becomes paperwork; run it as gates and it changes what ships. ## Method 1. **Set the bug bar and security requirements up front.** Before design, define the SDL bug bar: the severity thresholds that block release, and which vulnerability classes are never acceptable. Add security and privacy requirements to the backlog as tracked, owned work, not aspirations. 2. **Threat model every design.** Draw the data flow diagram, mark trust boundaries, and walk STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) against each element. Use the Microsoft Threat Modeling Tool or equivalent, record a mitigation per threat, and make the threat model a gate no design review passes without. 3. **Constrain the toolchain in implementation.** Pin approved compiler and linker versions with hardening flags on (/GS, /DYNAMICBASE, control flow guard). Ban unsafe APIs (strcpy, sprintf, gets) with a checked banned-function list, and scan dependencies for known CVEs before they enter the build. 4. **Gate merges on static analysis.** Run SAST on every pull request and