SCA identifies the open-source libraries your application depends on and checks each one against known vulnerabilities and licence obligations.
The short answer
Software composition analysis builds an inventory of every third-party component in your codebase, including the ones you never chose directly, and reports which have published vulnerabilities and which carry licence terms you may not want. Most of a modern application is imported code, so most of its known vulnerabilities arrive this way.
On this page
The dependencies you did not choose
You add a handful of libraries. Each of those pulls in its own, and so on. The result is a tree where the code you selected is a small fraction of the code you ship, and where most vulnerabilities sit several levels down.
What SCA reports
| Output | Why it matters |
|---|---|
| Component inventory | Every library and version actually present, direct and transitive |
| Known vulnerabilities | Matches against CVE and advisory databases, with severity |
| Licence obligations | Copyleft terms that can affect how you distribute your product |
| Upgrade path | The version that resolves the issue, and which direct dependency to bump |
| Component age | Unmaintained packages, which are a risk even with no CVE today |
Prioritising what to upgrade
An SCA report on a mature codebase will list more findings than any team can act on at once. Severity alone is a weak filter, for the same reason it is weak elsewhere: it describes the vulnerability, not your exposure.
Is it reachable?
A vulnerable function your code never calls is far less urgent than one on a request path.
Is it being exploited?
Presence in the known exploited catalogue moves a finding straight to the top.
Is a fix available?
A finding with no patched version needs a different response: replace, isolate, or compensate.
How Osto runs code security
Osto’s code security module covers SCA alongside SAST, SBOM generation and open-source licence compliance, so dependency findings, code findings and the component inventory come from one place. Because the platform also runs the WAF and vulnerability testing, a dependency finding can be assessed against whether the affected path is exposed in production rather than in isolation.
Free security assessment
Know what is actually in your build
Osto covers SCA alongside SAST, SBOM generation and open-source licence compliance, with findings read against production exposure.
Get a free security assessment Book a platform walkthroughDirect and transitive coverage · Licence checks · One platform, everything
Frequently asked questions
What does SCA stand for?
Software composition analysis. It identifies the third-party and open-source components in a codebase and checks them against known vulnerability databases and licence terms.
What is a transitive dependency?
A library pulled in by another library rather than chosen by you. Most dependencies in a modern application are transitive, and a large share of dependency vulnerabilities sit among them.
How is SCA different from SAST?
SAST analyses code your team wrote. SCA analyses code you imported. They find different classes of problem and neither substitutes for the other.
Why does SCA report licences?
Open-source components carry terms. Some copyleft licences impose obligations on how you distribute software that includes them. Enterprise buyers and investors increasingly ask for a licence position during due diligence.