Knowledge base

What is software composition analysis (SCA)?

If an SBOM is the inventory of what your software is made of, software composition analysis is what reads that inventory and tells you where the risk is.

6 min read · Updated June 26, 2026

What SCA is

Software composition analysis (SCA) is tooling that identifies the open-source and third-party components in a codebase and analyzes them for risk. OWASP frames it as a focused form of component analysis covering three things: known vulnerabilities, license compliance, and operational risk such as unmaintained or outdated packages.

How it works

SCA starts by building an inventory, often an SBOM, from your manifests, lockfiles, or built artifacts. Then it matches each component against two kinds of reference data:

Vulnerability databases to flag known security flaws. The standard sources are the NIST National Vulnerability Database (NVD), the GitHub Advisory Database, and OSV (osv.dev), Google’s open vulnerability database.
License metadata to flag obligations and policy violations, like copyleft components or a banned AGPL dependency.

The transitive-dependency problem

The reason you need a tool and not a spreadsheet is that most components are transitive: pulled in indirectly by the packages you actually chose. A project with a handful of direct dependencies routinely resolves to hundreds of total packages. SCA follows that whole graph, which is where the vulnerabilities and surprise licenses usually live.

Reachability: signal over noise

A naive scan reports every known vulnerability in every dependency, which buries teams in alerts. The important refinement is reachability: a vulnerability only matters if your code can actually reach the flawed function. Modern SCA prioritizes findings by whether the vulnerable path is invoked, so engineering fixes what is exploitable instead of chasing everything.

VEX: is it actually exploitable?

Closely related is VEX, the Vulnerability Exploitability eXchange. A VEX document is a companion to an SBOM that states whether a product is actually affected by a given vulnerability, with statuses like Not Affected, Affected, Fixed, or Under Investigation. If the SBOM is the ingredient list, the VEX is the note that says "yes this contains the recalled ingredient, but in a form that is not harmful here."

SCA and SBOM are not the same thing

It is worth being precise: the SBOM is the noun (the inventory), and SCA is the verb (the analysis that acts on it). You can generate an SBOM with a free tool and never analyze it. The ongoing work of ingesting SBOMs, checking them against vulnerability and license policy on every build, and prioritizing the results is what platforms such as FOSSA provide on top of the raw document.

Frequently asked questions

What is software composition analysis?

SCA is tooling that finds the open-source and third-party components in your software and analyzes them for known vulnerabilities, license compliance, and operational risk such as unmaintained packages.

How is SCA different from an SBOM?

An SBOM is the inventory of components. SCA is the analysis performed on that inventory: matching components to vulnerability databases and license policy and prioritizing the findings. The SBOM is the data; SCA is what makes it actionable.

What databases does SCA use to find vulnerabilities?

The common sources are the NIST National Vulnerability Database (NVD), the GitHub Advisory Database, and OSV (osv.dev). Tools cross-reference your components against these to flag known flaws.

What is reachability analysis?

Reachability analysis checks whether your code actually calls the vulnerable function in a dependency. If the flawed path is never reached, the vulnerability can be deprioritized, which cuts the noise so teams fix what is genuinely exploitable.

Keep reading

The SBOM lifecycle: before and after the document Most coverage of SBOMs stops at "here is how you generate one." Generating it is the cheap part. This walks the full lifecycle, because the value is on either side of the document. What is an SBOM? A Software Bill of Materials is a complete, machine-readable inventory of everything your software is built from. Here is what that means, what goes in one, and why it has become a requirement rather than a nice-to-have. How to implement FOSSA: a setup and CI-gating checklist Standing up software composition analysis is less about the scan and more about the gate. This walks the full path on a real repository: connect, read the first scan, set policy, and wire CI so a bad dependency cannot be merged. Every step here was run on this site.

Sources

Part of the software supply-chain field notes on this site. Written by Antoni K Pestka.