What is SCA? Software composition analysis, explained
SCA identifies every third-party component your software contains, including the transitive dependencies you never chose directly, then matches them against known vulnerabilities and classifies their licenses. Since most of a modern codebase is other people's code, SCA covers the majority of your software by volume.
SCA, software composition analysis, answers a deceptively simple question: what is actually inside your software? Modern applications are assembled more than written; the majority of a typical codebase is open-source and third-party components, pulled in through package managers, resolved through layers of transitive dependencies, and updated on schedules nobody fully controls. SCA makes that inherited codebase visible and accountable.
The three questions SCA answers
Which components, exactly? Real SCA resolves the complete dependency graph: direct dependencies, their dependencies, and so on down, with exact versions and the paths that pulled each one in. The graph matters as much as the list: when a vulnerable component surfaces, the path tells you which direct dependency to upgrade, which is why flat inventories fail audits.
Which known vulnerabilities? Each identified component is matched against vulnerability databases. Volume is the challenge: mature applications match hundreds of CVEs, most of them irrelevant in practice. Useful SCA therefore carries prioritization signals with each finding: severity, exploitation likelihood, known-exploited status, and ideally reachability, so the queue starts with what attackers actually use.
Which licenses? Every component arrives under a license, and some licenses carry obligations that matter commercially. License classification across the full graph, including the messy compound and vendored cases, is the half of SCA that legal teams and acquirers care about most.
Where the hard parts hide
The difference between SCA tools shows up in the corners: lockfile-less legacy projects, vendored code copied into the repository, components inside container images and binaries, and ecosystems with unusual resolution rules. An engine that only reads clean, modern lockfiles inventories the easy majority and silently misses exactly the components most likely to be stale and vulnerable. Honest tooling also declares what it could not resolve rather than presenting partial coverage as complete.
SCA as an ongoing practice
The scan is a snapshot; the risk moves. New vulnerabilities are disclosed against old components continuously, which means yesterday’s clean report ages without anything in your code changing. The mature pattern is inventory-plus-monitoring: SBOMs stored per release and re-evaluated automatically as vulnerability data updates, so “are we affected by this new CVE” is answered from records in minutes.
SecuDep is SecuNexa’s SCA engine: complete dependency graphs across ecosystems, exploitation-aware vulnerability matching against signed offline data, and SPDX-aware license classification, all running entirely inside your network.
Frequently asked questions
What is the difference between SCA and SAST?
SAST analyzes the code your team wrote for flaws in its own logic. SCA analyzes the code you imported: which components, which versions, which known vulnerabilities, and which licenses. A modern application is mostly imported code, so the two together cover the whole codebase.
What are transitive dependencies and why do they matter?
Dependencies of your dependencies, resolved automatically and often invisible to developers. They typically outnumber direct dependencies several times over, and they carry vulnerabilities and license obligations exactly as if you had chosen them yourself. SCA without full transitive resolution misses most of the actual risk.
How does SCA relate to an SBOM?
The component inventory SCA builds is exactly what a software bill of materials formalizes. Good SCA tooling emits the SBOM as a standard artifact, and good SBOM practice keeps that inventory monitored as new vulnerabilities are disclosed.