Software Composition Analysis (SCA)

Software Composition Analysis inventories the third-party and open-source components inside an application, then maps each one to known vulnerabilities and licence obligations. Modern software is mostly assembled rather than written: a typical codebase pulls in hundreds of libraries, each dragging in transitive dependencies of its own. SCA tools read build manifests and binaries to produce that inventory, commonly expressed as a software bill of materials (SBOM), and alert when a component gains a newly published CVE.

The distinction that matters is whose code is being tested. Static analysis finds undiscovered flaws in code your team wrote; SCA finds known, already published vulnerabilities in code you imported. That makes SCA the application-layer arm of supply chain risk management: when the next Log4Shell-class flaw lands, the SBOM answers “are we exposed, and where” in minutes instead of weeks. Licence findings matter too, because a copyleft licence can impose obligations on proprietary code.

Exam relevance: if a scenario mentions a vulnerable open-source library, an SBOM, or knowing what components ship inside a product, the answer is SCA. The confusable term is SAST, which inspects your own source for undiscovered flaws; SCA checks a component list against databases of flaws that are already public. A mature pipeline needs both, running side by side.