Security in the SDLC
Security across the SDLC and the cost-of-correction curve
A flaw caused by a missing security requirement is cheapest to fix while it is still a sentence in a requirements document and most expensive once it ships, which is the whole reason CISSP treats security as a property engineered into every phase rather than a test bolted on at the end. The Software Development Life Cycle (SDLC) is the structured progression a system moves through from idea to retirement; NIST defines it simply as "a formal or informal methodology for designing, creating, and maintaining software" (NIST SP 800-218[1]). The CISSP mental model for the whole domain is one sentence: security is a property engineered into every phase, never a test you run at the end. That framing is shared with the systems-engineering world. ISO/IEC/IEEE 15288 and NIST SP 800-160 Vol. 1, Engineering Trustworthy Secure Systems[2], treat security as built in across the life cycle rather than added on, and the software side inherits it.
The phases and the security activity in each
The diagram below walks the classic phase sequence (drawn from the now-superseded but still-canonical NIST SDLC model) from requirements through disposal, pairing each phase with the security work it owns; the table restates the same pairing for reference:
| Phase | Security activity it owns |
|---|---|
| Requirements / initiation | Security and privacy requirements, abuse/misuse cases, an initial risk and data-classification view |
| Design | Threat modeling, secure-design review, choosing controls and a security architecture |
| Implementation / coding | Secure coding standards, code review, static analysis (SAST) |
| Testing / verification | Security testing, dynamic analysis (DAST), penetration testing, validating the requirements |
| Deployment / transition | Secure configuration, hardening, a security acceptance gate |
| Operation and maintenance | Patching, monitoring, re-assessment after change, configuration management |
| Disposal | Secure decommissioning: sanitize media, revoke identities and trust, update inventory |
The point is not to memorize one vendor's phase names (different models split or merge phases) but to internalize that each phase has a distinct security deliverable, so a gap in any phase becomes a vulnerability downstream.
Why early beats late: the cost-of-correction curve
A flaw caused by a missing or wrong security requirement is cheapest to fix while it is still a sentence in a requirements document, and progressively more expensive through design, code, test, and production, because a late fix forces rework of everything built on top of the mistake plus a re-release, whereas an early fix edits one requirement. This is the economic argument behind shifting security left: move requirements, threat modeling, and testing earlier in the timeline so defects surface when they are cheap. It is also why CISSP prefers building security in (proactive, designed-in controls) over penetrate-and-patch (ship, get attacked, fix), which pays the highest point on the cost curve every time. NIST captures the same idea: "few SDLC models explicitly address software security in detail, so practices like those in the SSDF need to be added to and integrated with each SDLC implementation" (NIST SSDF, SP 800-218[3]).
Methodologies, maturity models, and the teams that run them
This section covers the moving parts a question tests by name: the development methodologies, where security fits each, the maturity models used to benchmark a program, and the staffing/change models that sustain it. It builds directly on the prior section's phases: a methodology is just a way of sequencing and repeating those phases.
Development methodologies and where security sits
- Waterfall runs the phases once, in strict sequence, each finishing before the next begins. It suits stable, well-understood requirements (regulated, fixed-scope work). Its security weakness: a flaw found late is very costly to retrofit, exactly the high end of the cost curve.
- Agile delivers in short, repeated iterations (sprints), reworking requirements as feedback arrives. Security must be in every sprint's definition of done (security stories, per-sprint review) or it slips between iterations.
- DevOps fuses development and operations into a continuous integration / continuous delivery (CI/CD) pipeline, releasing frequently. DevSecOps is the security-integrated variant: security becomes automated, continuous gates inside that pipeline (dependency scanning, SAST/DAST, policy checks) so a fast release cadence does not outrun security.
The unifying rule from the overview: the methodology sets the cadence; security practices adapt to it. NIST's Secure Software Development Framework (SSDF, SP 800-218[3]) is deliberately methodology-agnostic for this reason: its four practice groups (Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV)) are meant to be integrated into whatever model a team already uses, not to replace it.
Maturity models: rating the discipline of the process
A maturity model rates how disciplined and repeatable a process is on an ordinal scale, so an organization can benchmark and plan improvement. Two families matter for CISSP:
The Software Engineering Institute's original Capability Maturity Model (SW-CMM) defines five levels, climbing from chaos to continuous improvement:
- Initial: ad-hoc, unpredictable, success depends on individual heroics.
- Repeatable: basic project management; successes can be repeated on similar projects.
- Defined: processes are documented and standardized organization-wide.
- Managed: processes are measured quantitatively and controlled with metrics.
- Optimizing: the focus is continuous, data-driven process improvement.
Its successor, CMMI (now maintained by ISACA, formerly the SEI), keeps five levels but renames level 2 to Managed and level 4 to Quantitatively Managed, a frequent trap, because the names moved between the two models even though the ladder is the same shape.
For software security specifically, two models sit side by side and are best understood as one contrast, prescriptive vs descriptive:
- OWASP SAMM (Software Assurance Maturity Model) is prescriptive: it defines 15 security practices grouped into 5 business functions (Governance, Design, Implementation, Verification, Operations), each with three maturity levels of activities, and tells you what to adopt next (OWASP SAMM[4]). It is technology- and process-agnostic.
- BSIMM (Building Security In Maturity Model) is descriptive: rather than prescribing an ideal, it observes and reports what a large pool of real firms actually do across four domains (Governance, Intelligence, SSDL Touchpoints, Deployment), so you benchmark against peers. "BSIMM is descriptive, documenting your actual practices and capabilities" (Black Duck / BSIMM[5]).
Choosing a target level is a risk and resource decision; most organizations should not reflexively aim for the top level.
Operation, maintenance, change management, and the IPT
Operation and maintenance is the longest SDLC phase, where patching, secure configuration, monitoring, and re-assessment after change keep a live system secure against new threats. Every change here (patch, feature, or config tweak) flows through change management: review, test, approve, document, and keep a rollback path, so no modification silently weakens a control. (The general change-management discipline lives in change-management; here it is the SDLC-specific reason it exists.) The Integrated Product Team (IPT) is the staffing model that makes all of this collaborative: a multidisciplinary group (developers, security, operations, QA, and the business owner) works the whole life cycle together so security is a shared responsibility, not a hand-off to a separate team at the end.
Exam-pattern recognition
This section maps the stems to the right answers: what the question looks like and which distractor it dangles.
"When is the cheapest / best time to address security?"
Stems asking when to introduce security, when a flaw is cheapest to fix, or where to put the most security effort want the earliest possible phase (requirements/design) and the language of shifting left and building security in. The tempting wrong answer is "during testing" or "in production once issues are found" (penetrate-and-patch); both sit at the expensive end of the cost-of-correction curve. If a stem describes a team that only does a security review just before go-live, the defect is that security was not integrated into earlier phases.
"Which methodology / where does security fit it?"
Match the cadence to the keyword: Waterfall = strict sequential phases, suits stable requirements; Agile = iterative sprints, security must be in each sprint's definition of done; DevOps = continuous CI/CD pipeline, and the security-integrated form is DevSecOps (automated gates in the pipeline). A common trap is treating DevSecOps as a separate, after-the-fact security review bolted onto DevOps; its whole point is automated, continuous, in-pipeline security so it keeps pace with frequent releases. Another: assuming a single methodology is "most secure"; the secure choice depends on the requirements' stability and release cadence.
"Which maturity model / which level?"
The sharpest maturity trap is SW-CMM vs CMMI level names: original CMM levels are Initial, Repeatable, Defined, Managed, Optimizing; CMMI keeps five levels but level 2 becomes Managed and level 4 becomes Quantitatively Managed. A stem that names "Repeatable" is the original CMM. The second maturity trap is SAMM vs BSIMM: SAMM is prescriptive (tells you the practices to adopt), BSIMM is descriptive (reports what real firms do so you benchmark against peers); if the stem says "benchmark against what other organizations actually do," the answer is BSIMM. Do not assume the goal is always the highest level; the right target is set by risk and resources.
"Who owns security / how do changes ship?"
When a stem describes a multidisciplinary group owning a product across its whole life cycle, the answer is the Integrated Product Team (IPT); the distractor is a standalone security team that receives a hand-off at the end, which is exactly the model the SDLC discipline rejects. When a stem describes a patch or feature being deployed to live software, the controlling process is change management (review, test, approve, document, rollback); skipping it so a fix ships faster is the wrong move that introduces unreviewed risk.
Where security fits each development methodology
| Dimension | Waterfall | Agile | DevOps / DevSecOps |
|---|---|---|---|
| Phase flow | Phases run once, in strict sequence | Short iterative sprints, repeated | Continuous integration and delivery pipeline |
| Where security sits | A defined activity in each sequential phase | Security stories and reviews each sprint | Automated security gates in the CI/CD pipeline (DevSecOps) |
| Main risk to security | Late-found flaws are very costly to retrofit | Security can slip if it is not in every sprint's definition of done | Fast release cadence can outrun manual security checks |
| Best fit | Stable, well-understood requirements (e.g. regulated, fixed-scope) | Evolving requirements needing frequent feedback | Frequent releases needing security to keep pace with delivery |
| Security keyword | Build security into every phase | Shift-left into each sprint | Automate and continuously verify (DevSecOps) |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Build security into every SDLC phase, never bolt it on at the end
Security is a property engineered into each phase of the Software Development Life Cycle, not a single test before release. Requirements owns security requirements and abuse cases, design owns threat modeling, coding owns secure standards and static analysis, testing owns security and penetration testing, and operation owns patching and monitoring. A program that only reviews security just before go-live has already lost, because gaps in earlier phases have hardened into vulnerabilities by then.
- A flaw costs more to fix the later it is found, so shift security left
The cost to correct a defect rises sharply across the life cycle: a missing security requirement is cheapest to fix while it is still a sentence in a document and most expensive once it is live code, because a late fix forces reworking design, code, tests, and a re-release. This cost-of-correction curve is the economic case for shifting security left: moving requirements, threat modeling, and testing earlier so defects surface when they are cheap to fix.
Trap Answering that security is cheapest to address during testing or after deployment: that is the expensive end of the curve.
3 questions test this
- A security architect at a SaaS company is embedding security testing into a newly adopted DevSecOps pipeline. Leadership wants defects…
- A development lead at an insurer is integrating security gates into a CI/CD pipeline for an application written in-house. A post-incident…
- A development organization implements threat modeling in their design phase and wants to establish a KPI to measure its effectiveness.…
- Prefer building security in over penetrate-and-patch
Building security in means designing controls into the software proactively from requirements onward; penetrate-and-patch means shipping, waiting to be attacked or scanned, then fixing. Building in is cheaper and safer because it avoids the high end of the cost-of-correction curve and the window of exposure that penetrate-and-patch leaves open. Penetrate-and-patch is reactive and should never be the primary strategy.
Trap Accepting penetrate-and-patch as a legitimate primary strategy because patches still get released, when it is reactive and leaves a window of exposure.
- The methodology sets the cadence; security must adapt to it
Development methodologies differ mainly in how they sequence and repeat the SDLC phases: Waterfall runs them once in strict order, Agile repeats them in short sprints, DevOps runs them continuously in a CI/CD pipeline. There is no single 'most secure' methodology; the secure choice depends on requirement stability and release cadence. Security practices are fitted into whichever model is used rather than the model being chosen for security.
Trap Claiming one methodology (e.g. Waterfall) is inherently the most secure: fit depends on the requirements and cadence.
- Waterfall runs phases once in sequence; its risk is costly late fixes
Waterfall executes the SDLC phases one time in strict order, each phase completing before the next starts, which suits stable, well-understood, fixed-scope requirements such as regulated work. Its security weakness is that a flaw found in a late phase is very expensive to retrofit, because earlier phases are already closed. Security in Waterfall is a defined activity inside each sequential phase.
Trap Assuming Waterfall lets you freely loop back to revise an earlier phase mid-project, when that iterative reworking is the Agile model, not strict Waterfall.
- Agile delivers in sprints, so security must be in each sprint's definition of done
Agile reworks the phases in short iterative sprints, reshaping requirements as feedback arrives, which fits evolving requirements that need frequent delivery. Security can slip between iterations unless it is part of every sprint's definition of done: security user stories, per-sprint review, and testing. The risk is deferring security to a 'later' sprint that never has room for it.
Trap Reading Agile's speed and light documentation as license to skip security activities until a dedicated 'security sprint' later.
- DevSecOps embeds automated security gates into the DevOps pipeline
DevOps fuses development and operations into a continuous integration and delivery (CI/CD) pipeline that releases frequently; DevSecOps is the variant that builds security in as automated, continuous gates inside that pipeline: dependency scanning, static and dynamic analysis, policy checks. The goal is for security to keep pace with a fast release cadence rather than become a manual bottleneck before each release.
Trap Treating DevSecOps as a separate manual security review bolted onto DevOps: its point is automated, in-pipeline, continuous security.
- The SSDF (NIST SP 800-218) is methodology-agnostic and added to your existing model
NIST's Secure Software Development Framework, SP 800-218, is deliberately methodology-agnostic: it states that few SDLC models address software security in detail, so its practices are meant to be added to and integrated with whatever model a team already uses. Its four practice groups are Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). It is guidance to integrate, not a methodology that replaces Waterfall, Agile, or DevOps.
Trap Picking the SSDF as a replacement SDLC methodology a team adopts instead of Waterfall or Agile, when it is guidance layered onto whatever model is already in use.
- The original SW-CMM has five levels: Initial, Repeatable, Defined, Managed, Optimizing
The Software Engineering Institute's original Capability Maturity Model rates process discipline on five ascending levels: 1 Initial (ad-hoc, hero-driven), 2 Repeatable (basic project management), 3 Defined (standardized organization-wide), 4 Managed (measured quantitatively), and 5 Optimizing (continuous improvement). The ladder climbs from chaos to metrics-driven improvement, and an organization benchmarks itself against it to plan improvement.
Trap Mixing in the CMMI names: the original CMM level 2 is 'Repeatable', not 'Managed'.
- CMMI keeps five levels but renames level 2 to Managed and level 4 to Quantitatively Managed
CMMI, the successor to SW-CMM now maintained by ISACA (formerly the SEI), keeps the five-level ladder but changes two names: level 2 becomes Managed (was Repeatable) and level 4 becomes Quantitatively Managed (was Managed). The shape of the ladder is the same; only the labels at levels 2 and 4 moved. This name collision ('Managed' meaning level 2 in CMMI but level 4 in the old CMM) is a frequent exam trap.
Trap Reading 'Managed' as level 4 when the question is about CMMI, where 'Managed' is level 2 and level 4 is 'Quantitatively Managed'.
- OWASP SAMM is prescriptive: it tells you which practices to adopt
OWASP SAMM (Software Assurance Maturity Model) is a prescriptive software-security maturity model: it defines 15 security practices grouped into 5 business functions (Governance, Design, Implementation, Verification, Operations) each with three maturity levels of activities, and tells an organization what to adopt next. It is technology- and process-agnostic, so it works across any methodology. Use it to set target activities and measure progress toward them.
Trap Labeling SAMM as descriptive like BSIMM, when SAMM prescribes target activities to adopt while BSIMM only reports observed practices.
- BSIMM is descriptive: it reports what real firms actually do
BSIMM (Building Security In Maturity Model) is descriptive rather than prescriptive: instead of an ideal to aim at, it observes and reports the activities a large pool of real organizations actually perform, across four domains (Governance, Intelligence, SSDL Touchpoints, and Deployment) so you benchmark your program against peers. SAMM tells you what you should do; BSIMM tells you what others are doing.
Trap Calling BSIMM prescriptive: it documents observed practices for benchmarking, not a target set of best practices.
- Choose a target maturity level by risk and resources, not 'always aim for level 5'
A maturity model lets an organization benchmark and plan improvement, but the right target level is a risk and resource decision, not an automatic climb to the top. Most organizations should not reflexively aim for the highest level; the cost of reaching and sustaining it must be justified by the risk it reduces. The model guides prioritization, not a mandate to maximize.
Trap Choosing the highest maturity level as the universally correct goal, when the right target is the one justified by the organization's risk and resources.
- Operation and maintenance is the longest SDLC phase and an active security stage
Once software is released, operation and maintenance is the longest phase of its life, where patching, secure configuration, monitoring, and re-assessment after every significant change keep it secure against new threats. Security work does not stop at deployment; the running system needs continuous attention, including re-running risk assessments when the system or its environment changes materially.
Trap Assuming security work effectively ends once the system is deployed, treating operation and maintenance as passive upkeep rather than an active security stage.
- Route every change to released software through change management
During operation, every modification (a patch, a feature, or a configuration tweak) flows through change management: review, test, approve, document, and keep a rollback path, so no change is made without oversight. This prevents a well-meant fix from silently introducing a new vulnerability or breaking an existing control. Skipping change control to ship a fix faster is the wrong move because it deploys unreviewed risk.
Trap Pushing a patch straight to production to fix something fast, bypassing review and testing: that ships unvetted risk.
- The Integrated Product Team (IPT) makes security a shared, cross-functional responsibility
An Integrated Product Team is a multidisciplinary group (developers, security, operations, QA, and the business owner) that works a product across its whole life cycle together, so security is a shared responsibility rather than a hand-off to a separate team at the end. The IPT model embeds security expertise alongside development instead of gating it as a late, separate review. It is the staffing pattern behind 'build security in.'
Trap Picturing a standalone security team that receives a finished product to review: the IPT integrates security throughout, not at a hand-off.
- Capture security requirements and abuse cases in the requirements phase
The requirements phase owns security and privacy requirements plus abuse or misuse cases (explicit statements of how the system must resist attack and how an attacker might try to misuse it) alongside an initial risk and data-classification view. Getting these right early is the cheapest point on the cost-of-correction curve, and they drive the threat modeling and control choices made in design. Functional requirements alone, with security added later, is the failure pattern.
Trap Conflating abuse and misuse cases with ordinary functional use cases, when they specify how an attacker tries to break the system, not the intended user behavior.
- Threat modeling belongs to the design phase
Threat modeling (systematically enumerating how a design could be attacked and which controls counter each threat) is a design-phase activity, performed after requirements are set but before code is written, so the architecture can be shaped to resist the identified threats. Done here it is cheap; deferred until after implementation it forces redesign. It feeds the secure-design review and control selection that close out the design phase.
Trap Placing threat modeling in the testing phase alongside penetration testing, when it belongs in design, before code is written, so the architecture can be shaped.
- Disposal is a deliberate security stage, not an afterthought
Retirement and disposal is the final SDLC phase and a deliberate security activity, because a system at end of life still holds data, credentials, keys, and trust relationships. Secure decommissioning sanitizes or destroys media, revokes the system's identities and access, and updates the asset inventory and architecture records. Walking away from a retired system without sanitizing it leaves recoverable data and live trust paths.
Trap Treating disposal as a non-security cleanup step of deleting files and unplugging hardware, skipping media sanitization and revocation of the system's identities and trust paths.
References
- NIST glossary: Software Development Life Cycle (SDLC) Whitepaper
- NIST SP 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systems Whitepaper
- NIST Secure Software Development Framework (SSDF), SP 800-218 Whitepaper
- OWASP SAMM: Software Assurance Maturity Model (About)
- BSIMM: Building Security In Maturity Model (overview)