Software Composition Analysis (SCA)
What it is
Software Composition Analysis (SCA) inventories the open-source and third-party components your application is built from and analyzes each one for security vulnerabilities, licenses, and outdatedness. It answers both “what exactly is in my software?” and “are any of those components risky or non-compliant?”
Why it exists
Modern apps are 80%+ pre-built components, not your code. That brings two risks SCA manages:
- Security — components carry vulnerabilities that become your exposure.
- Legal/compliance — every OSS component has a license (MIT, Apache-2.0, GPL, proprietary) with obligations you must honor; and corporate policy may ban certain licenses.
Key ideas
- Bill of Materials (SBOM) — SCA builds and tracks an inventory of components + versions + licenses.
- Vulnerability scanning — cross-reference each package against CVE/advisory feeds → flag risky versions (overlaps dependency-vulnerabilities).
- License governance — detect licenses, flag copyleft (e.g. GPL) or banned ones, and block them per policy.
- Outdated / deprecated components — report components past their supported/patched life.
- Transitive dependencies — scans the full dependency graph, not just direct references.
- Feed a compliance gate — policy violations (critical CVE, banned license) can fail the build/release.
Distinct from vulnerability scanning
Vulnerability scanning is the security health view (“is this package patched?”). SCA is the broader governance view — adds license and inventory (bill of materials) on top of vulnerability detection.
Example tools
Mend (WhiteSource) · Synopsys Black Duck · FOSSA · OWASP Dependency-Check (open source) · Azure-hosted Open Source compliance scanning with Azure Artifacts.
How it fits
The “software + supply chain” pillar of shift-left analysis: alongside SAST (your code) and DAST (runtime), SCA owns components/licenses. Its output gates the release via a compliance gate and pairs with dependency management for feeds/versioning strategy.
Exam notes
- SCA = components + licenses + vulnerabilities (governance) vs vuln scanning = just patch state vs SAST = your code — memorize the three-way split.
- License question (e.g. “a GPL component isn’t allowed”) is an SCA concern.
- SCA output → compliance gate fails the build on critical vulnerability or banned license.
- Related exam skill-measured phrase: “manage … open-source and third-party dependencies” — part of security/compliance.
Related
dev-sec-ops · dependency-vulnerabilities · dependency-management · static-analysis · compliance-gate