Study guide
9.2 Secure SDLC Process (Domain 4.2)
Certified Cloud Security Professional CCSP
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current CCSP Exam Facts 1.2 CAT Format, Scoring & Logistics 1.3 Eligibility, Experience & Certification Maintenance
2 Domain 1: Cloud Concepts & Architecture Foundations
2.1 Cloud Computing Concepts (Domain 1.1) 2.2 Cloud Reference Architecture (Domain 1.2) 2.3 Security Concepts Relevant to Cloud (Domain 1.3)
3 Domain 1: Secure Design, CSP Evaluation & AI/ML
3.1 Design Principles of Secure Cloud Computing (Domain 1.4) 3.2 Evaluate Cloud Service Providers (Domain 1.5) 3.3 AI/ML in Cloud Security (Domain 1.6)
4 Domain 2: Data Concepts, Storage & Protection Technologies
4.1 Cloud Data Concepts (Domain 2.1) 4.2 Cloud Data Storage Architectures (Domain 2.2) 4.3 Data Security Technologies & Strategies (Domain 2.3)
5 Domain 2: Discovery, Classification & Information Rights Management
5.1 Data Discovery (Domain 2.4) 5.2 Data Classification (Domain 2.5) 5.3 Information Rights Management (Domain 2.6)
6 Domain 2: Retention, Auditability & AI/ML Data Protection
6.1 Retention, Deletion & Archiving (Domain 2.7) 6.2 Auditability, Traceability & Accountability (Domain 2.8) 6.3 AI/ML Data Protection (Domain 2.9)
7 Domain 3: Infrastructure Components, Data Center & Risks
7.1 Cloud Infrastructure Components (Domain 3.1) 7.2 Secure Data Center Design (Domain 3.2) 7.3 Infrastructure & Platform Risks (Domain 3.3)
8 Domain 3: Security Controls & Business Continuity / Disaster Recovery
8.1 Security Controls Implementation (Domain 3.4) 8.2 Business Continuity & Disaster Recovery (Domain 3.5)
9 Domain 4: Application Security Awareness & Secure SDLC
9.1 Application Security Training & Awareness (Domain 4.1) 9.2 Secure SDLC Process (Domain 4.2) 9.3 Apply Secure SDLC (Domain 4.3)
10 Domain 4: Software Assurance, Architecture & IAM
10.1 Cloud Software Assurance & Validation (Domain 4.4) 10.2 Verified Secure Software (Domain 4.5) 10.3 Cloud Application Architecture (Domain 4.6) 10.4 Identity & Access Management Solutions (Domain 4.7)
11 Domain 5: Build, Operate & Operational Controls
11.1 Build Physical & Logical Infrastructure (Domain 5.1) 11.2 Operate & Maintain Infrastructure (Domain 5.2) 11.3 Operational Controls & Standards (Domain 5.3)
12 Domain 5: Forensics, Stakeholder Communication & Security Operations
12.1 Digital Forensics Support (Domain 5.4) 12.2 Communication with Relevant Parties (Domain 5.5) 12.3 Manage Security Operations (Domain 5.6)
13 Domain 6: Legal Requirements, Privacy & Audit
13.1 Legal Requirements & Cloud Risks (Domain 6.1) 13.2 Privacy Requirements (Domain 6.2) 13.3 Audit Processes for Cloud (Domain 6.3)
14 Domain 6: Enterprise Risk Management & Cloud Contracts
14.1 Cloud Implications for Enterprise Risk (Domain 6.4) 14.2 Outsourcing & Cloud Contract Design (Domain 6.5)
9.2 Secure SDLC Process (Domain 4.2)
Key Takeaways Explain This Topic AI
Secure SDLC integrates security activities into every development phase rather than treating security as a post-release bolt-on.
Business requirements drive security requirements: classification, compliance, availability, privacy, and abuse cases must be captured early with functional needs.
Core phases include requirements, design, implementation (code), testing, deployment/release, and maintenance/operations — with disposal when systems retire.
Waterfall and Agile (including DevOps/DevSecOps) both can be secure; methodology changes when and how security activities run, not whether they exist.
On CCSP, describe process and business drivers first (4.2); detailed application of cloud risks, threat modeling, and secure coding appears in 4.3.
Last updated: July 2026
Secure Software Development Life Cycle (SDLC) Process
Domain 4.2 asks you to describe the Secure SDLC process: business requirements and phases and methodologies (design, code, test, maintain; waterfall vs. agile). This is the process blueprint. Domain 4.3 will apply it with cloud-specific risks, threat modeling, secure coding, and configuration management. Do not skip the process language — exam items often test whether you know when a control belongs in the lifecycle, not only what the control is.
What “Secure SDLC” Means
A Software Development Life Cycle (SDLC) is the structured set of phases an organization uses to conceive, build, test, release, and maintain software. A Secure SDLC (sometimes SSDLC) embeds security practices, gates, and artifacts into those phases so that confidentiality, integrity, availability, privacy, and safety properties are designed and verified — not hoped for after launch.
- Traditional late security Secure SDLC
- Pen test only before go-live Threat modeling and requirements at start
- Security as optional reviewer Security criteria in definition of done
- Fix only criticals if time remains Risk-based remediation SLAs by severity
- Manual heroics Automated checks in pipelines where possible
- Blame after breach Continuous improvement of process metrics
Shift-left is the slogan: move defect discovery earlier when fixes are cheaper. In cloud, “left” also means infrastructure and policy as code reviewed with application code, because the runtime is defined in the same repositories.
Business Requirements as the Security Driver
Security requirements that are not grounded in business context become either theater or blockers. CCSP expects you to derive security needs from business drivers.
Categories of Business Input
- Business input Security requirement examples
- Data classification & handling Encryption, residency, logging minimization, IRM for “confidential”
- Regulatory / contractual Sector controls, privacy subject rights, audit logging retention
- Availability commitments (SLA/SLO) Multi-AZ design, graceful degradation, RTO/RPO for the app tier
- User population & trust model Workforce vs customer vs partner; federation and MFA requirements
- Transaction value / fraud risk Step-up authentication, velocity checks, non-repudiation
- Time-to-market strategy Risk acceptance process; MVP control baseline vs later hardening
- Third-party integrations Vendor assessment, least data shared, API contracts
- Brand and safety Abuse prevention, content safety for user-generated or AI features
- Functional vs Non-Functional vs Security Requirements
Functional — what the system does (“user can reset password”).
Non-functional — quality attributes (“p95 latency under 200 ms”).
Security — often non-functional but written as testable requirements (“password reset tokens single-use, expire in 15 minutes, sent only over TLS, rate-limited”).
Abuse cases (or misuse cases) are the negative twin of use cases: how an attacker or malicious insider would misuse features. Capturing abuse cases during requirements is a hallmark of secure SDLC maturity.
Worked example: Business wants “share document links with partners.” Security requirements derived: link expiry, authentication vs semi-public tokens, watermarking/IRM if classified, audit of access, ability to revoke, no secrets in URLs logged by intermediaries, and residency of shared storage. Without that analysis, engineers ship infinite-lived public URLs — a requirements failure, not only a coding bug.
SDLC Phases and Security Activities
Exact phase names vary by organization. For CCSP, master a vendor-neutral sequence and the security work in each.
Phase Primary goal Security activities (examples)
Initiation / planning Scope, stakeholders, feasibility Security objectives, compliance scope, RACI for AppSec, tool budget
Requirements What to build Security & privacy requirements, abuse cases, classification, legal constraints
Design / architecture How to build Threat modeling, trust boundaries, control selection, secure design patterns
Implementation / coding Build software & IaC Secure coding standards, peer review, secret hygiene, dependency choice
Testing / verification Prove it works safely SAST/DAST/IAST/SCA (detail in 4.4), security unit/integration tests, abuse tests
Deployment / release Deliver to environments Signed artifacts, least-privilege deploy, change control, config baselines
Operations / maintenance Run and improve Patching, monitoring, IR, vulnerability management, feedback to backlog
- Disposal / end-of-life Retire cleanly Data deletion, key destruction, decommission of APIs and identities
- Requirements Phase
Outputs that examiners love to see named:
Security requirements traceable to assets and regulations.
Data-flow and trust assumptions documented at a high level.
Acceptance criteria that QA can test (not “be secure”).
Privacy requirements (minimization, consent, retention) when personal data is in scope.
Design Phase
Design is where architecture risk is cheapest to remove. Activities include selecting authentication patterns (OIDC, mTLS between services), defining tenancy isolation, choosing encryption points, and deciding which managed services reduce undifferentiated risk. Security design review is a process control — a checkpoint, not an informal chat.
Implementation Phase
Coding standards, linters, pre-commit hooks for secrets, and mandatory peer review for sensitive paths operationalize design. Cloud adds: IaC modules for private networking defaults, policy libraries, and approved base images.
Testing Phase
Testing validates both functional correctness and security properties. Continuous integration can fail builds on policy violations. Domain 4.4 expands methodologies; in 4.2, know that testing is a defined phase/activity , not optional hobby work.
Maintenance Phase
Most of a system’s life is maintenance: dependency CVEs, feature additions, configuration drift, and incident-driven fixes. Secure SDLC includes ongoing risk assessment when scope changes (new region, new AI feature, new processor). “Maintain” is not “ignore until rewrite.”
Phase Traceability
A mature process maintains traceability : business requirement → security requirement → design control → code/config → test evidence → operational monitoring. Auditors and CCSP scenarios that mention “prove controls” are asking about this chain.
Methodologies: Waterfall vs Agile (and DevOps)
The outline calls out waterfall vs agile . Neither is inherently secure or insecure; the question is how security activities map onto the delivery rhythm.
Waterfall
Waterfall progresses through largely sequential phases with formal gate reviews. Security fits as stage-gate deliverables: requirements document security section, design review board, code complete with review, system security test, production acceptance.
- Waterfall strength Waterfall risk
- Clear documentation and checkpoints Late discovery if security only at end
- Good for highly regulated big-bang releases Slow feedback; expensive late redesign
- Easy to map to audit artifacts Parallel work and cloud iteration may not wait
- Agile
Agile delivers in iterations (sprints), emphasizing working software, collaboration, and response to change. Security must be sliced into backlog items , definition of done, and automated pipelines — not a single gate after six months of coding.
- Agile strength Agile risk
- Fast feedback from automated tests “We’ll secure in a hardening sprint” never arrives
- Continuous prioritization of risk Security debt if not scored in backlog
- Fits cloud continuous delivery Documentation gaps for auditors if not intentional
- DevOps and DevSecOps
DevOps unifies development and operations through automation and shared ownership of production outcomes. DevSecOps inserts security as a shared responsibility in that culture: policy-as-code, continuous security testing, and collaborative incident learning. For CCSP:
DevOps without security automation is speed without brakes.
Security teams that only throw PDF reports over the wall fail DevSecOps.
Cloud-native delivery almost always assumes CI/CD; secure SDLC language must include pipeline stages as process control points.
Mapping Security Activities Across Methodologies
Security activity Waterfall placement Agile / DevSecOps placement
Security requirements Dedicated requirements document section User stories + acceptance criteria + non-functional backlog
Threat modeling Design phase gate Lightweight models per epic/feature; update when architecture shifts
Secure code review Pre-system-test checkpoint Pull request reviews continuous; bots + human for sensitive paths
- Security testing Late system/integration test phase CI on every merge; deeper tests on release candidates
- Risk acceptance Formal change board Product owner + security with documented exceptions and expiry
- Maintenance patches Maintenance phase projects Automated dependency PRs + sprint capacity for CVE debt
Exam discrimination: A waterfall program that only pen-tests at the end is not a secure SDLC. An agile program that has no security stories, no definition-of-done security criteria, and no automated checks is also not a secure SDLC. Methodology label is not a security control.
Cloud-Specific Process Considerations
Even while describing process (not full application in 4.3), cloud changes how SDLC is run:
Cloud factor Process implication
Multi-account / multi-subscription environments Promote artifacts through environments (dev → test → prod) with separate identities
Managed services Requirements must name provider features (KMS, private endpoints) as design choices
Ephemeral environments Test environments spun from IaC must still enforce data masking for production-like data
- Continuous deployment Security gates must be automated or they will be skipped
- Shared responsibility Requirements and design RACI must state customer vs CSP control ownership
- Global release Legal/residency requirements enter the process before multi-region enablement
- Process Roles and Governance
- Role SDLC security responsibility
- Business owner Prioritize risk; accept residual risk formally
- Product manager Include security stories; protect capacity for debt
- Architect Threat model; select patterns and standards
- Developer Implement secure code and tests; fix findings
- AppSec / security engineer Standards, coaching, risk review, tool chain
- QA Abuse and negative testing; regression of security fixes
- Operations / SRE Runtime baselines, monitoring, patch feedback loop
- Compliance / risk Map process evidence to obligations
- Minimum Process Artifacts (Exam Checklist)
Security requirements (or security acceptance criteria per story).
Architecture/threat-model notes for non-trivial changes.
Coding standard reference (e.g., ASVS-aligned).
Pipeline policy (what fails the build).
Test evidence retention for releases.
Vulnerability and exception management procedure.
Operational runbooks for security events related to the app.
Process Maturity Signals
- Immature Maturing Mature
- Ad-hoc reviews when someone remembers Checklist at release Continuous, measured, improving
- Security only “no” Security as late gate Security as shared product quality
- Unknown third-party risk Inventory of dependencies SCA + approved catalogs + SBOMs
- No idea of data classes Spreadsheet of systems Classification drives requirements automatically
- Putting Domain 4.2 Together for the Exam
Read the stem: is it asking which phase , which methodology fit , or which business requirement drives a control ?
Place the activity correctly: threat modeling ≈ design; secure coding ≈ implementation; abuse cases ≈ requirements; patching ≈ maintain.
Reject answers that claim waterfall cannot be secure or that agile does not need documentation.
Connect business drivers (classification, SLA, regulation) to security requirements before tool selection.
- Common Traps
- Equating “we use Agile” with “we have Secure SDLC.”
Putting pen testing as the only security activity and calling it complete.
Writing non-testable requirements (“must be secure and robust”).
Ignoring maintenance and disposal as SDLC phases.