Secure Software Lifecycle Management
Make security repeatable
Secure lifecycle management turns security from a final review into a program. Be able to place each activity in the right phase: policy, roles, and training anywhere; risk classification and security requirements during initiation and requirements; threat modeling and architectural risk analysis in design; standards, code review, and static analysis in implementation; security testing in verification; hardening and release review in deployment; monitoring, patching, and disposal in operations and retirement.
Know the frameworks by purpose. Microsoft SDL is a phase-based set of practices with gates. OWASP SAMM and BSIMM are maturity models that measure and benchmark a program - they describe process health, not the security of a given product. DevSecOps automates security checks into CI/CD so feedback is continuous. Governance roles matter: a Software Security Group (SSG) sets direction and standards, while security champions are embedded developers extending the SSG into delivery teams. Supporting elements include secure coding standards, security awareness training, supplier and acquisition controls, metrics, and documented waivers with risk acceptance.
Traps
- 'Shift left' does not mean testing only early; it means starting early and keeping security in every phase.
- A gate that can be bypassed without documented, risk-accepted approval is not a gate.
- Maturity models measure process, not the security of any single product.
- Agile does not forbid security requirements or gates; it delivers them per increment.
Worked example
A team wants to skip threat modeling because it is agile. Correct answer: threat model each story or increment as it is designed, store the model with the code, and revise it when the architecture changes. The practice scales down; it does not disappear.