What does a secure SDLC look like?
Short answer
A secure SDLC embeds security into every phase rather than testing at the end: requirements (security and abuse cases), design (threat modeling), implementation (secure coding standards, SAST/SCA in the IDE and CI), testing (DAST, pentest), release (gates and sign-off), and operations (monitoring, patching, feedback). Shift-left moves defects earlier where they're cheap to fix; maturity models like OWASP SAMM and BSIMM measure how well you actually do it.
A secure SDLC means security is a property of how you build software, not a scan you run the week before launch. Interviewers ask about it to gauge whether you can operationalize "shift-left" — moving defect discovery earlier, where a fix costs a code comment instead of an incident.
Security in each phase
- Requirements. Capture security requirements and abuse cases alongside features — "what should this never allow" is as important as "what should this do."
- Design. Threat model the architecture and choose secure patterns before any code exists. The cheapest bug to fix is the one never built.
- Implementation. Secure coding standards, plus automated SAST and SCA (dependency/software-composition) running in the IDE and on every pull request so feedback is immediate.
- Testing. DAST, fuzzing, and targeted manual penetration testing against running builds.
- Release. Security gates and sign-off — but risk-tuned, so a low-severity informational finding does not block a deploy while a critical does.
- Operations. Runtime monitoring, patching, secrets and configuration hygiene, and feeding incidents back into requirements and threat models.
Why shift-left works
The cost of fixing a defect rises sharply the later it is found. Catching an injection flaw in a pull-request SAST check costs minutes; catching it as a breach costs disclosure, downtime, and trust. Shift-left simply moves the discovery point to where remediation is cheap.
Measuring maturity
You manage what you measure. OWASP SAMM is a prescriptive, self-assessable maturity model across governance, design, implementation, verification, and operations. BSIMM is descriptive — it reports what real firms actually do, so you can benchmark against peers.
What interviewers look for
They want concrete touchpoints per phase, the right tool in the right place (SAST early, DAST on running apps, SCA for dependencies), gates that are risk-tuned rather than blanket blockers, and awareness that a maturity model turns "we care about security" into something measurable.
Likely follow-ups
- What's the difference between SAST, DAST, and SCA, and where does each fit?
- How do OWASP SAMM and BSIMM differ in purpose?
- How do you add a security gate to CI without blocking every deploy?