What does a secure SDLC look like, and what security activities happen at each phase?
Short answer
A secure SDLC bakes security into every phase rather than bolting it on at the end. Requirements include security and abuse cases, design adds threat modeling, development uses secure coding and SAST plus dependency scanning, testing adds DAST and pen testing, and operations adds monitoring, patching, and incident response — shifting security left.
A secure Software Development Life Cycle integrates security as a continuous activity across the whole development process rather than a gate at the end. The core idea is shift left: the earlier a flaw is found, the cheaper and easier it is to fix — a design flaw caught on a whiteboard costs almost nothing; the same flaw found in production after a breach is enormously expensive.
Security at each phase
- Requirements: capture security and compliance requirements alongside functional ones, and write abuse cases — how might someone misuse this feature? — not just user stories.
- Design: perform threat modeling (e.g. STRIDE) to identify how the system could be attacked and design controls in. Architecture decisions like trust boundaries and authentication flows are cheapest to get right here.
- Development: follow secure coding standards, run SAST (static analysis) in the IDE and CI, and use SCA / dependency scanning to catch vulnerable third-party libraries — most modern apps are mostly other people's code.
- Testing / QA: add DAST (dynamic testing against the running app), fuzzing, and targeted penetration testing before release.
- Deployment: scan infrastructure-as-code and container images, manage secrets properly, and harden the runtime configuration.
- Operations / maintenance: continuous monitoring and logging, timely patching, and a tested incident response plan to handle what slips through. Findings feed back into requirements.
Making it work
Automate the checks into the CI/CD pipeline so security is fast feedback, not a manual bottleneck. Use risk-based gates — fail the build on critical findings, warn on lower ones — so security enables delivery instead of blocking it.
What interviewers look for
A senior answer maps specific activities to specific phases (threat modeling at design, SAST/SCA in dev, DAST/pen test in QA, monitoring in ops), explains why shifting left saves money, and shows awareness of integrating these into the pipeline without grinding delivery to a halt.
Likely follow-ups
- Why is fixing a vulnerability cheaper the earlier it's caught?
- What's the difference between SAST, DAST, and SCA?
- How do you integrate security gates without blocking the pipeline?