Cloud Application Security · Topic 3 of 6
Cloud Software Assurance and Validation
CCSP software assurance: functional and non-functional testing in CI/CD, black box and white box, SAST, DAST, IAST and SCA, QA and abuse case testing.
- 5 min
- Functional tests check features; non-functional tests check qualities including security.
- SAST is static and white box; DAST is dynamic and black box; IAST instruments the running app.
- SCA finds known vulnerable and badly licensed components and produces an SBOM.
What it is
Software assurance is the confidence that software is free from exploitable flaws and works as intended. Validation proves it through testing: functional tests check that features work, non-functional tests check qualities such as performance and security, and security testing looks for weaknesses an attacker could use.
In the cloud, most of this testing runs automatically in the CI/CD pipeline on every change.
How it works
Functional and non-functional testing
| Type | Question it answers | Examples |
|---|---|---|
| Functional | Does it do what it should? | Unit, integration, regression, user acceptance tests |
| Non-functional | Does it do it well enough? | Performance, load, scalability, availability, usability, security |
Security is mostly non-functional, but some security features, such as "a locked account cannot log in", are tested functionally.
Testing in CI/CD
Continuous integration (CI) merges and tests code changes frequently, running automated tests on every commit. Continuous delivery (CD) keeps the software always ready to release, and continuous deployment releases automatically when tests pass.
Security in the pipeline:
- Fast checks (SAST, secrets scanning, SCA) run on every commit.
- Slower checks (DAST, IAST) run against a deployed test environment.
- Policy gates fail the build on critical findings.
- Infrastructure as code templates are scanned before they create resources.
- The pipeline itself is protected: restricted access, signed artefacts, no secrets in build logs.
Black box and white box testing
| Approach | Tester knowledge | Strength |
|---|---|---|
| Black box | No internal knowledge; tests from outside like an attacker | Realistic view of exposed weaknesses |
| White box | Full access to code and design | Thorough coverage of logic and paths |
| Gray box | Partial knowledge, such as user credentials or architecture | Balances realism and depth |
Security testing methodologies
| Method | How it works | Finds | Limits |
|---|---|---|---|
| SAST | Analyses source or compiled code without running it | Injection patterns, unsafe functions, hardcoded secrets, early in development | False positives; misses runtime and configuration issues |
| DAST | Attacks the running application from outside | Runtime flaws, misconfiguration, authentication issues | Needs a running app; limited code location detail |
| IAST | Agents inside the running application observe code while tests run | Confirmed flaws with code location, fewer false positives | Needs instrumentation; language support varies |
| SCA | Inventories open source and third-party components | Known vulnerable versions, licence conflicts; produces an SBOM | Only finds known issues in components |
SAST is white box and early; DAST is black box and late; IAST combines both views; SCA looks at what you did not write.
Quality assurance
Quality assurance (QA) is the process that makes sure the software meets defined requirements and standards, including security requirements. QA owns test plans, entry and exit criteria and sign-off, and confirms that security findings are fixed or formally accepted before release. Security belongs inside the QA definition of "done", not beside it.
Abuse case testing
A use case describes how a legitimate user achieves a goal. An abuse case (or misuse case) describes how someone could misuse the same function to cause harm. Testing abuse cases checks that the application resists them.
| Use case | Abuse case | Test |
|---|---|---|
| Customer resets password by email | Attacker requests resets for many accounts | Rate limiting and no account enumeration in responses |
| User uploads a profile picture | Attacker uploads a script file | File type validation, storage outside web root, malware scan |
| Customer views own invoice | Customer changes the invoice ID | Object level authorization returns access denied |
Abuse cases come from threat modeling and give testers concrete, attacker minded scenarios.
A worked example
An e-commerce team releases several times a day. A recent incident came from a vulnerable version of an image processing library. Their pipeline ran unit tests and SAST only.
They add SCA to every build, failing it on critical known vulnerabilities, and generate an SBOM for each release. A weekly DAST scan becomes a nightly scan in the test environment, and IAST agents run during integration tests. Abuse cases from the threat model, such as coupon reuse, are added as automated tests.
How the exam asks about this
- "Which testing method identifies known vulnerabilities in open source libraries?" Software composition analysis.
- "Which method analyses code without executing it, early in development?" SAST.
- "Testers design scenarios in which a user tries to apply a discount code repeatedly. What is this?" Abuse case testing.
What to remember for the exam
- Functional tests check features; non-functional tests check qualities including security.
- SAST is static and white box; DAST is dynamic and black box; IAST instruments the running app.
- SCA finds known vulnerable and badly licensed components and produces an SBOM.
- CI/CD runs fast checks on every commit and gates release on critical findings.
- Abuse cases turn threat models into attacker minded tests.
Passing automated scans is not proof of security. Business logic flaws, such as skipping a payment step, are rarely found by SAST or DAST and need abuse case and manual testing.
Common mistakes
Picking DAST for code level flaws early in development. DAST needs a running application; SAST is the early, code level method.
Forgetting third-party code. Most of an application is open source components, which only SCA reviews.
Separating QA from security. Security requirements should be part of QA exit criteria.
Check yourself
What is the difference between SAST and DAST?
SAST examines source or compiled code without running it, while DAST tests the running application from the outside.
What does IAST add over SAST and DAST?
It instruments the running application, confirming exploitable flaws during tests and pointing to the exact code location, with fewer false positives.
What is an abuse case?
A description of how a function could be misused by an attacker, used to design tests that confirm the application resists that misuse.
Topic 3 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.