Security development lifecycle

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 fail the build on bug-bar findings rather than posting a warning someone can ignore. Route open-source components through software composition analysis with a license and vulnerability policy.
5. Fuzz and dynamic-test at verification. Point a fuzzer at every parser and network-facing input, run DAST against the running service, and do an attack surface review: confirm what shipped matches the threat model and that no debug endpoint or default credential leaked in.
6. Pass the Final Security Review before release. A security advisor outside the team confirms every bug-bar issue is closed, the threat model matches the build, and an incident response plan with named contacts exists. Record the FSR outcome (passed, passed with exceptions, or escalate) and archive the evidence.
7. Keep the response loop open after release. Maintain the security contact and a triage path for externally reported vulnerabilities. A CVE against a shipped version reopens the lifecycle for that component.

Checks

• Does every design in this release carry a threat model with a mitigation recorded for each STRIDE threat?
• Would the build actually fail on a bug-bar SAST finding, or only warn?
• Can you produce the FSR sign-off and archived scans for the last release without reconstructing them after the fact?

Boundaries

SDL is Microsoft's framework and its phase names and bug bar are conventions: map them onto your own SDLC and compliance regime (SOC 2, ISO 27001) rather than importing the vocabulary wholesale. It sets process, not the fixes themselves, so the actual vulnerability review belongs to a security-review skill, and a novel design risk still needs a security engineer's judgment.