What Is Software Composition Analysis (SCA)? A 2026 Guide

Direct answer

Software composition analysis resolves your full dependency tree from lockfiles, matches every resolved package version against vulnerability advisory databases, and checks licence compatibility. It covers the code you imported rather than the code you wrote, which is where most of your line count and most of your weaponized, publicly documented risk lives. The feature that separates useful SCA from a CVE firehose is reachability analysis. Verified 2026-10-19.

What is software composition analysis?

Direct answer: SCA is automated scanning of the open-source and third-party dependencies in your project, direct and transitive, for known vulnerabilities, licence risk and outdated versions. It reads lockfiles rather than source, matches against CVE and ecosystem advisory feeds, and the good implementations add reachability analysis to rank findings by whether your code executes them. Verified 2026-10-19.

Where a linter checks the code you wrote, SCA checks the code you imported - the packages your application pulls from npm, PyPI, Maven, NuGet, crates.io, Go modules and the rest.

This matters because most of your application is not yours. Once you resolve the transitive tree, the third-party line count typically dwarfs your own by a wide margin in JavaScript and Python projects specifically, where the dependency graph fans out hardest. When a vulnerability like Log4Shell surfaces in a library millions of projects depend on, the question every engineering team scrambles to answer is “are we affected, and where?” SCA answers that question continuously instead of during a fire drill.

For a compact reference definition see our software composition analysis glossary entry. This guide goes further: how SCA actually works, how transitive resolution breaks, what SBOM formats you will be asked for, why reachability changes the economics, and what it costs in 2026.

How SCA works, step by step

SCA is conceptually simple and the details are where tools differ in quality.

1. Build the dependency graph. The scanner reads manifests and, critically, lockfiles - package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, Pipfile.lock, go.sum, Cargo.lock, pom.xml with its resolved tree - and produces the full set of resolved versions including transitive packages you never installed directly.
2. Match against advisory databases. Each resolved package and version is compared against known issues keyed by CVE identifiers plus ecosystem-specific advisory feeds (GHSA, PyPA, RustSec, OSV). Database freshness is a genuine differentiator.
3. Check licences. Dependencies under licences that conflict with policy get flagged - a copyleft GPL package inside a proprietary product, or an unlicensed package with no declared terms at all.
4. Prioritize. Better tools do not stop at “this package has a CVE.” They apply severity scoring, exploit-maturity signals, and increasingly reachability analysis to tell you which findings actually matter.
5. Remediate. The best tools open a pull request bumping the vulnerable package to a fixed version, so the fix lands in your normal review flow and gets tested by CI.
6. Monitor continuously. New CVEs are disclosed daily against dependencies you already shipped. PR-time scanning alone misses every one of them.

SCA is only as good as its dependency resolution and its database. A scanner that ignores transitive dependencies or lags on new disclosures gives you false confidence, which is worse than no scanner because it produces a green check.

Where transitive resolution actually breaks

This is the part vendor documentation glosses over, and it is where you should push during an evaluation:

Failure mode	Why it happens	How to test for it
Manifest-only scanning	Tool reads package.json, not package-lock.json	Ask it to show the dependency path from your code to a deep package
Monorepo workspace confusion	npm/pnpm/Yarn workspaces hoist and dedupe differently	Point it at a workspace repo and check the per-package attribution
No lockfile in the repo	Libraries often commit no lockfile by design	Ask what the tool does when there is no lockfile - best answer is “resolve and tell you it is an estimate”
Vendored or bundled code	A dependency shipped as a minified bundle has no manifest at all	Check whether the tool does binary or file-hash matching
Container base-image layers	OS packages are a different ecosystem entirely	Verify container scanning is in scope, or price it separately
Build-time plugins	Gradle plugins and build scripts pull code that never lands in the runtime tree	Ask whether build-scope dependencies are reported separately

The monorepo case is the one that catches teams most often. We cover the broader pattern in AI code review for monorepos and AI code review on large codebases.

SCA vs SAST vs the rest of the AppSec alphabet

Direct answer: SAST scans your source for flaws you wrote. SCA scans your dependency tree for flaws you inherited. DAST probes a deployed app from outside for runtime and config flaws. Secrets scanning scans code and git history for committed credentials. Four different surfaces, four different failure modes, and no two of them substitute for each other. Verified 2026-10-19.

Technique	What it analyzes	Catches	Example finding	Needs running app
SCA	Resolved dependency tree	Known CVEs, licence risk in imported code	Vulnerable lodash version reachable from your request handler	No
SAST	Your own source, bytecode or binary	New flaws you wrote, via taint analysis	SQL injection in your query builder	No
DAST	A deployed, running application	Runtime, deployment and config flaws	Exposed admin endpoint, missing HSTS header	Yes
IAST	Running app, from inside via an agent	Confirmed-reachable code flaws	Taint path proven to execute during a test run	Yes
Secrets scanning	Code and git history	Committed credentials	AWS key in a config file, three commits back	No

The crucial distinction is SCA versus SAST. SAST finds vulnerabilities you introduced; SCA finds vulnerabilities you inherited. A team that runs only SAST is blind to the majority of its actual attack surface, because most code in the build is third-party and because those vulnerabilities come with published, weaponized exploits. For the full side-by-side on the dynamic half see SAST vs DAST, and for the static field generally see best SAST tools 2026.

One commercial note that shapes buying decisions: these are usually separately priced modules, not one product. Semgrep Teams charges Code $30, Supply Chain $30 and Secrets $15 per contributor per month (verified 2026-10-18). Snyk splits Snyk Code from Snyk Open Source. Budget accordingly, because “we bought Semgrep” does not mean you bought SCA.

The false-positive problem, and how reachability solves it

Direct answer: Naive SCA flags every package with any published CVE, which on a mid-sized codebase surfaces hundreds of alerts that never execute. Reachability analysis asks a better question - does our code call the vulnerable function on a path that runs - and that reordering is the difference between a usable gate and alert fatigue. Verified 2026-10-19.

Alert fatigue is not a soft problem. It has a hard failure mode: the team sets the check to non-blocking, then stops reading it, then misses the one critical finding that was real. The sequence is predictable enough to plan around.

Reachability analysis is the single most important advance in modern SCA. Instead of asking “does this package have a known vulnerability,” it asks “does our code actually call the vulnerable function on a path that runs.” A CVE in a code path you never invoke is a far lower priority than one your request handler hits on every call.

Three honest notes on the numbers:

• Semgrep states that Supply Chain dataflow reachability reduces false positives by up to 98% compared with a plain dependency alert. That is a vendor figure. No party without a commercial stake has replicated it (checked 2026-10-19).
• Aikido claims a 95% reduction in alert volume from its AI AutoTriage. Also vendor-stated and unreplicated.
• No independent benchmark compares SCA precision across vendors on a shared corpus, as far as we can establish on 2026-10-19. The OpenSSF CVE Benchmark dataset is independent, but the only published run on it is DeepSource’s own self-winning one across 165 CVEs. Do not present that as an independent evaluation.

So: ask about reachability, prefer tools that have it, and treat every percentage reduction as a marketing number until somebody neutral measures it. Our AI code review tools with low false positives page applies the same scepticism to the review layer.

Reachability is not binary

Vendors use “reachability” for at least three different things, and the depth varies:

Depth	What it proves	Cost
Package presence	The vulnerable package is in the tree	Free, this is Dependabot’s level
Symbol reachability	Your code imports or references the vulnerable symbol	Cheap, mostly static import analysis
Dataflow reachability	A path exists from your code into the vulnerable function	Expensive, needs interfile dataflow
Runtime reachability	The path was observed executing	Needs an agent in production or a strong test suite

When a vendor says “reachability”, ask which row. Symbol reachability and dataflow reachability differ enormously in both accuracy and price, and interfile dataflow is the expensive capability that sits behind the paywall almost everywhere. Semgrep’s interfile analysis requires the proprietary Pro engine; Semgrep CE cannot do interfile at all (verified 2026-10-18).

What is an SBOM and which format should I use?

Direct answer: An SBOM is a machine-readable inventory of every component in a build with versions, licences and ideally hashes. Two formats dominate: SPDX, Linux Foundation origin and an ISO/IEC standard, favoured by legal and licence teams; and CycloneDX, OWASP origin, more security-oriented with first-class vulnerability and VEX support. Most SCA tools export both. Ask the requester which they parse. Verified 2026-10-19.

SBOM requests arrive from three directions now: enterprise customers in procurement, regulated-sector contracts, and your own incident response when you need to answer “are we affected” in minutes rather than days.

Format	Origin	Strength	Typical requester
SPDX	Linux Foundation, also an ISO/IEC standard	Licence fidelity, long-standing legal acceptance	Legal, open source compliance, procurement
CycloneDX	OWASP	Security focus, native vulnerability and VEX support, broader component types	Security teams, vulnerability management

A few practical points that matter more than the format choice:

• An SBOM generated at build time from the resolved graph is accurate. One generated from a manifest is a guess. Generate it in CI from the same lockfile your SCA tool reads, and attach it to the release artifact.
• VEX is the companion document that most teams forget. A Vulnerability Exploitability eXchange statement is how you say “this CVE is in our SBOM but it is not exploitable in our product, and here is why.” Without it, every customer who scans your SBOM opens a support ticket about a finding you already triaged.
• An SBOM is a point-in-time snapshot. It ages the moment you ship. Version it with the artifact and regenerate on every release.

What does SCA cost in 2026?

Direct answer: Snyk Free is 5 projects and 100 Snyk Code tests per month; Team runs to 100 projects and 1,000 tests per month; enterprise is now a prepaid credit subscription at 1 credit = $1. Semgrep Supply Chain is $30 per contributor per month on Teams, separate from Code at $30 and Secrets at $15. Aikido prices flat from $300/mo for 10 users. Dependabot alerting is free. Verified 2026-10-18.

Tool	SCA tier	Price	Key limit
GitHub Dependabot	Alerts + update PRs	Free on all repos	No reachability, no licence policy, no SBOM policy gating
Snyk Open Source	Free	$0	5 projects; 100 Snyk Code tests/mo
Snyk	Team	Per contributing developer	100 projects, 1,000 tests/mo
Snyk	Enterprise	Prepaid credits, 1 credit = $1	Snyk Code metered at 1.0 credit per active contributor per day
Semgrep Supply Chain	Free	$0	10 contributors, 10 private repos, 60 AI credits
Semgrep Supply Chain	Teams	$30 per contributor/mo	Modular: Code $30 and Secrets $15 are priced separately
Aikido	Basic	$300/mo flat, 10 users	Pro $600; Advanced $600 + 100 credits. Deep PR Review is Advanced+ and consumes credits
Codacy	Team	$18/dev/mo yearly ($21 monthly)	Up to 30 devs; Developer tier free forever
Checkmarx	Enterprise	Quote only	Part of the wider AppSec suite

All figures verified 2026-10-18 against vendor pricing pages. Two cautions: the frequently quoted “Snyk Ignite $1,260/yr unlimited projects” figure is third-party sourced and not on Snyk’s plans page - do not state it as fact. And only three vendors in our sweep publish an enterprise rate card at all (Snyk, Gitar, Entelligence); 12 of 15 enterprise tiers are quote-only, which is itself a finding. See Snyk pricing, Semgrep pricing and the AI code review price book 2026.

Which review tools bundle SCA

You do not always need a standalone SCA product. Several platforms fold dependency scanning into a broader workflow, which is often the easier adoption path because findings show up on the pull request.

Snyk is the most complete developer-first option. Snyk Open Source handles SCA with reachability and licence compliance and can auto-open a pull request to upgrade a vulnerable dependency, sitting alongside Snyk Code (SAST), Container and IaC scanning. Pricing moved to a prepaid credit platform subscription for enterprise in 2026, with 1 credit equal to $1 and Snyk Code metered at 1.0 credit per active contributor per day (verified 2026-10-18). One deployment caveat worth repeating: Snyk Broker is an outbound tunnel to Snyk’s cloud, not on-premise deployment. If your requirement is that code never leaves your network, a broker does not satisfy it. See what Snyk Code is, Snyk vs Semgrep and Snyk vs Dependabot.

Semgrep offers Semgrep Supply Chain, whose reachability-first design is the strongest false-positive story on the market by its own account. It pairs naturally with Semgrep’s SAST rules if you already run Semgrep in CI. Same deployment caveat: Semgrep’s Network Broker is a WireGuard tunnel to Semgrep’s cloud, not on-prem. And Semgrep Inc. is explicitly not ISO 27001 certified per its own documentation (verified 2026-10-18; the docs URL returned 404 when we re-checked on 2026-10-19, so treat as vendor-stated), which contradicts several aggregator profiles listing it as PCI, HIPAA, FedRAMP, ISO and CSA STAR compliant.

Aikido takes the all-in-one route, bundling SCA with SAST, secrets detection, IaC and container scanning behind one interface. It prices flat rather than per seat - Basic $300/mo for 10 users, Pro $600, Advanced $600 plus 100 credits - and its Deep PR Review is Advanced-tier only and consumes credits (verified 2026-10-18). Aikido holds ISO/IEC 42001:2023, and notably its certificate scope explicitly covers “Deep PR Review” - the only certification scope in this market that names a review feature. Its “FedRAMP Certified: Class C (Moderate)” claim, however, is not standard FedRAMP terminology and we could not verify it.

Checkmarx covers SCA as part of its enterprise AppSec suite, aimed at regulated organizations needing deep, auditable coverage across SAST and SCA together. See Checkmarx pricing.

Does AI code review cover dependency vulnerabilities?

Direct answer: No, and do not plan around it. An LLM can notice an unmaintained package or an odd pin in a diff, but it cannot resolve a transitive tree and diff it against a continuously updated advisory feed - that is a data problem, not a reasoning problem. No AI reviewer we track publishes a measured known-CVE detection rate. Verified 2026-10-19.

This is worth stating plainly because the marketing blurs it. AI reviewers advertise “security review”, and they do find real security bugs - missing authorization checks, weakened permission boundaries, business-logic flaws. Those are reasoning tasks. Dependency vulnerability detection is a lookup task against a database that changes daily, and an LLM’s training cutoff makes it structurally the wrong tool.

What the AI layer genuinely adds on the dependency surface:

• Noticing that a new dependency is added for a trivial function that already exists in the codebase.
• Flagging a dependency name that resembles a popular package (typosquat shape).
• Questioning why a version was pinned backwards or a lockfile was deleted.

What it does not do: tell you that transitive-package@2.1.3, four levels deep, has a critical advisory published this morning. Run SCA as a deterministic check. See AI code review for security vulnerabilities and how AI code review tools work for the architectural reasons.

A practical adoption plan

Rolling out SCA well is a workflow problem more than a tooling problem. A pattern that works:

1. Start in CI, non-blocking, for two to four weeks. Report rather than block so you can measure signal quality on your actual codebase before anyone’s merge is affected.
2. Turn reachability on before you turn gating on. Gating on raw CVE counts will drown the team. Gate on reachable, high-severity findings only.
3. Gate new code, baseline the rest. The same ratchet that works for technical debt works here: existing findings become a tracked backlog, and CI fails only on newly introduced ones. Politically cheap, monotonically improving.
4. Fix by upgrade, not by suppression. Prefer the version bump the tool suggests. Reserve ignore rules for genuinely unreachable findings, and require a comment and an expiry date - an undated suppression is permanent.
5. Track licence findings separately. Licence risk is a legal concern with a different owner and a different urgency. Mixing it into the security gate makes both worse.
6. Generate the SBOM in the same CI job. Same lockfile, same resolved graph, attached to the release artifact. Add VEX statements for findings you have triaged as non-exploitable.
7. Monitor after merge. Continuous monitoring, not just PR-time scanning, is what catches the next Log4Shell on day one rather than day nine.

Treat SCA as a continuous, reachability-filtered gate on your dependency tree, not a one-time audit. The dependencies you shipped last month are still your responsibility this month.

How do you handle a vulnerable transitive dependency you cannot upgrade?

Direct answer: Upgrade the direct parent first - that is the clean fix and is usually possible. Failing that, override the resolved version with npm overrides, Yarn resolutions, pip constraints or Maven dependencyManagement, and test hard. Failing that, document unreachability with evidence and accept the risk with an expiry date. Vendoring or forking is the last resort. Verified 2026-10-19.

The second option deserves a warning. When you force a transitive version with overrides or resolutions, you are running a dependency combination that nobody upstream has tested. It usually works. When it does not, the failure is subtle and shows up in production. Pin it, test it properly, and add a ticket to remove the override once the parent catches up.

The third option is where reachability evidence pays for itself. “We accept this because the vulnerable function is unreachable from our code, per the dataflow analysis attached” is an auditable decision. “We accept this because upgrading is hard” is not.

Common mistakes

• Scanning manifests instead of lockfiles. You will miss most of the tree.
• Gating on raw CVE presence. Guaranteed alert fatigue, and then a green check nobody reads.
• Treating licence findings as security findings. Different owner, different urgency, different remediation.
• Suppressing without a date. Every undated suppression is permanent by accident.
• Skipping container base images. OS packages are a separate ecosystem and often the largest CVE count in the report. See Snyk Docker scanning.
• Scanning only at PR time. New disclosures land daily against code you already shipped.
• Accepting “broker” as “on-prem”. Snyk Broker and Semgrep’s Network Broker are tunnels to the vendor cloud.
• Assuming the AI reviewer has this covered. It does not, and no vendor publishes a number saying it does.

How we verified this

Checked on 2026-10-19: internal link targets against the live content tree in this repository. We attempted to re-verify Semgrep’s compliance statement at both semgrep.dev/docs/trust-and-security and the redirect target docs.semgrep.dev/trust-and-security; both returned HTTP 404, so the ISO 27001 negative is labelled vendor-stated and carried from 2026-10-18 rather than re-confirmed today.

Carried from the 2026-10-18 verification pass, read directly from vendor pricing and documentation pages:

• Snyk Free at 5 projects and 100 Snyk Code tests per month; Team at 100 projects and 1,000 tests per month; the move to a prepaid credit platform subscription at 1 credit = $1 with Snyk Code metered at 1.0 credit per active contributor per day. Also that the “Ignite $1,260/yr unlimited projects” figure is third-party sourced and absent from Snyk’s plans page.
• Semgrep Teams modular pricing: Code $30, Supply Chain $30, Secrets $15 per contributor per month. Semgrep Free at 10 contributors and 10 private repos with 60 AI credits. Interfile analysis requiring the proprietary Pro engine, and Semgrep CE being unable to do interfile at all.
• Semgrep Network Broker and Snyk Broker both being outbound tunnels to the vendor cloud rather than on-premise deployment.
• Aikido flat pricing (Basic $300/mo for 10 users, Pro $600, Advanced $600 + 100 credits), Deep PR Review being Advanced-tier and credit-consuming, Aikido’s ISO/IEC 42001:2023 certificate scope naming “Deep PR Review”, and its non-standard “FedRAMP Certified: Class C (Moderate)” wording.
• Codacy Team at $18/dev/mo yearly, Developer free forever.

Vendor claims we report but did not independently verify:

• Semgrep’s “up to 98% false-positive reduction” from Supply Chain reachability. Vendor-stated, unreplicated.
• Aikido’s “95% alert volume reduction” from AI AutoTriage. Vendor-stated, unreplicated.

What we could not verify:

• No independent benchmark compares SCA precision or recall across vendors on a shared corpus (checked 2026-10-19). The OpenSSF CVE Benchmark dataset is independent but the only published run on it is DeepSource’s own self-winning 165-CVE evaluation - that is not an independent evaluation of SCA tools.
• No AI code reviewer publishes a measured detection rate for known-CVE dependencies.
• The frequently cited “70 to 90 percent of a modern application is third-party code” range appears across industry reporting but we could not trace it to a primary measurement we would stand behind, so this version of the page describes the fan-out qualitatively instead. An earlier version of this article stated the 70-90% figure; we have removed it.
• SBOM format adoption shares. We describe which audiences tend to request SPDX versus CycloneDX from practice, not from a survey we can cite.

Disclosure: Gitar is a paid sponsor of aicodereview.cc and was acquired by Sonar in May 2026. Gitar does not appear in this article’s recommendations because it does not ship SCA.

Recommendations

Criteria: tree-resolution accuracy, reachability depth, cost at your size, and whether findings arrive early enough to be cheap.

If you have no security budget at all: turn on Dependabot alerts and automated security updates. It is free on every GitHub repository, it resolves the real tree, and it opens the version-bump PR. It has no reachability, no licence policy and no gating, and it is still the single highest-return free thing available. Add npm audit or pip-audit in CI as a crude second signal.

If you are a team of 10 or fewer on private repos: Semgrep Free (10 contributors, 10 private repos) gives you SCA and SAST from one tool and one config, which matters more at small scale than any individual feature. Snyk Free’s 5-project cap bites almost immediately in a multi-repo setup.

If you are 20 to 200 engineers: pay for reachability. Semgrep Supply Chain at $30 per contributor per month or Snyk Open Source on Team. The deciding question is whether you also want SAST from the same vendor, because the config and triage overhead of running two platforms is real and usually underestimated.

If you want one dashboard and hate per-seat maths: Aikido’s flat pricing from $300/mo for 10 users is the clearest all-in-one option, with the caveat that its Deep PR Review sits on the Advanced tier and consumes credits. Verify its FedRAMP wording before it enters a compliance document.

If you are regulated and need auditable, on-premise analysis: Checkmarx, and be rigorous about rejecting broker architectures presented as on-prem. Ask, in writing, where analysis executes. See AI code review for regulated teams.

What to ask every vendor, in order: which row of the reachability table do you implement; show me the dependency path from my code to a flagged deep package; what happens when there is no lockfile; is container scanning in scope or priced separately; and where does analysis execute.

Further reading

• What Is Snyk Code? Features, Pricing, and Real-World Assessment
• SAST vs DAST - What Is the Difference?
• Best SAST Tools in 2026
• Snyk vs Semgrep
• Snyk vs Dependabot
• AI Code Review for Security
• Supply Chain Security - glossary definition