A county is building a new benefits-enrollment application. Leadership proposes a single security review one week before go-live. What SDLC practice should security advocate instead?

Secure software development life-cycle practice places security gates and activities in each phase—from requirements and design through implementation, testing, deployment, and maintenance—rather than concentrating review in a single pre-go-live week. For a county benefits-enrollment application, that means threat modeling and security requirements early, design reviews for authN/Z and data protection, secure coding and dependency checks during build, security testing before release, and ongoing patch/monitoring after launch. Late-only review finds some defects but systematically misses requirements and architecture flaws that are expensive or impossible to fix at the ribbon-cutting.

Skipping design reviews because “testing at the end always finds every flaw” overestimates test coverage and ignores design-level weaknesses. Deferring all threat modeling until after public launch metrics arrive postpones risk analysis until real residents’ data are already exposed. Treating security as paperwork sign-off that never touches requirements or code produces compliance theater without reducing vulnerability.

Exam caveat: integrating security throughout the SDLC is a core software-development security theme. Phase-appropriate activities matter more than a single gate. Maintenance is part of the life cycle—security does not end at go-live.

Operational check: map mandatory security activities to each SDLC phase in the county’s development standard, require evidence at stage exits for benefits systems handling PII, and reject go-live packages that only show a last-week checklist with no earlier artifacts.