CCSP Cloud Application Security Practice Question
A company is adopting DevSecOps and wants to incorporate security testing into their continuous integration pipeline. They have decided to run SAST (static analysis) and SCA (software composition analysis) tools. Which of the following is the PRIMARY reason for including SCA in addition to SAST?
⚠ Common exam trap
ISC2 often tests the distinction between SAST (custom code analysis) and SCA (third-party dependency analysis), and the trap here is that candidates may confuse SCA with DAST or think SCA can reduce SAST false positives, when in reality SCA addresses a completely different attack surface—open-source library vulnerabilities.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
To identify known vulnerabilities in third-party libraries and dependencies
SCA (Software Composition Analysis) is specifically designed to identify known vulnerabilities in third-party libraries and dependencies by comparing their versions against public vulnerability databases like the National Vulnerability Database (NVD) or OWASP Dependency-Check. SAST (Static Application Security Testing) analyzes custom source code for security flaws but cannot inspect external libraries that are often pulled in via package managers (e.g., npm, Maven, pip). Including SCA ensures that the organization addresses supply chain risks, which is a primary goal in DevSecOps pipelines.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
To detect insecure runtime behavior
Why it's wrong here
SCA inventories open-source dependencies and flags known CVEs in third-party libraries; it does not observe executing code, so runtime behaviour falls to DAST or RASP. It is tempting because SCA does surface vulnerable components, but the stem asks what SAST alone cannot cover — third-party library risk, not runtime detection.
- ✓
To identify known vulnerabilities in third-party libraries and dependencies
Why this is correct
SAST analyses your own source code for coding flaws, so it cannot detect risks inside compiled third-party packages. SCA inventories dependencies and maps them to known CVE databases, satisfying the stem's requirement to cover libraries pulled into the CI pipeline.
- ✗
To reduce false positives identified by SAST
Why it's wrong here
SCA correlates dependency versions against vulnerability databases; it neither analyses your source nor tunes SAST findings, so false-positive reduction is not its function. It is tempting because both tools run in the same pipeline stage, but triage of SAST alerts is achieved through rule tuning and baseline suppression, not composition scanning.
- ✗
To scan for vulnerabilities in custom APIs
Why it's wrong here
SCA examines declared third-party components and their versions, not first-party code, so custom APIs are outside its scope; SAST itself covers proprietary source. It is tempting because SCA does find vulnerabilities, but those sit in imported libraries, whereas custom API flaws require source analysis of your own code.
Go deeper
Related to this question
About these practice questions
This CCSP question is part of Courseiva's 934-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CCSP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCSP exam.