Cloud Application Security · Topic 2 of 6
The Secure SDLC and Threat Modeling
CCSP secure SDLC: business requirements, phases, waterfall vs agile, cloud risks, STRIDE, DREAD, ATASM and PASTA, secure coding and versioning.
- 5 min
- Security requirements come from business, legal and risk requirements and must be testable.
- Every phase has security activities; in agile they live in each sprint.
- STRIDE classifies threats; DREAD scores them; PASTA is seven stage and risk centric; ATASM walks architecture to mitigations.
What it is
The secure software development life cycle (SDLC) builds security activities into every phase of development, from requirements to maintenance. Applying it in the cloud means accounting for cloud-specific risks, modeling threats early, coding securely and controlling every change to code and configuration.
The principle is simple: the earlier a flaw is caught, the cheaper and more complete the fix.
How it works
Business requirements
Security requirements start from business requirements: what data the application handles, which laws and contracts apply, the needed availability, and the organization's risk appetite. They are written as testable statements, for example "all administrative functions require MFA", and include non-functional requirements such as logging, performance under attack and data location.
Phases and security activities
| Phase | Security activities |
|---|---|
| Requirements | Security and privacy requirements, compliance needs, abuse cases |
| Design | Threat modeling, secure architecture review, choice of trusted components |
| Code | Secure coding standards, peer review, static analysis, secrets scanning |
| Test | Security testing (SAST, DAST, IAST, SCA), abuse case tests |
| Deploy | Hardened configuration, infrastructure as code scanning, approvals |
| Maintain | Patching, monitoring, vulnerability management, secure decommissioning |
Waterfall and agile
| Methodology | How it works | Security fit |
|---|---|---|
| Waterfall | Sequential phases, each finished before the next | Clear security gates; slow to react to new threats |
| Agile | Short iterations delivering working software | Security must be built into each sprint: security stories, definition of done, automated tests |
DevSecOps extends agile by automating security tests in the CI/CD pipeline. Security requirements become backlog items, not a final phase.
Cloud-specific risks
| Risk | What it means for developers |
|---|---|
| Shared technology issues | Flaws in shared hypervisors, runtimes or libraries affect many tenants |
| CSP insider threats | Provider staff with privileged access; reduce exposure with customer managed encryption |
| Lack of visibility and control | Limited access to platform logs and internals; design own application logging |
| Legal and jurisdiction issues | Where data and processing happen decides which laws apply |
| Multi-tenancy in the application | Every query must enforce the tenant boundary |
Threat modeling
Threat modeling identifies what can go wrong in a design before code is written.
| Model | What it does |
|---|---|
| STRIDE | Classifies threats: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege |
| DREAD | Scores a threat on Damage, Reproducibility, Exploitability, Affected users, Discoverability |
| ATASM | Architecture, Threats, Attack Surfaces, Mitigations: understand the architecture, list threats, find attack surfaces, choose mitigations |
| PASTA | Process for Attack Simulation and Threat Analysis: a seven stage, risk centric method linking business objectives to attack simulation |
STRIDE maps each threat to a property it violates:
| Threat | Property violated |
|---|---|
| Spoofing | Authentication |
| Tampering | Integrity |
| Repudiation | Non-repudiation |
| Information disclosure | Confidentiality |
| Denial of service | Availability |
| Elevation of privilege | Authorization |
Avoiding common vulnerabilities during development
- Validate all input on the server side; encode output for its context.
- Use parameterized queries to prevent injection.
- Enforce authorization on every request and every object.
- Use vetted libraries for cryptography and authentication instead of writing your own.
- Fail securely, with generic error messages and detailed internal logs.
- Keep secrets out of code; read them from a secrets manager at run time.
Secure coding standards
OWASP ASVS gives verifiable requirements developers can code to. SAFECode, an industry forum, published fundamental practices for secure software development covering design, coding, testing and vulnerability response. Organizations combine these into their own coding standard and enforce it through review and automated tools.
# Parameterized query: user input is passed as data, not as SQL text
cursor.execute("SELECT * FROM orders WHERE customer_id = %s", (customer_id,))Software configuration management and versioning
All source code, infrastructure templates and configuration live in version control. Changes go through reviewed pull requests, builds are reproducible, releases are tagged with versions, and production runs only approved versions. This gives traceability from every running component back to the change and the person who approved it, and allows fast rollback.
A worked example
A team designs a multi-tenant SaaS invoicing service. In a STRIDE session they find that tenant ID is taken from a request parameter, which allows elevation of privilege across tenants, and that invoice changes are not logged, which allows repudiation.
They change the design so tenant ID comes only from the authenticated token, add an audit log for invoice changes, and record both as security requirements with tests. DREAD scoring puts the tenant flaw first because damage and affected users are both high.
How the exam asks about this
- "In which SDLC phase is threat modeling MOST effective?" Design.
- "A user denies submitting a transaction and no log can prove otherwise. Which STRIDE category applies?" Repudiation.
- "Which threat modeling method is a seven stage, risk centric process?" PASTA.
What to remember for the exam
- Security requirements come from business, legal and risk requirements and must be testable.
- Every phase has security activities; in agile they live in each sprint.
- STRIDE classifies threats; DREAD scores them; PASTA is seven stage and risk centric; ATASM walks architecture to mitigations.
- Parameterized queries and server side validation prevent injection.
- Version control and reviewed changes give traceability and rollback.
In multi-tenant applications, never trust a tenant identifier supplied by the client. Derive it from the authenticated session, or one tenant can read another's data.
Common mistakes
Leaving security to the test phase. Design flaws found in testing are expensive to fix and often patched badly.
Confusing STRIDE with DREAD. STRIDE names the type of threat; DREAD rates how serious it is.
Changing production by hand. Manual changes bypass review and version control and break traceability.
Check yourself
Which STRIDE threat violates integrity?
Tampering, the unauthorized modification of data or code.
How is security handled in agile development?
Security requirements become backlog items, each sprint's definition of done includes security checks, and tests are automated in the pipeline.
Why does software configuration management support security?
It ties every running component to a reviewed, versioned change, providing traceability and the ability to roll back.
Topic 2 of 6 in Cloud Application Security
Test yourself on Cloud Application Security
The full ISC2 CCSP question bank has 900 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISC2. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.