9.2 Secure SDLC Process (Domain 4.2)
Key Takeaways
- 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.
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.
- Forgetting that cloud IaC and pipeline design are part of the software process, not pure “ops afterthought.”
During which Secure SDLC phase should abuse cases and testable security requirements typically be captured for a new cloud application feature?
Which statement correctly contrasts waterfall and agile approaches to Secure SDLC?
A business requires multi-region active-active operation with a five-minute RPO for a payments API. In Secure SDLC terms, how should this primarily be treated?
What best characterizes a Secure SDLC compared with traditional late-stage security?