What is software composition analysis (SCA)?

How SCA works

1. Identify the components. The tool reads what it is pointed at: manifests and lockfiles in a repository, installed packages, or the contents of a container image or binary. The result is an inventory of components and versions, often exported as an SBOM.
2. Match them against known risks. Each component is looked up in vulnerability databases such as the GitHub Advisory Database, OSV and the NVD, and its declared license is checked against your policy.
3. Prioritize. Findings are ranked by severity, and some tools add reachability analysis to check whether your code can call the vulnerable function at all.
4. Fix. Many tools suggest a fixed version or open a pull request, the way Dependabot and Renovate do. For a vulnerable transitive dependency, the fix is usually in the package that pulls it in, which a dependency graph shows.

What SCA finds

• Known vulnerabilities in the versions you use, with the advisories that describe them.
• License risk, such as a copyleft license in a proprietary product.
• Outdated and unmaintained packages that will not get security fixes.
• Malicious packages, in tools that also analyze how packages behave rather than only matching advisories.

SCA vs SAST

SCA and static application security testing (SAST) are often sold together, but they look at different code and answer different questions.

	SCA	SAST
What it analyzes	The open source and third-party components you depend on	The code your team writes
What it finds	Known vulnerabilities, license issues, outdated packages	Flaws in your code, such as injection or unsafe input handling
What it reads	Manifests, lockfiles, installed packages, images or binaries	Source code
What makes a finding new	A dependency change, or a new advisory for a version you already ship	A change to your code
Typical output	Vulnerable components with fixed versions, and an SBOM	Code locations with the flaw and a suggested fix

You need both. A codebase with no SAST findings can still ship a vulnerable dependency, and a clean dependency tree says nothing about your own code. One difference matters for how you run them: a SAST finding appears when your code changes, while an SCA finding can appear on a release you shipped months ago, the day a new advisory is published.

Where SCA stops

Every SCA result depends on step one: identifying the components. A component the tool never identified cannot be matched, prioritized or fixed, and it does not show up as a gap either. The common blind spots:

• What the files do not say. Most SCA tools read manifests and lockfiles. A missing or stale lockfile, packages restored from CI caches, build tools, downloads and install scripts never reach the inventory. See why a lockfile is not a record of what shipped.
• Tools disagree. Two scanners pointed at the same commit return different component lists, because each has its own rules for what to read and how to name it. See what open source SBOM generators miss.
• Binaries. Software distributed as a prebuilt binary declares little or nothing a manifest reader can see.
• Known vulnerabilities only. Matching finds what has been published. A new malicious package or an undisclosed flaw has no advisory yet.
• A snapshot. A scan in a pull request describes that moment. New advisories for versions already in production need something that keeps checking what shipped.

This is not a flaw in one product. It is how scanning works, commercial or open source. CRACI has found vulnerable packages that Snyk and Aikido did not report, because the components were never in what they scanned.

Record the build, keep your SCA

CRACI closes the identification gap from the build side. It is a GitHub Actions runner that records every package each job fetches, at every depth of the tree and including packages restored from CI caches, into an SBOM that states its own completeness. It keeps re-evaluating the SBOMs of what shipped as new vulnerabilities are published, and build history shows which past builds contained a vulnerable package.

CRACI does not do SAST or reachability analysis, by design. Teams run it next to an SCA or SAST tool that covers pull requests and their own code. See SCA tools compared, where CRACI fits next to your SCA tools, or book a demo to compare a recorded SBOM with your current scan.

Software composition analysis: frequently asked questions

What is SCA in cyber security?

Software composition analysis (SCA) is the practice of finding the open source and third-party components in your software and checking them for known vulnerabilities, license issues and outdated versions. It covers the code you depend on, as opposed to the code you write.

What is the difference between SCA and SAST?

SAST analyzes the code your team writes for flaws such as injection bugs. SCA analyzes the components you depend on for known vulnerabilities and license issues. They answer different questions, so most security programs run both.

What does SCA scanning mean?

An SCA scan reads a project's manifests, lockfiles, installed packages or a container image, works out which components are in it, and matches them against vulnerability and license data. The result is a list of findings, often with an SBOM of the components it identified.

Is an SBOM the same as SCA?

No. An SBOM is an inventory: the list of components in a release. SCA is the analysis: identifying components and checking them for risk. Many SCA tools produce an SBOM along the way, and an SBOM can feed vulnerability monitoring after the release.

What are the limitations of SCA?

It only analyzes the components it can identify, usually from manifests and lockfiles. Packages restored from CI caches, build tools, downloads and binaries without package metadata can be missed. It finds known vulnerabilities, not unknown ones, and a scan is a snapshot unless the tool keeps re-checking what shipped.

What are the best SCA tools?

It depends on what you need beyond the basics: reachability analysis, malicious package detection, license policy or developer workflow. See our comparison of 13 SCA tools for what each covers and where it stops.