Overview
Domain 4 covers application security from awareness to architecture. It starts with training developers on cloud development basics, common pitfalls and well-known vulnerability lists, including the OWASP Top 10 for web, API and large language model applications. It covers the secure software development life cycle (SDLC), both as a process and in practice: cloud-specific risks, threat modeling methods such as STRIDE and PASTA, secure coding and configuration management. It then covers assurance and testing (SAST, DAST, IAST, software composition analysis and abuse case testing), using verified software and securing APIs and the supply chain, cloud application architecture components such as WAFs and API gateways, and identity and access management design.
The domain exists because applications are where most customer-controlled risk sits in PaaS and SaaS-built solutions. It builds on Domain 1's design principles, protects the data from Domain 2, and feeds the operational monitoring in Domain 5.
How it's tested
Questions describe a development situation, such as a new cloud application, a CI/CD pipeline, an API exposed to partners or a third-party library issue, and ask which technique, test or component is MOST appropriate, or what should happen FIRST. Timing in the SDLC often decides the answer.
-
Right test, right stage
Choose between SAST, DAST, IAST, SCA, penetration testing and abuse case testing based on what is available and what must be found.
-
Earliest effective point
Identify the SDLC phase where an activity, such as threat modeling or setting security requirements, gives the most value.
-
Component fit
Match a protection need to a component, such as a WAF, API gateway, DAM, CASB or secrets manager, without over-crediting what it can do.
A team wants to find injection flaws in its own code before anything is deployed, and the application cannot be run yet. DAST needs a running application, and a penetration test comes later still. SCA looks at third-party components, not the team's code. SAST analyzes source code without executing it, so it fits both the goal and the stage.
Subdomains 7
Official subdomains from the ISC2 outline, in outline order.
4.1 Advocate training and awareness for application securityCloud development basics, common pitfalls and common vulnerability lists.
- What it means
- This covers teaching developers how cloud development differs, the pitfalls teams fall into, and the well-known vulnerability references: the OWASP Top 10, OWASP Application Security Verification Standard (ASVS), OWASP API Security Top 10, OWASP Top 10 for Large Language Model Applications, and the SANS/CWE Top 25.
- What to understand
- Common pitfalls include moving on-premises applications to the cloud without redesign, hard-coding secrets, trusting the network, and assuming provider defaults are secure. Training works best when it is role-specific and tied to the vulnerabilities the team actually produces.
- How it shows up
- Questions ask for the MOST effective way to reduce recurring vulnerabilities, or which reference fits a given application type, such as an API or an LLM-based feature.
- Common confusion
- Treating the OWASP Top 10 as a complete security standard. It is an awareness list. ASVS is the verification standard with testable requirements.
4.2 Describe the Secure Software Development Life Cycle (SDLC) processBusiness requirements, phases and methodologies.
- What it means
- The secure SDLC starts with business and security requirements and moves through design, coding, testing and maintenance. It applies in waterfall, where phases run in sequence, and in agile, where work is delivered in short iterations.
- What to understand
- Security requirements must be defined alongside business requirements, because fixing a design flaw after release is far more expensive than avoiding it. In agile, security work belongs in the backlog and the definition of done rather than a final gate.
- How it shows up
- Questions ask when security should FIRST be involved in a project, or how to fit security into short agile iterations.
- Common confusion
- Assuming agile cannot accommodate security controls. It changes when and how they are applied, not whether.
4.3 Apply the Secure Software Development Life Cycle (SDLC)Cloud-specific risks, threat modeling, secure coding and configuration management.
- What it means
- Applying the SDLC means accounting for cloud-specific risks such as shared technology, provider insiders, reduced visibility and jurisdiction, threat modeling with methods such as STRIDE, DREAD, ATASM and PASTA, avoiding common vulnerabilities, coding to standards such as ASVS and SAFECode guidance, and managing configuration and versions.
- What to understand
- Threat modeling is most useful during design, when changes are cheap. STRIDE categorizes threats (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), DREAD rates them, and PASTA is a risk-centric, attacker-focused process. Configuration management keeps code, infrastructure definitions and settings versioned and controlled.
- How it shows up
- Questions ask which threat modeling method fits a purpose, or when threat modeling should happen.
- Common confusion
- Mixing up STRIDE and DREAD. STRIDE identifies categories of threat, and DREAD scores how serious they are.
4.4 Apply cloud software assurance and validationFunctional and non-functional testing, security testing methods, QA and abuse case testing.
- What it means
- Assurance covers functional and non-functional testing, often automated in continuous integration and continuous delivery (CI/CD) pipelines, and security testing methods: black-box and white-box testing, static (SAST), dynamic (DAST) and interactive (IAST) application security testing, and software composition analysis (SCA). It also covers quality assurance and abuse case testing.
- What to understand
- SAST examines code without running it and finds issues early. DAST tests a running application from outside. IAST instruments a running application to combine both views. SCA identifies third-party components and their known vulnerabilities and licenses. Abuse cases test what happens when users deliberately misuse features.
- How it shows up
- A testing goal and the stage of development are given, and you must choose the method that fits.
- Common confusion
- Choosing DAST before the application can run, or SAST to find vulnerabilities in third-party libraries, which is SCA's job.
4.5 Use verified secure softwareAPI security, supply chain management, third-party software and validated open source.
- What it means
- This covers securing application programming interfaces (APIs), managing the software supply chain through vendor assessment and checks on integrity, authenticity and licensing, managing third-party software, and using open-source components that have been validated.
- What to understand
- Third-party and open-source code inherits into your application along with its vulnerabilities, so it needs inventory, integrity checks such as signature verification, and ongoing monitoring. APIs need authentication, authorization on every call, input validation and rate limiting.
- How it shows up
- A scenario describes a vulnerable library, an unsigned package or an over-exposed API, and you must choose the BEST control.
- Common confusion
- Trusting open-source components because they are popular. Popularity does not mean maintained, unaltered or free of known vulnerabilities.
4.6 Comprehend and apply the specifics of cloud application architectureSupplemental security components, cryptography, sandboxing and orchestration.
- What it means
- Cloud application architecture uses supplemental components such as web application firewalls (WAF), database activity monitoring (DAM), XML firewalls, API gateways and load balancers. It also uses cryptography, sandboxing to isolate untrusted code, and application virtualization and orchestration with microservices, containers, Docker and Kubernetes.
- What to understand
- Each component has a specific job. A WAF filters malicious HTTP traffic, an API gateway centralizes authentication, throttling and routing for APIs, and DAM monitors database queries for misuse. These add protection layers but do not replace secure code. Containers and microservices increase the number of components and interfaces that need securing.
- How it shows up
- A protection need is described and you must choose the right component, or recognize what a component cannot do.
- Common confusion
- Treating a WAF as a fix for vulnerable code. It can block known attack patterns while the underlying flaw remains.
4.7 Design appropriate Identity and Access Management (IAM) solutionsFederation, identity providers, SSO, MFA, CASB, and secrets, keys and certificates.
- What it means
- Cloud IAM design uses federated identity, where an identity provider (IdP) authenticates users for other services, single sign-on (SSO), multi-factor authentication (MFA), cloud access security brokers (CASB) for visibility and control over cloud service use, and management of secrets, keys and certificates.
- What to understand
- Common federation standards include SAML and OpenID Connect for authentication, and OAuth for delegated authorization. SSO improves usability but makes the IdP a high-value target, so it needs MFA. A CASB sits between users and cloud services to enforce policy and discover unapproved services.
- How it shows up
- Questions ask for the BEST way to give partner users access, or how to gain visibility into unapproved SaaS use.
- Common confusion
- Using OAuth as if it authenticates users. It grants delegated access, and OpenID Connect adds the authentication layer on top of it.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
SAST
Static application security testing analyzes source or compiled code without running it.
- Remember
- White-box, early in development, can produce false positives.
- Tested as
- Test selection questions.
- Trap
- Expecting it to find runtime or configuration issues.
-
DAST
Dynamic application security testing probes a running application from outside.
- Remember
- Black-box, needs a deployed application, finds runtime issues.
- Tested as
- Test selection questions.
- Trap
- Choosing it before the application can run.
-
IAST
Interactive testing instruments a running application to observe code behavior during tests.
- Remember
- Combines inside and outside views.
- Tested as
- Distinguishing test types.
- Trap
- Confusing it with SAST.
-
SCA
Software composition analysis inventories third-party and open-source components and flags known vulnerabilities and license issues.
- Remember
- It is the tool for library and dependency risk.
- Tested as
- Supply chain scenarios.
- Trap
- Using SAST to assess third-party libraries.
-
STRIDE
Spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
- Remember
- It categorizes threats, ideally during design.
- Tested as
- Threat modeling questions.
- Trap
- Treating it as a scoring method.
-
DREAD and PASTA
DREAD scores threats on damage, reproducibility, exploitability, affected users and discoverability. PASTA is a seven-stage, risk-centric threat analysis process.
- Remember
- DREAD rates, while PASTA is a full attacker-focused methodology.
- Tested as
- Method selection questions.
- Trap
- Using DREAD to identify threats.
-
Abuse case
A scenario describing how a user could deliberately misuse a feature.
- Remember
- It tests behavior that functional testing does not cover.
- Tested as
- Assurance questions.
- Trap
- Relying only on functional test cases.
-
WAF vs. API gateway
A WAF filters malicious web traffic. An API gateway manages, authenticates, throttles and routes API calls.
- Remember
- Both add protection, and neither fixes insecure code.
- Tested as
- Component selection.
- Trap
- Treating a WAF as a code fix.
-
SAML vs. OIDC vs. OAuth
SAML and OpenID Connect handle federated authentication. OAuth handles delegated authorization.
- Remember
- OIDC is an identity layer built on OAuth 2.0.
- Tested as
- Federation design questions.
- Trap
- Using OAuth alone for authentication.
-
CASB
A cloud access security broker provides visibility and policy enforcement between users and cloud services.
- Remember
- It helps discover shadow IT and enforce data policies.
- Tested as
- SaaS governance questions.
- Trap
- Confusing it with a cloud service broker.
-
OWASP LLM Top 10
OWASP's list of the most significant risks for applications built on large language models, such as prompt injection.
- Remember
- It is named in the 2026 outline alongside the web and API lists.
- Tested as
- AI-enabled application questions.
- Trap
- Assuming web application controls fully cover LLM risks.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
SAST vs. DAST vs. IAST vs. SCA
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SAST | Analyzes code without executing it | Early, white-box, sees the code | Expecting runtime issues to be found |
| DAST | Tests a running application from outside | Later, black-box, sees behavior | Running it before deployment is possible |
| IAST | Instruments a running application during testing | Combines inside and outside views | Thinking it needs no running application |
| SCA | Inventories third-party components and known vulnerabilities | Focuses on dependencies, not custom code | Using it to review your own code |
SAML vs. OpenID Connect vs. OAuth
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SAML | XML-based standard for exchanging authentication and attribute assertions | Common for enterprise web SSO | Assuming it suits every mobile or API use case |
| OpenID Connect | Identity layer on top of OAuth 2.0 | Provides authentication with ID tokens | Confusing it with plain OAuth |
| OAuth | Framework for delegated authorization | Grants access to resources, does not on its own prove identity | Using it alone to authenticate users |
STRIDE vs. DREAD vs. PASTA
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| STRIDE | Categories of threats | Identifies what can go wrong | Using it to rate severity |
| DREAD | Scoring model for threats | Rates how serious threats are | Using it to discover threats |
| PASTA | Seven-stage risk-centric threat analysis | Ties threats to business impact from an attacker's view | Treating it as a simple checklist |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
WAF as a fix
- What candidates pick
- Deploy a WAF to resolve an injection vulnerability found in testing.
- Why it looks right
- It blocks attacks quickly without code changes.
- Why it's wrong
- A WAF is a compensating layer. The vulnerability remains and can be reached by bypasses. The code must be fixed.
Clue to watch for The question asks for the BEST long-term remediation.
-
OAuth for login
- What candidates pick
- Use OAuth to authenticate users to a cloud application.
- Why it looks right
- OAuth is everywhere in sign-in flows.
- Why it's wrong
- OAuth grants delegated authorization. Authentication needs OpenID Connect or SAML.
Clue to watch for The requirement is to verify who the user is.
-
Test too late
- What candidates pick
- Rely on a penetration test before release as the main security assurance.
- Why it looks right
- It finds real, exploitable issues.
- Why it's wrong
- Design flaws found that late are expensive to fix. Threat modeling and security requirements should start in design.
Clue to watch for The question asks when security activity gives the MOST value.
-
SAST for dependencies
- What candidates pick
- Run SAST to find vulnerable open-source libraries.
- Why it looks right
- SAST is the familiar code-scanning tool.
- Why it's wrong
- SCA identifies third-party components and their known vulnerabilities and licenses. SAST focuses on your own code.
Clue to watch for The scenario mentions libraries, packages, dependencies or a newly disclosed component vulnerability.
-
Popular means safe
- What candidates pick
- Approve an open-source package because it is widely used.
- Why it looks right
- Wide use suggests scrutiny.
- Why it's wrong
- Popular packages are attractive supply chain targets. Integrity, maintenance status and known vulnerabilities still need checking.
Clue to watch for The scenario mentions an unsigned package, a new maintainer or an unverified source.
-
SSO without MFA
- What candidates pick
- Implement SSO across cloud applications as a complete access solution.
- Why it looks right
- It centralizes identity and improves usability.
- Why it's wrong
- SSO makes one credential unlock everything, so the IdP needs MFA and strong protection.
Clue to watch for The question asks about the biggest new risk of SSO.
Answer framework
Use these steps to reason through any Domain 4 application security scenario.
- Place the scenario in the SDLC, such as requirements, design, coding, testing, deployment or operation, because the stage limits what is possible.
- Identify whether the risk lies in custom code, third-party components, APIs, configuration or identity.
- Choose the technique that fits both the stage and the source of risk, for example SAST for custom code, SCA for dependencies or DAST for running behavior.
- Treat WAFs, gateways and monitoring as supplementary layers, and prefer answers that remove the underlying flaw when a long-term fix is asked for.
- Check the identity design, separating authentication from authorization and protecting central identity providers with MFA.
Practice question
Want more like this? The CCSP practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with testing in 4.4, because it generates the most precise questions. Build a table of SAST, DAST, IAST and SCA showing what each looks at, when it can run and what it finds, then practice choosing from scenarios.
Next, cover the SDLC in 4.2 and 4.3, focusing on where security activities fit and on the threat modeling methods. Be clear on which methods identify threats and which ones score them.
Then study identity in 4.7. Candidates commonly confuse OAuth with authentication, and often overlook the CASB, so give both specific attention. Supply chain and API security in 4.5 are also underestimated, and given recent industry attention to software supply chain attacks, expect scenarios around libraries and package integrity.
Finish with architecture components in 4.6, concentrating on what each component can and cannot do.
Afterwards, practice with Domain 5. Application issues found in operations, such as logs, incidents and vulnerability scans, often lead back to the development decisions covered here.
FAQ
How much of the CCSP exam is Domain 4?
Cloud Application Security carries 16% under the outline effective 1 August 2026.
Do I need to be a developer for this domain?
No. You need to understand what each practice and test is for and when it applies. Questions do not require writing code.
What is the difference between SAST and DAST?
SAST analyzes code without running it and fits early development. DAST tests a running application from outside and needs a deployed or test environment.
Are LLM applications covered?
Yes. The 2026 outline lists the OWASP Top 10 for Large Language Model Applications among the common vulnerability references.
Is OAuth an authentication protocol?
No. OAuth handles delegated authorization. OpenID Connect adds authentication on top of OAuth 2.0, and SAML is another federation standard for authentication.
What does a CASB do?
A cloud access security broker sits between users and cloud services to provide visibility, discover unapproved services and enforce policies such as data protection rules.
How does Domain 4 relate to Domain 2?
Applications are the main way users and systems reach data, so the protections in Domain 2 depend on applications enforcing access, encryption and secrets management correctly.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- Certified Ethical Hacker Same subject: Domain 8: Cloud Computing (5%)
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
Test your Domain 4 knowledge
You have covered the secure SDLC, threat modeling, testing methods, the supply chain and cloud IAM. Test whether you can pick the right technique at the right stage.