Security in Agile, Waterfall and DevOps Methodologies

1. Why This Topic Is Important

Software is never built in a vacuum. Every organization follows some development methodology, whether it is a rigid, phase-based Waterfall approach, an iterative Agile approach, or a highly automated DevOps pipeline. The CSSLP exam tests whether you understand that security must be adapted to the methodology in use, not bolted on at the end regardless of how the team works. A security professional who insists on a six-week penetration test before every release will fail in a DevOps shop that deploys ten times a day. Likewise, a team that only runs automated scans but never performs threat modeling or requirements analysis will miss design-level flaws no matter how fast they move.

ISC2 places this topic within Domain 2, Secure Software Lifecycle Management, because the domain is about integrating security into the way software is actually planned, built, tested, released and maintained. Exam questions frequently describe a scenario (for example, 'a team uses two-week sprints' or 'releases are pushed through an automated pipeline') and then ask which security activity, control, role or artifact is MOST appropriate. If you cannot recognize the methodology and its implications, you cannot select the best answer.

Key reasons the topic matters in practice:
- The cost of fixing a defect rises dramatically the later it is found; each methodology provides different opportunities to find defects early ('shift left').
- Regulatory and audit requirements (PCI DSS, HIPAA, ISO 27001, FedRAMP) demand evidence that security was addressed throughout the lifecycle, and the evidence looks different in each methodology.
- Speed vs. assurance is the central tension of modern development; the security professional must find ways to deliver assurance without becoming a bottleneck.

2. What It Is: Overview of the Three Methodologies

Waterfall is a sequential, plan-driven model. Phases typically include Requirements, Design, Implementation (coding), Verification (testing), and Maintenance. Each phase is completed and formally signed off before the next begins. Documentation is heavy, scope is fixed early, and change is managed through formal change control. Waterfall is still common in regulated industries, safety-critical systems, government contracts, and embedded or hardware-dependent projects.

Agile is an iterative, incremental, value-driven approach described by the Agile Manifesto (individuals and interactions, working software, customer collaboration, responding to change). Work is organized into short timeboxes called sprints or iterations (usually one to four weeks). Requirements are captured as user stories in a prioritized product backlog. Common frameworks include Scrum (roles: Product Owner, Scrum Master, Development Team; events: Sprint Planning, Daily Stand-up, Sprint Review, Retrospective), Kanban (continuous flow, work-in-progress limits), Extreme Programming (pair programming, test-driven development) and scaled frameworks such as SAFe.

DevOps is a culture and set of practices that unify software development (Dev) and IT operations (Ops) to shorten the delivery cycle through automation, collaboration and continuous feedback. Its technical backbone is the CI/CD pipeline: Continuous Integration (frequent merges with automated builds and tests), Continuous Delivery (every build is release-ready) and Continuous Deployment (every passing build is automatically pushed to production). Infrastructure is defined as code (IaC), environments are reproducible, and monitoring feeds back into development. DevSecOps is the extension of DevOps in which security is treated as a shared responsibility and embedded into every stage of the pipeline, largely through automation ('security as code').

3. How Security Works in Waterfall

Because Waterfall is gate-driven, security is integrated through security gates and deliverables at each phase. This maps very naturally to classic Secure SDLC models such as Microsoft SDL, NIST SP 800-64 (now superseded but conceptually relevant) and NIST SSDF (SP 800-218).

- Requirements phase: gather security requirements alongside functional ones; perform data classification, privacy impact assessment, identify compliance drivers, define misuse and abuse cases, establish the risk acceptance baseline.
- Design phase: threat modeling (STRIDE, PASTA, attack trees), architectural risk analysis, selection of security design patterns and principles (least privilege, defense in depth, fail secure, complete mediation), security design review and sign-off.
- Implementation phase: secure coding standards, static analysis (SAST), peer code review, approved cryptographic libraries, banned functions lists.
- Verification phase: dynamic analysis (DAST), penetration testing, fuzzing, security regression testing, verification that every security requirement has a test case (requirements traceability matrix).
- Release and Maintenance: final security review, residual risk sign-off, secure configuration and deployment documentation, incident response plan, patch management and vulnerability disclosure processes.

Strengths for security: clear checkpoints, strong documentation and audit trail, full requirements known up front make threat modeling complete, well suited to formal certification and accreditation (for example Common Criteria, FIPS 140, authority to operate).

Weaknesses for security: security testing happens late, so flaws are expensive to fix; long cycles mean the threat landscape may change before release; change control can make urgent security fixes slow; heavy documentation can become 'paperwork security' rather than real assurance.

4. How Security Works in Agile

Agile does not have natural phase gates, so security must be woven into the backlog, the sprint cadence and the team culture. The guiding idea is that security is a quality attribute of every increment, not a separate phase.

Key practices:
- Security user stories ('As a user, I want my session to expire after 15 minutes of inactivity so that an unattended device cannot be abused') and evil user stories / abuse cases ('As an attacker, I want to enumerate valid usernames via the login error message') placed in the backlog and prioritized by the Product Owner with security input.
- Security acceptance criteria attached to functional stories so a story is not accepted until, for example, input validation and authorization checks are present.
- Definition of Done (DoD) extended to include security: SAST clean of high findings, peer review completed, dependency scan passed, security unit tests written.
- Incremental threat modeling: rather than one large design document, threat model each new feature or architecturally significant story during sprint planning or backlog refinement; maintain a living threat model.
- Security champion role: a developer on the team who receives extra training and acts as the liaison with the central security team; scales security expertise without a bottleneck.
- Security spikes (time-boxed research tasks) and hardening sprints used sparingly to address accumulated security debt; the preferred approach is to avoid debt by handling security every sprint.
- Automated security testing in the sprint (SAST, SCA, security-focused unit tests) so feedback arrives within the iteration.
- Retrospectives used to review security incidents and near misses and to improve the process.
- Microsoft SDL for Agile classifies requirements as every-sprint (for example threat model new features, run static analysis), bucket (rotated activities completed over several sprints, such as fuzzing or privacy review) and one-time (performed once per project, such as establishing a security response plan).

Strengths for security: early and frequent feedback, small changes are easier to review, vulnerabilities can be fixed in the next sprint, close collaboration with the customer clarifies security needs.

Weaknesses for security: minimal documentation can hurt compliance evidence; emergent design can make architectural security hard to reason about; security stories may be deprioritized in favor of visible features; the Product Owner may lack security expertise; frequent change can invalidate earlier threat models.

5. How Security Works in DevOps (DevSecOps)

In DevOps, releases may happen many times per day, so manual, point-in-time security reviews cannot keep pace. The answer is automation, shift-left, and shared responsibility. The phrase 'security as code' captures the goal: policies, tests and configurations are expressed as code, version controlled and enforced automatically by the pipeline.

Security controls mapped to the pipeline:
- Plan: threat modeling, security requirements, risk-based prioritization; security included in planning meetings.
- Code: IDE security plugins, pre-commit hooks, secrets detection, secure coding standards, mandatory peer review via pull requests, signed commits.
- Build (CI): SAST, Software Composition Analysis (SCA) for third-party and open-source dependencies, license compliance, generation of a Software Bill of Materials (SBOM), build integrity checks.
- Test: DAST, Interactive Application Security Testing (IAST), security unit and integration tests, fuzzing, container image scanning, Infrastructure as Code scanning (for example Terraform or CloudFormation misconfigurations).
- Release: artifact signing, policy-as-code gates (deployment blocked if critical vulnerabilities exist), approval workflows for high-risk changes, secure artifact repositories.
- Deploy: immutable infrastructure, hardened base images, secrets management (vaults rather than hard-coded credentials), configuration management, blue-green or canary deployments to limit blast radius.
- Operate: runtime protection (RASP, WAF), least-privilege service identities, patching through redeployment rather than manual changes.
- Monitor: centralized logging, security telemetry, anomaly detection, feedback of production vulnerabilities and incidents into the backlog ('shift right' complements 'shift left').

Cultural and governance elements:
- Shared responsibility: developers, operations and security are jointly accountable; security is 'everyone's job' with the security team acting as enablers and toolsmiths.
- Separation of duties is achieved through pipeline controls (automated approvals, role-based access to the pipeline, audit logs) rather than through separate people performing manual deployments.
- Fail fast, fix fast: breaking the build on security failures is acceptable if the feedback is immediate and actionable; excessive false positives destroy developer trust, so tools must be tuned.
- Continuous compliance: evidence is generated automatically by the pipeline (scan results, approvals, SBOMs) and retained for auditors.
- Secure the pipeline itself: the CI/CD system is a high-value target (supply chain attacks such as SolarWinds); protect build servers, restrict who can modify pipeline definitions, verify dependencies and tool integrity, use frameworks such as SLSA.

Strengths for security: every change is tested consistently, vulnerabilities are detected in minutes, patches reach production quickly, configuration drift is eliminated, excellent traceability.

Weaknesses for security: automation cannot find design flaws or business logic abuses, so threat modeling and manual review are still needed; tool sprawl and false positives; misconfigured pipelines can deploy vulnerabilities at scale; the pipeline becomes a single point of compromise if not secured.

6. Side-by-Side Comparison

Cadence: Waterfall = months to years per release; Agile = weeks per increment; DevOps = hours or minutes per deployment.
Where security lives: Waterfall = phase gates and deliverables; Agile = backlog, DoD, every sprint; DevOps = automated pipeline stages and culture.
Primary security artifacts: Waterfall = security requirements document, threat model report, test plans, sign-offs; Agile = security stories, abuse cases, acceptance criteria, living threat model; DevOps = pipeline-as-code, policy-as-code, scan reports, SBOM, telemetry.
Threat modeling style: Waterfall = comprehensive, once during design; Agile = incremental per feature; DevOps = incremental plus automated architecture checks.
Testing approach: Waterfall = manual and tool-based during verification phase; Agile = automated in-sprint with periodic manual testing; DevOps = fully automated in pipeline with runtime monitoring.
Compliance evidence: Waterfall = documents and signatures; Agile = backlog history, sprint artifacts, test results; DevOps = immutable pipeline logs and automated reports.
Biggest risk: Waterfall = late discovery, slow fixes; Agile = security deprioritized, thin documentation; DevOps = insecure automation at scale, pipeline compromise.

7. Common Principles Across All Methodologies

Regardless of method, the CSSLP expects you to know these constants:
- Shift left: find and fix issues as early as possible.
- Risk-based approach: depth of security activity should match the risk and criticality of the component.
- Security requirements must be explicit and traceable to tests.
- Threat modeling is methodology-independent and remains the primary way to find design flaws.
- Defense in depth and secure defaults apply to the application and to the pipeline and infrastructure.
- Metrics (defect density, mean time to remediate, percentage of stories with security criteria, scan coverage) demonstrate the effectiveness of the program.
- Training and culture matter more than any single tool.
- Residual risk must be formally accepted by an appropriate business owner, not by the development team alone.

8. Exam Tips: Answering Questions on Security in Agile, Waterfall and DevOps Methodologies

Tip 1 - Identify the methodology from clues. Words such as 'phase', 'gate', 'sign-off', 'requirements baseline', 'change control board' signal Waterfall. 'Sprint', 'backlog', 'user story', 'Product Owner', 'retrospective', 'iteration' signal Agile. 'Pipeline', 'CI/CD', 'continuous', 'infrastructure as code', 'deploy multiple times per day', 'automation' signal DevOps. Once you know the methodology, eliminate answers that do not fit its cadence.

Tip 2 - Match the control to the cadence. If the scenario releases daily, a manual quarterly penetration test is not the BEST answer; automated SAST/DAST/SCA in the pipeline is. If the scenario is a two-week sprint, 'add security acceptance criteria to the Definition of Done' or 'threat model the new feature during sprint planning' beats 'conduct a full security review before the final release'. If the scenario is a Waterfall government project, 'formal security design review and sign-off before implementation begins' is appropriate.

Tip 3 - Prefer integration over isolation. ISC2 consistently favors answers that embed security into the team's existing process (security stories, security champions, pipeline gates) over answers that create a separate security phase, separate security team gatekeeping, or 'security sprint at the end'. A hardening sprint is a remediation tactic, not a preferred strategy.

Tip 4 - Automation does not replace thinking. When a DevOps question asks what automated tools CANNOT do, the answer involves design flaws, business logic vulnerabilities and architecture issues, which require threat modeling and manual review. When a question asks what is MOST effective for finding design flaws early, the answer is threat modeling, not scanning.

Tip 5 - Know the Agile security vocabulary. Be ready to define evil/abuse user stories, security acceptance criteria, Definition of Done, security champion, security spike, bucket requirements (Microsoft SDL for Agile), and incremental threat modeling. Questions often ask 'which artifact' or 'which role' is responsible.

Tip 6 - Know the DevSecOps vocabulary. Be ready to place SAST (build stage, source code), DAST (test stage, running application), IAST (instrumented runtime testing), SCA (third-party components, SBOM), container and IaC scanning, secrets management, artifact signing, policy as code, RASP and continuous monitoring in the correct pipeline stage. Remember that the pipeline itself must be secured and that separation of duties can be enforced by automation and access controls.

Tip 7 - Watch for the 'documentation vs. compliance' angle. If the question involves an audit, regulation or certification in an Agile or DevOps environment, the BEST answer usually involves generating evidence automatically or capturing it in backlog and pipeline artifacts, not reverting to Waterfall or writing documents after the fact.

Tip 8 - Risk acceptance is a business decision. If a question asks who should accept residual risk when a sprint ends with an open security issue, the answer is the business or product owner with appropriate authority (often with security advising), not the developer, the Scrum Master or the tester.

Tip 9 - Look for the word that changes everything. MOST, BEST, FIRST, PRIMARY and LEAST are decisive. 'FIRST' in an Agile scenario often points to adding security to requirements or the backlog; 'BEST' in a DevOps scenario often points to automating a control in the pipeline; 'PRIMARY' benefit of DevSecOps is usually early, continuous detection and faster remediation, not cost savings.

Tip 10 - Eliminate extreme or impractical answers. Answers that halt all development, require security approval of every commit by a human, or remove automation to improve security are almost always wrong. Answers that remove security entirely in favor of speed are also wrong. The exam rewards balanced, risk-based, integrated answers.

Tip 11 - Think like a manager and a practitioner. CSSLP questions are written from the perspective of a security professional advising a development organization. Choose answers that improve the process sustainably (training, culture, repeatable controls) over one-off heroics.

9. Practice Scenarios to Rehearse

Scenario A: A Scrum team repeatedly ships features without security review because the Product Owner prioritizes customer-visible functionality. Best response: Work with the Product Owner to add security acceptance criteria to the Definition of Done and introduce abuse cases into backlog refinement, supported by a security champion on the team.

Scenario B: An organization deploys to production 30 times a day and wants assurance that no known vulnerable libraries reach production. Best response: Integrate Software Composition Analysis into the CI pipeline with a policy gate that fails the build on critical findings, and generate an SBOM for each release.

Scenario C: A defense contractor follows Waterfall and must obtain authority to operate. Best response: Define security requirements in the requirements phase, perform formal threat modeling and design review before coding, and maintain a traceability matrix linking requirements to verification tests.

Scenario D: A DevSecOps pipeline has all scans passing, yet an attacker exploits a flaw allowing users to approve their own purchase orders. Lesson: Automated tools miss business logic and authorization design flaws; threat modeling and manual review remain essential.

Scenario E: A team wants to introduce SAST but developers complain about hundreds of false positives. Best response: Tune the tool, start with high-confidence rules, integrate results into the developer workflow, and expand gradually; do not abandon the control or ignore the findings.

10. Key Takeaways

- Security must be adapted to the methodology: gates in Waterfall, backlog and Definition of Done in Agile, automated pipeline and culture in DevOps.
- Shift left, risk-based prioritization, explicit security requirements and threat modeling are constants across all approaches.
- Agile security relies on security stories, abuse cases, acceptance criteria, security champions and incremental threat modeling.
- DevSecOps relies on security as code, SAST/DAST/IAST/SCA automation, secrets management, artifact signing, continuous monitoring and securing the pipeline itself.
- Waterfall security relies on phase deliverables, formal reviews, traceability and sign-offs, and is well suited to regulated and safety-critical environments.
- On the exam, identify the methodology, match the control to the cadence, favor integrated and automated approaches where appropriate, remember that tools cannot replace threat modeling, and ensure residual risk is accepted by the business.