Secure SDLC Process
The SDLC phase model and why phasing matters
A flaw is cheapest to fix in the phase that created it. That single economic fact is why the CCSP frames application security around a life cycle rather than a single build step: name the phases, attach a security activity to each, and you catch defects where they are cheap instead of in production where they are not.
The software development life cycle (SDLC) is the ordered set of phases software passes through from idea to retirement. ISC2 study material commonly works with these phases: requirements, design, development (coding), testing, deployment, and operations and maintenance (which ends in secure decommissioning). Other models compress or rename these (a five-phase "plan, design, develop, test, deploy/maintain" is common), but the candidate's job is to recognize the same backbone whatever the labels. The secure SDLC (SSDLC) is not a different life cycle; it is the same phases with a security activity deliberately added to each, so security is a property designed into the system rather than inspected in at the end.
The reason to insist on phasing is the cost-of-remediation curve. Industry data popularized by NIST and the OWASP Software Assurance Maturity Model (SAMM)[1] shows the relative cost to fix a defect climbs by roughly an order of magnitude as it survives into later phases: a requirements error fixed on paper is far cheaper than the same error found by a tester, which is far cheaper than a vulnerability patched after release. This curve is the justification for shift-left: move security activity toward the earlier phases.
This subtopic describes the phase model and the activity each phase owns. Converting those activities into concrete technique (threat-modeling methods, secure-coding standards, configuration management) is the job of the apply-the-SDLC subtopic; here the goal is to know the map, not yet to drive every road.
One security activity per phase
The phase model earns its keep by assigning a named security activity to each phase, so nothing is left to chance. Read this as the map a question draws from: the exam routinely hands you a phase and asks for the right activity, or hands you an activity and asks which phase owns it.
Requirements
Security and privacy requirements are gathered here, alongside functional requirements, driven by the data the application handles, the regulations it falls under, and the threats it faces. Abuse cases (how an attacker would misuse a feature) are written as the security counterpart to use cases. Getting requirements right is the highest-leverage phase, because every later phase inherits its gaps.
Design
The team produces a secure architecture and a threat model that identifies what could go wrong and which controls answer each threat. Design decisions like trust boundaries, authentication flows, and where data is encrypted are made here, on paper, where they are cheap to change.
Development (coding)
Developers apply secure coding standards and run static application security testing (SAST), which analyzes source code (or bytecode) without executing it to flag vulnerable patterns early. SAST is a white-box, code-time check; it sees the code but not the running behavior.
Testing
Dynamic application security testing (DAST) exercises the running application from the outside, finding flaws that only appear at runtime, and security and abuse-case testing confirms the controls actually hold. DAST is a black-box, runtime check; it sees behavior but not source. The two are complementary, which is why both appear in a complete SSDLC.
Deployment
The build is released to a hardened configuration, secrets are injected from a vault rather than baked into images, and the deployment configuration is reviewed. In the cloud this is where infrastructure-as-code and image scanning gate the release.
Operations and maintenance
The live system is patched, monitored, and its dependencies tracked, and when the application retires it is securely decommissioned (data sanitized or crypto-shredded, access revoked). Maintenance is a phase of the SSDLC, not an afterthought outside it.
Waterfall, agile, and the DevSecOps answer
The phases are the same; the methodology decides how often you run them and when each is signed off. The exam wants the trade-off, not a preference.
Waterfall runs the phases once, strictly in sequence, with each phase formally signed off before the next begins. Its strength is traceability and predictability: a regulator who wants documented phase gates and a fixed scope is well served. Its weakness is that most testing is deferred to a late, dedicated phase, so security defects surface where the cost-to-fix curve is steepest, and a requirement that changes mid-project is expensive to absorb. Waterfall fits stable, heavily regulated requirements.
Agile delivers the same phases in short repeating iterations (sprints), producing working, tested software continuously and absorbing changing requirements gracefully. The risk is that security can drift if it is not made an explicit part of every sprint: "we'll secure it later" never arrives. Agile fits evolving requirements and fast feedback.
Neither methodology is security; security has to be built into whichever one you choose. DevSecOps is the cloud-native way to do that, and it is methodology-agnostic. It extends DevOps by shifting security left into the automated pipeline: static analysis (SAST), dynamic analysis (DAST), software composition analysis (SCA) for vulnerable dependencies, infrastructure-as-code and container-image scanning, and policy-as-code gates all run on every change. The principle is continuous, automated assurance instead of a one-time release gate, which is the same shift-left idea the cost-to-fix curve demands, now enforced by the pipeline rather than by discipline alone.
A careful distinction the exam rewards: agile is about iteration cadence, while DevSecOps is about automating security into delivery. You can run agile without DevSecOps (manual security reviews each sprint) and you can apply DevSecOps practices on top of either methodology; they are complementary, not synonyms.
Exam-pattern recognition
CCSP items on this objective tend to test the map, not deep technique. A few recurring stem shapes and how to read them:
"Where in the SDLC does activity X belong?"
Match the activity to its phase. Threat modeling and secure architecture sit in design; static analysis (SAST) sits in development; dynamic analysis (DAST) and abuse-case testing sit in testing; hardening and secrets management sit at deployment; patching and monitoring sit in operations and maintenance. The classic distractor is putting threat modeling in the coding phase: it belongs to design, before the code exists.
"When is the cheapest time to fix this flaw?"
The answer is always the earliest phase that could catch it, usually requirements or design. The cost-to-fix curve is the reasoning, and a stem that describes an expensive late-stage patch is signalling that the team skipped an early activity.
"Which methodology fits this scenario?"
Fixed scope plus a regulator who wants documented phase sign-offs points to waterfall; rapidly changing requirements and a need for continuous delivery points to agile; a question about automating security checks into the CI/CD pipeline points to DevSecOps / shift-left. Watch the trap that treats agile and DevSecOps as the same thing: agile is iteration cadence, DevSecOps is automated security in delivery.
"What is wrong with this team's process?"
If the scenario runs a single security review just before launch, the defect is that security was treated as a release gate instead of being built into every phase; the corrective answer is shift-left. If the scenario writes only functional requirements and discovers security needs during a pre-launch test, the defect is missing security requirements, fixed by gathering them in the requirements phase.
Keep the boundary clear: this objective is describe the process. If a question drills into a specific threat-modeling method (STRIDE, DREAD, PASTA, ATASM) or a secure-coding standard (OWASP ASVS, SAFECode), it has moved into the apply-the-SDLC territory, and the right mental model is the one taught there.
Secure activity by SDLC phase, and how waterfall vs agile sequences it
| SDLC phase | Secure activity in this phase | Waterfall sequencing | Agile / DevSecOps sequencing |
|---|---|---|---|
| Requirements | Security and privacy requirements, abuse cases | Once, fully signed off before design | Refined per iteration as a backlog item |
| Design | Secure architecture, threat model | Once, after requirements sign-off | Per feature, revisited each sprint |
| Development | Secure coding standards, static analysis (SAST) | After full design sign-off | Continuous, automated on each commit |
| Testing | Dynamic analysis (DAST), security and abuse-case testing | Deferred to a late dedicated phase | Continuous in the pipeline, every build |
| Deployment | Hardening, secrets management, config review | One-time release event | Automated, frequent, repeatable |
| Operations & maintenance | Patching, monitoring, secure decommissioning | Post-handover, separate team | Same pipeline owns run plus change |
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.
- The secure SDLC is the normal SDLC with a security activity per phase
The SSDLC does not replace the development life cycle; it attaches a deliberate security activity to each existing phase so security is designed in rather than inspected in at the end. The phases ISC2 commonly uses are requirements, design, development, testing, deployment, and operations and maintenance. Knowing the backbone matters more than the exact count, because different models compress or rename phases while keeping the same flow.
- Fix flaws as early as possible because cost rises about 10x per later phase
The cheapest place to fix a defect is the earliest phase that could catch it, which is why the whole life cycle is phased. A requirements or design flaw fixed on paper costs roughly an order of magnitude less than the same flaw found in testing, and far less again than a vulnerability patched in production. This cost-to-fix curve is the reasoning behind shift-left, so a question describing an expensive late patch is signalling a skipped early activity.
- Capture security requirements at the requirements phase, not before launch
Security and privacy requirements are gathered alongside functional requirements at the very start, driven by the data handled, the regulations in scope, and the threat environment. They then shape design, constrain code, and define what tests must prove. A team that writes only functional stories and discovers its encryption, logging, and access needs during a pre-launch pen test has inverted the life cycle and pays for it in rework.
Trap Treating security as a final review gate just before go-live; that lets flawed requirements and insecure design accumulate to where they are expensive to remove, the exact shift-left failure the phase model prevents.
- Abuse cases are the security counterpart to use cases, written at requirements
An abuse case describes how an attacker would deliberately misuse a feature, the mirror image of a use case that describes intended behavior. Writing abuse cases during the requirements phase surfaces the misuse paths controls must block before any design is drawn. They feed the threat model that the design phase produces.
- Threat modeling belongs to the design phase, before code exists
The design phase produces a secure architecture and a threat model that names what could go wrong and which control answers each threat. Trust boundaries, authentication flows, and where data is encrypted are decided here on paper, where changes are cheap. The describe-the-process view places threat modeling in design; the specific methods used to do it live in the apply-the-SDLC objective.
Trap Placing threat modeling in the coding phase; it belongs to design, because you model the architecture before the code that implements it exists.
- SAST is a white-box code-time check run during development
Static application security testing (SAST) analyzes source code or bytecode without running it, flagging vulnerable patterns early in the development phase. It is a white-box technique because it sees the code, so it catches issues like injection-prone patterns before a build runs. It cannot see behavior that only emerges at runtime, which is what dynamic testing covers.
Trap Expecting SAST to catch runtime-only flaws such as misconfigured server responses or auth bypasses that appear only when the app runs; those need dynamic testing.
- DAST is a black-box runtime check run during testing
Dynamic application security testing (DAST) exercises the running application from the outside, finding flaws that surface only at runtime. It is a black-box technique because it sees behavior, not source, so it complements rather than replaces SAST. A complete secure SDLC uses both: SAST in development on the code, DAST in testing on the running system.
Trap Choosing DAST alone as sufficient application security testing; without SAST you miss code-level defects that never surface in black-box behavior.
- Each phase owns a distinct, named security activity
The phase model assigns one security activity per phase so nothing is implicit: requirements gathers security requirements and abuse cases, design produces the threat model and secure architecture, development applies secure coding and SAST, testing runs DAST and abuse-case testing, deployment hardens config and manages secrets, and operations patches, monitors, and securely decommissions. The exam frequently hands you a phase and asks for its activity, or an activity and asks for its phase.
- Maintenance and secure decommissioning are phases of the SSDLC, not afterthoughts
Operations and maintenance is a full phase: the live system is patched, monitored, and its dependencies tracked, and when the application retires it is securely decommissioned with data sanitized or crypto-shredded and access revoked. Treating retirement as outside the life cycle leaves orphaned data and credentials behind. In the cloud, crypto-shredding the keys is the practical decommission step because you do not control the physical disks.
- Waterfall runs the phases once in sequence with sign-off gates
Waterfall executes the phases strictly in order, each formally signed off before the next begins, which gives traceability and predictability that suit fixed-scope, heavily regulated work. Its cost is that most testing is deferred to a late dedicated phase, so security defects appear where the cost-to-fix curve is steepest, and mid-project requirement changes are expensive to absorb. Choose it when requirements are stable and a regulator expects documented phase gates.
Trap Forcing waterfall onto volatile requirements; its single ordered pass ships software that no longer matches need by release, which is exactly when an iterative methodology fits better.
- Agile delivers the same phases in short repeating iterations
Agile runs requirements, design, build, and test inside short sprints, producing working tested software continuously and absorbing changing requirements gracefully. The risk is that security drifts when it is not made an explicit part of every sprint, because deferred security work tends never to arrive. Choose agile when requirements evolve and fast feedback matters more than fixed up-front scope.
Trap Assuming agile is automatically secure; without security work built into each sprint, the iterative cadence just defers security indefinitely.
- DevSecOps shifts security left by automating it into the pipeline
DevSecOps extends DevOps by wiring security into the automated CI/CD pipeline so it runs on every change: SAST and software composition analysis on code and dependencies, DAST on the running build, infrastructure-as-code and container-image scanning, and policy-as-code gates. The principle is continuous automated assurance instead of a one-time release gate, the same shift-left idea the cost-to-fix curve demands, now enforced by the pipeline rather than by discipline alone.
Trap Treating a single security review just before launch as a secure pipeline; that is a release gate, not shift-left, and lets insecure design accumulate until it is costly to fix.
14 questions test this
- An organization wants to ensure that its IaC templates comply with security policies before any pull request is merged. The security team…
- A cloud security architect is designing a CI/CD pipeline for deploying microservices in containers. The organization wants to prevent…
- An organization is implementing training for developers on integrating SCA tools into CI/CD pipelines. Which approach should the training…
- A DevSecOps team is integrating SCA scanning into their cloud application development workflow. According to OWASP DevSecOps guidance, at…
- An organization is implementing a container security strategy that includes vulnerability scanning for container images. At which point in…
- An organization is implementing container image scanning within their CI/CD pipeline. At which point in the pipeline does scanning provide…
- A security architect wants to enforce organizational guardrails on every Terraform plan before it is applied, such as prohibiting publicly…
- An organization is implementing a DevSecOps pipeline and wants to identify security vulnerabilities in their Terraform templates before…
- An organization wants to integrate SCA scanning into their CI/CD pipeline for cloud-native applications. At which stage should SCA scanning…
- A development team is implementing container security controls for their cloud-native application. Which approach provides the MOST…
- A cloud application development team using a DevSecOps approach wants to ensure that vulnerabilities introduced during the coding phase are…
- A software development organization is implementing the NIST Secure Software Development Framework (SSDF), which incorporates practices…
- A DevSecOps engineer is integrating IAST into a continuous integration pipeline for a cloud-native application. What is the PRIMARY benefit…
- A DevSecOps team wants their CI/CD pipeline to automatically enforce security policies as code, ensuring that every deployment is validated…
- Agile is iteration cadence; DevSecOps is automated security in delivery
The two are complementary, not synonyms: agile decides how often you run the phases, while DevSecOps decides how security is built into delivery. You can run agile with manual security reviews each sprint, and you can apply DevSecOps practices on top of waterfall or agile alike. A question about automating SAST/DAST into CI/CD points to DevSecOps, while a question about short iterations and changing scope points to agile.
Trap Equating agile with DevSecOps; adopting sprints does not by itself automate security, and automating security does not require agile.
- Software composition analysis covers vulnerable third-party dependencies
Software composition analysis (SCA) inventories the open-source and third-party components a build pulls in and flags known-vulnerable versions, which neither SAST nor DAST reliably catch because the flaw lives in code you did not write. In a DevSecOps pipeline SCA runs automatically on each change so a newly disclosed dependency CVE is caught at build time. It is the supply-chain-facing leg of automated assurance.
Trap Relying on SAST to catch vulnerable libraries; SAST scans your code, while a known-vulnerable dependency version is found by SCA against a vulnerability database.
- Security is a system requirement, designed in, not bolted on
The governing principle of the secure SDLC is that security is a property of the system and its delivery process, captured as a requirement and carried through every phase, never a checklist added before release. This is why the phase model exists and why shift-left is the recurring corrective. A process whose only security step is a final gate has misunderstood the model regardless of which methodology it uses.