Reference · Software composition analysis
What is software composition analysis (SCA)?
Software composition analysis (SCA) is how you find out what open-source and third-party code your software is actually built from — and whether any of it carries a known vulnerability or a license you can’t ship. Modern apps are mostly other people’s code; SCA is how you keep track of the risk that comes with it.
Updated 28 Jul 2026 · by the depproof team
In one sentence: SCA inventories every dependency your project pulls in — direct and transitive — and checks each one for security vulnerabilities and license risk, so problems surface on the pull request instead of in an audit.
What SCA actually does
Two jobs, on the same dependency inventory:
- Finds known vulnerabilities. Every dependency — including the transitive ones you never chose — is checked against advisory data for known CVEs, so a vulnerable component can’t hide deep in the tree. Which database that data comes from decides what can be matched at all — OSV vs CVE. Scan Java · scan npm.
- Flags license risk. Each dependency’s license is identified and classified, so a prohibited or copyleft license that affects whether you can distribute your product gets caught early. Check Java licenses · check npm.
- Produces an SBOM. The inventory itself is emitted as a CycloneDX SBOM — the machine-readable evidence artifact compliance, procurement, and regulations increasingly require.
How SCA works
Conceptually, every SCA tool does the same three things:
- Resolve the full dependency tree. It reads your manifests and lockfiles and works out every component you actually ship — including transitive dependencies, which is where most risk hides. Accuracy here is everything: a scan is only as good as the tree under it, and a scan that found nothing may simply have read the wrong file.
- Check each component. Every dependency is matched against vulnerability advisory data and against your license policy (allowed / review / forbidden).
- Report and gate. You get a human-readable report and an SBOM — and, in CI, a pass/fail gate so a bad CVE stops the pull request rather than the release, with forbidden licenses flagged for review.
The hard part isn’t finding them. It’s knowing which ones matter.
A first SCA run on a real codebase routinely returns hundreds of findings. Nobody fixes hundreds of things. So the question that decides whether SCA is useful or just noisy is the one that comes next: which of these is actually going to hurt us?
Most teams answer it with severity — fail the build on high and critical, let the rest through. That is a reasonable default and a poor proxy. Severity describes how bad a vulnerability would be if someone exploited it. It says nothing about whether anyone is. Two better signals exist, and both are public:
- Known exploited (CISA KEV). A catalogue of vulnerabilities with confirmed, observed exploitation in the wild. Not modelled, not predicted — seen. It is a small list relative to the CVE corpus, and being on it is the strongest signal available that something needs attention now.
- Exploitation probability (EPSS). FIRST.org’s modelled probability that a vulnerability will be exploited in the next 30 days, from 0 to 1. Where KEV is binary and backward-looking, this is continuous and forward-looking.
The reason this reorders your work rather than just annotating it: 11% of the CISA KEV catalogue is rated below high, so a severity threshold lets those confirmed-exploited findings straight through. Meanwhile a high that nobody is attacking sits at the top of your queue because of a number that was assigned before anyone knew how it would be used in practice. A medium at 0.98 probability outranks a high at 0.01 — and severity alone will never tell you that.
Used as a gate rather than a report column, this changes what stops a build. depproof can fail on known-exploited status regardless of severity, or on an exploitation probability you choose, alongside the usual severity rule. Findings carry the exploitation data into the HTML report and the CycloneDX SBOM, so the evidence travels with the artifact instead of living in a dashboard. And it is fail-closed: if the exploitation data can’t be reached and a gate rule depends on it, the build stops rather than passing on data it never received — a clean result you didn’t earn is the failure mode worth designing against.
Honest scope: both signals need exploitation data supplied to the scan — in practice from the self-hosted hub, so it is served from your own infrastructure rather than a vendor API. Neither is a substitute for knowing whether the vulnerable code path is reachable in your application; that judgement is still yours, and worth recording when you make it.
SCA vs SBOM vs SAST — how they differ
These terms get mixed up constantly. The short version:
| Term | What it covers | In one line |
|---|---|---|
| SCA | Third-party / open-source dependencies | Finds vulnerabilities + license risk in code you didn’t write |
| SBOM | The inventory itself | The machine-readable list of components; SCA produces and analyzes it |
| SAST | Your own first-party source code | Finds flaws you wrote (e.g. injection) — complementary to SCA |
| DAST | Your running application | Tests the live app from the outside; not about dependencies |
SCA and SBOM are two sides of one coin — the inventory and the analysis on top of it. SAST and DAST are a different axis (your code, not your dependencies), and most mature programs run all of them.
Why SCA matters now
Three forces made SCA non-optional:
- Most of your code is open source. Typically 80–90% of a modern application is third-party dependencies — so most of your risk lives in code you didn’t write and can’t review line by line.
- Supply-chain attacks are now routine. Compromised and malicious packages, and high-blast-radius CVEs, arrive through the dependency tree — exactly what SCA is built to surface.
- Regulation now asks for it. The EU Cyber Resilience Act requires an SBOM from December 2027, US federal agencies may require one under contract, and SOC 2 reviews increasingly expect evidence that you monitor components for new vulnerabilities. SCA is how you produce that.
Per-repo vs org-wide SCA
SCA happens at two levels, and you need both:
- Per-repo — scan each project in CI and gate the build. This is the day-to-day developer workflow: catch a bad dependency on the pull request. Start with the depproof guides.
- Org-wide — aggregate every repo’s results into one view, so you can answer estate-level questions: “is this new CVE anywhere in our products, and where?” and “which repos ship a license we prohibit?” That’s the job of the depproof hub, and the substance of dependency governance.
Self-hosted vs SaaS SCA
SCA does not require sending your code to a vendor cloud. A self-hosted SCA tool runs entirely in your infrastructure — in your CI or on your machine — so your source and your findings never leave your infrastructure, and there’s no new subprocessor for a customer to vet. For regulated, data-residency-bound, and security-conscious teams, that’s the difference between a tool they can adopt and one they can’t. depproof takes that approach: open advisory data (OSV), self-hosted, and priced per product rather than per seat.
How to run SCA on your own project
SCA is a one-command build step, not a platform purchase. From here:
- Scan Java (Maven & Gradle) dependencies for vulnerabilities, scan npm, or scan Python — the security half.
- Which licenses can you ship? and the Maven / npm license checks — the license half.
- Generate a CycloneDX SBOM — the inventory artifact, on your own infrastructure.
- The depproof hub — SCA across your whole estate, not one repo at a time.
- The part that never finishes — the cadence after the first scan, and the four moments worth scanning.
- End-of-life dependencies — the second axis of risk, which no advisory feed reports.
Frequently asked questions
What is software composition analysis (SCA)?
Software composition analysis (SCA) is the practice of identifying the open-source and third-party components in your software and checking each one for known security vulnerabilities and license obligations. Because modern applications are mostly built from open-source dependencies — often 80–90% of the code you ship — SCA is how you know what is actually in your software and whether any of it is risky to use or distribute.
What does SCA stand for?
SCA stands for Software Composition Analysis. It analyzes the “composition” of your application — the inventory of open-source and third-party components it is built from — rather than your own source code.
What is the difference between SCA and SAST?
SAST (static application security testing) analyzes your own first-party source code for security flaws you wrote — things like SQL injection or insecure patterns. SCA analyzes the third-party dependencies you did not write, checking them for known vulnerabilities (CVEs) and license risk. They are complementary: SAST covers your code, SCA covers everyone else’s that you ship.
Is SCA the same as an SBOM?
No, but they are closely related. An SBOM (software bill of materials) is the inventory — a machine-readable list of every component in your software. SCA is the analysis performed on that inventory: checking each component against vulnerability data and license policy. A good SCA tool produces an SBOM (e.g. CycloneDX) as part of the scan.
How do you prioritise SCA findings — KEV and EPSS?
Severity alone is a weak prioritiser: it says how bad a vulnerability would be if exploited, not whether anyone is exploiting it. Two public signals answer that better. CISA KEV is a catalogue of vulnerabilities with confirmed exploitation observed in the wild — binary, and the strongest available signal that something needs attention now. EPSS, from FIRST.org, is a modelled probability from 0 to 1 that a vulnerability will be exploited in the next 30 days. Because many actively exploited vulnerabilities are rated only medium, a severity threshold lets them through, while a high that nobody is attacking sits at the top of the queue. Used as a CI gate rather than a report column, these reorder the work: depproof can fail a build on known-exploited status regardless of severity, or on an exploitation probability you set. Neither replaces knowing whether the vulnerable code path is reachable in your application.
Does SCA check open-source licenses?
Yes — license risk is half of what SCA is for. Beyond security vulnerabilities, SCA identifies each dependency’s license and flags obligations or restrictions, such as strong-copyleft licenses (GPL, AGPL) that can affect whether you can ship proprietary software. Detecting a prohibited or copyleft license before release is a core SCA outcome.
Can SCA run self-hosted, without sending code to a vendor cloud?
Yes. SCA does not require a SaaS. A self-hosted SCA tool runs on your own infrastructure — in your CI or on your machine — so your source code and findings never leave it, and there is no new subprocessor to vet. That is the model regulated and security-conscious teams prefer.
depproof is a self-hosted SCA tool — free for open source and teams under $1M revenue. See pricing. Product and standard names are used nominatively.