9.3 Apply Secure SDLC (Domain 4.3)

Apply the Secure Software Development Life Cycle

Domain 4.3 moves from describing the process to applying it. The August 2026 outline groups: cloud-specific risks, threat modeling (STRIDE, DREAD, ATASM, PASTA), avoiding common vulnerabilities during development, secure coding (OWASP ASVS, SAFECode), and software configuration management (CM) and versioning. Think of this section as the CCSP’s “how” for cloud application delivery under DevSecOps.

Cloud-Specific Risks in Application SDLC

Traditional secure coding still matters, but cloud changes the threat landscape for every phase.

Shared Technology Issues

Your application may run on shared hosts, use shared metadata services, or call multi-tenant APIs. Side channels, noisy neighbors, and control-plane bugs are rare but high impact; day-to-day, logical isolation failures in your own multi-tenant app are more common. Apply SDLC design reviews to tenant ID enforcement at every data access path.

CSP Insider Threats

You cannot background-check every CSP operator. Mitigations in design/implementation: customer-managed encryption keys, confidential computing where justified, strict secret management, and contracts/assurance reports (link to Domain 1/6 thinking). Application teams must not store master secrets in places provider support can casually read.

Lack of Visibility and Control

On PaaS, you may not install host agents. Build observability into the application and account layers: structured audit logs, distributed tracing with careful PII handling, config drift detection on tenant settings, and break-glass procedures that still log.

Legal and Jurisdiction Issues

A feature flag that replicates customer data to another region is a legal event, not only a latency optimization. Requirements and CI policy should prevent accidental cross-border data flows. Third-party SDK updates can introduce new subprocessor calls — supply-chain review is part of apply-SDLC.

Worked scenario: A SaaS product stores EU personal data. Engineering enables a global CDN cache that includes personalized responses in a non-EU PoP. Cloud risk = jurisdiction + shared edge technology + reduced control over cache purge. Application fix = redesign caching of personal content, geo controls, and threat model update — not only “turn on TLS.”

Threat Modeling Methods

Threat modeling identifies what can go wrong and what to do about it before and while you build. CCSP lists several methods; know purpose and differences.

STRIDE

STRIDE (Microsoft lineage) categorizes threats:

STRIDE is excellent for structured brainstorming against data-flow diagrams and trust boundaries.

DREAD

DREAD is a scoring model (variants exist) often described as:

Use DREAD (or modern risk scoring alternatives) to prioritize mitigations after threats are identified. Exam trap: DREAD is not a substitute for enumerating threat types; it ranks them.

ATASM

ATASM — Architecture, Threats, Attack Surfaces, and Mitigations — emphasizes walking from architecture understanding to attack surface inventory to mitigations. It fits cloud reviews where diagrams of accounts, APIs, identity providers, and data stores must be correct before threat lists make sense.

PASTA

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric methodology aligning business objectives with technical threat analysis and attack simulation. It is heavier than a quick STRIDE whiteboard and suits high-risk systems (payments, health, critical infrastructure apps on cloud).

Applying Threat Modeling in DevSecOps

• Model new trust boundaries when adding SaaS integrations, webhooks, or LLM tools.
• Revisit models when IAM or network architecture changes.
• Feed outputs into backlog (mitigations as stories) and test plans (abuse cases).
• Keep models living documents, not one-time binders.

Avoiding Common Vulnerabilities During Development

Application of SDLC means prevention while coding and configuring, not only detection later.

Cloud Coding Anti-Patterns to Ban

1. Fetching arbitrary URLs without allow-lists (SSRF → metadata).
2. Logging authorization tokens or full payment payloads.
3. Using wildcard IAM policies in application runtime roles.
4. Trusting client-side enforcement of tenant ID.
5. Running containers as root with writable host mounts by default.
6. Accepting unsigned webhooks without verification.
7. Storing long-lived cloud access keys in mobile or SPA clients.

Requirements → Design → Implementation Chain (Applied)

Example control: “Tenant A must not read Tenant B data.”

• Requirements: explicit isolation requirement and audit need.
• Design: tenant key in every data model; authorization service; no shared predictable IDs without checks.
• Implementation: middleware enforces tenant context from verified identity, not from request body alone.
• Testing: cross-tenant access attempts must fail (abuse tests).
• Operations: alert on authorization failure spikes and anomalous cross-tenant queries.

That chain is “apply Secure SDLC” in one sentence.

Secure Coding: ASVS and SAFECode

OWASP ASVS in Application

While Domain 4.1 uses ASVS for awareness and requirements, Domain 4.3 uses it as a coding and verification target. Teams select a level (e.g., L2 for internet-facing apps) and implement controls such as:

• Authentication and session management strength.
• Access control patterns.
• Validation and business logic controls.
• Cryptographic practices (algorithms, key storage).
• API and file handling rules.
• Configuration and error handling without information leaks.

ASVS gives reviewers a shared language: “this PR fails V4 access control requirements” is clearer than “feels insecure.”

SAFECode

SAFECode (Software Assurance Forum for Excellence in Code) publishes practical guidance and training-oriented practices for secure development in industry settings. On CCSP, treat SAFECode as a recognized secure coding / software assurance practice source alongside OWASP — vendor-neutral industry collaboration, not a single product. Use it to reinforce: secure development training, code review culture, vulnerability management, and third-party component care.

Secure Coding Habits That Survive Exam Scenarios

Secure coding is necessary but not sufficient: architecture flaws (insecure design) still require threat modeling and requirements work.

Software Configuration Management and Versioning

Software Configuration Management (CM) is the discipline of identifying, controlling, and tracking software configuration items (source, build scripts, IaC, container definitions, environment configs, and release artifacts) so that integrity, reproducibility, and auditability hold across the lifecycle.

Why CM Matters for Cloud Security

Versioning Practices

• Source version control (Git-class systems) with protected main branches and required reviews.
• Semantic or calendar versioning of releases for clear rollback targets.
• Immutable artifact versions (container digests, package versions) — avoid mutable latest in production.
• Infrastructure versioning — modules pinned; plan/apply history retained.
• Configuration versioning — separate secrets from config; version non-secret config; inject secrets at runtime.
• Database migration versioning — ordered, reviewable schema changes with rollback strategy.

CM Controls Mapped to Threats

DevSecOps Pipeline as Applied SDLC

A practical apply-SDLC flow:

1. Requirements/backlog — security acceptance criteria.
2. Design — threat model for the feature (STRIDE/ATASM as appropriate).
3. Code — ASVS/SAFECode-aligned implementation; no secrets in repo.
4. Commit/PR — automated SAST/secret scan/SCA; human review.
5. Build — reproducible build; sign artifacts; generate SBOM.
6. Deploy — policy-as-code; least privilege; progressive delivery.
7. Operate — monitor, patch, feed CVEs back as CM-controlled updates.
8. Change — every modification versioned; emergency changes still recorded.

End-to-End Exam Scenario

A fintech team builds a new lending API on PaaS. Cloud risks: multi-tenant data store (shared technology), limited OS visibility, and multi-country customers (jurisdiction). They threat model with STRIDE on the API data-flow (spoofing of partner webhooks, elevation via IAM). DREAD prioritizes webhook forgery and BOLA as top risks. Developers apply centralized authZ, signed webhooks, parameterized queries, and customer-managed keys for sensitive fields (secure coding / ASVS). CM enforces tagged releases, immutable containers, and blocked direct prod console changes. That is Domain 4.3 applied end to end.

Common Traps

• Confusing DREAD (scoring) with STRIDE (threat categories).
• Treating threat modeling as only a waterfall design document, never updating in agile.
• Believing secure coding alone fixes missing tenant isolation design.
• Using mutable tags and shared admin credentials as “configuration management.”
• Ignoring legal/residency risks when enabling global features in the name of performance.