How would you embed security governance into the SDLC rather than bolting it on at the end?
Short answer
Embed security at every SDLC phase rather than testing at the end: requirements include security and privacy requirements, design includes threat modeling, development follows secure coding standards with SAST, testing adds DAST and reviews, and release requires sign-off — all governed by policy, separation of duties, and change control. Fixing flaws early is dramatically cheaper than after release.
This question lives at the intersection of the software-development-security and governance domains. Interviewers want to see that you treat security as a managed lifecycle activity, not a one-time gate, and that you can frame it in business and process terms.
Security at every phase
Governance means a defined security activity and gate at each SDLC stage:
- Requirements — capture explicit security and privacy requirements alongside functional ones (authentication, data handling, regulatory needs).
- Design — perform threat modeling (e.g. STRIDE) to find architectural flaws before any code exists, when they are cheapest to fix.
- Development — enforce secure coding standards and run SAST in the pipeline.
- Testing — add DAST, dependency scanning, and security-focused code review.
- Deployment — require a security sign-off and verify hardened configuration.
- Operations / maintenance — patch, monitor, and feed findings back into requirements.
Why shift left pays
The economic argument is central: the cost of fixing a flaw rises sharply the later it is found. A design flaw caught in threat modeling costs a conversation; the same flaw caught in production may mean an incident, emergency patching, and reputational damage. "Shifting left" is governance optimizing cost and risk together.
Governance controls around the SDLC
Process discipline matters as much as tooling: separation of duties so the person who writes code does not unilaterally push it to production, change management so releases are reviewed and reversible, and configuration management so environments are known and consistent. These prevent both honest mistakes and malicious insertion.
What interviewers look for
A phase-by-phase mapping of security activities with threat modeling placed in design, the shift-left cost argument, and the governance wrappers — separation of duties, change and configuration management — that make secure development repeatable rather than dependent on individual heroics.
Likely follow-ups
- What is threat modeling and at which phase does it belong?
- Why does separation of duties matter between developers and production deployment?
- How do change management and configuration management support secure releases?