Waterfall, Agile, DevOps: Where Security Fits In Each Development Model

🎯 CISSP Lens

Pick answers that align business risk, governance intent, and practical control execution.

A development model describes how you move from idea to working software. Security has to plug into this flow instead of fighting it.

Classic models

Waterfall

• Linear phases: requirements, design, implementation, testing, deployment, maintenance.
• Heavy documentation and formal reviews.
• Security fits naturally as review gates at the end of phases.

Typical security activities:

• Security requirements review at the end of requirements.
• Threat modeling and architecture review at the end of design.
• Secure coding standards and code review during implementation.
• Formal security testing and risk signoff before deployment.

V model

• Extends waterfall by tying each development phase to a matching test phase.
• Security requirements map to security test cases.
• Strong fit for regulated environments that require traceability.

Spiral and iterative models

• Cycles of planning, risk analysis, engineering, and evaluation.
• Security risk assessment is built into each iteration.

Modern approaches

Agile (Scrum, Kanban)

• Short iterations, evolving requirements, lightweight documentation.
• Security must be incremental and repeatable at the sprint level.

Security activities in agile:

• Include security stories or acceptance criteria in the backlog.
• Do quick threat discussions during refinement for risky items.
• Add security tests to the definition of done where appropriate.
• Allocate capacity each sprint for security debt and fixes.

DevOps

• Continuous integration and delivery, strong automation, shared responsibility.
• Changes are small and frequent.

Security in DevOps focuses on:

• Automating checks such as SAST, SCA, container scanning, and secrets scanning in pipelines.
• Treating infrastructure and configuration as code, so they can be reviewed and controlled.
• Using monitoring and metrics to feed information back into development decisions.

DevSecOps is simply DevOps where security is explicitly integrated into tooling and culture.

Hybrid realities

Most enterprises do not run only one pure model. You might see waterfall gating for big programs, agile inside product teams, and DevOps for a few services.

Your job is to:

• Identify which model each team actually uses.
• Map security expectations to that model.
• Avoid forcing waterfall style controls onto high speed teams without adaptation.

📋 Domain cross-reference

📋 Domain cross-reference

For the exam, you need to recognize from a scenario which development model is in play, then choose security activities that align with it.

Look for these cues:

• Long phases, detailed documents, formal signoffs. Think waterfall or V model.
• Sprints, standups, product backlog. Think agile.
• Continuous deployment, pipelines, infrastructure as code. Think DevOps or DevSecOps.

Preferred answers usually:

• Place security early in each model, not only at testing.
• Use reviews and documentation in structured models.
• Use automation, lightweight artifacts, and in sprint work in agile and DevOps.
• Respect regulatory and audit needs where documentation and traceability matter.

A large enterprise has a core billing system developed with a waterfall model and a customer portal run by an agile team. Security had one standard process: a long design document and a formal review board before coding.

The agile portal team struggled. Their sprints were blocked waiting for security meetings. As deadlines loomed, they bypassed the process, which led to design gaps and late findings.

The security manager reworked the approach:

• The billing system kept detailed design documents and quarterly review boards. This matched its slower release cycle and regulatory needs.
• The portal team shifted to short, template based design notes and in sprint security reviews.
• Security created checklists for sprint planning and story refinement.
• Automated SAST and dependency scanning were added to the portal pipeline, with clear triage rules.

Both teams now met the same security objectives, but the controls fit their delivery style.

⚠️ Watch for this mistake: Forcing one SDLC model and one security process on every team regardless of context.

⚠️ Watch for this mistake: Assuming agile means no documentation or design and skipping key security decisions.

⚠️ Watch for this mistake: Treating DevOps as only speed and not adding any security automation.

⚠️ Watch for this mistake: Ignoring compliance obligations when moving from waterfall to agile.

⚠️ Watch for this mistake: Letting security follow an old waterfall model while engineering has moved to agile and DevOps.

• ✅ ✅ Inventory critical applications and note which development model each uses today.
• ✅ ✅ For each model, list at least three security activities that fit naturally into its phases or ceremonies.
• ✅ ✅ For waterfall or V model systems, ensure you have defined security review gates and traceability from requirements to tests.
• ✅ ✅ For agile teams, add security questions to refinement and definition of done, and dedicate recurring time to security work.
• ✅ ✅ For DevOps teams, integrate at least one automated security check into CI and define ownership for findings.
• ✅ ✅ Align documentation expectations with both regulatory needs and team capacity.
• ✅ ✅ Educate security staff on agile and DevOps concepts so their recommendations are realistic.

• 💡 💡 Development models define the rhythm of software work, and security has to fit that rhythm.
• 💡 💡 Waterfall like models favor formal reviews and documentation, while agile and DevOps rely more on collaboration and automation.
• 💡 💡 There is no single best model, but there are better and worse ways to integrate security into each.
• 💡 💡 The CISSP exam rewards answers that align security with the stated development model.
• 💡 💡 In real organizations you will see hybrids, so focus on principles, not labels.

📝 Exam practice

📝 Exam practice

In a Scrum based project with two week sprints, when should security requirements be captured and reviewed.

Short answer: Security requirements should be considered continuously, with initial capture during backlog creation and refinement, and specific details discussed during sprint planning. Security work is then implemented and tested within the sprint so it becomes part of the normal delivery flow, not a separate phase.