What Is SCA? Software Composition Analysis and Why 99% of Alerts Do Not Matter

A typical enterprise SCA scan returns hundreds of vulnerable dependencies. Security teams triage for hours. Most findings are never exploited. This is not a tooling problem. It is a fundamental limitation of how Software Composition Analysis works, and understanding it is the first step to cutting through the noise.

This article covers what SCA is, how it works, what it finds, where it falls short, and how runtime SCA resolves the noise problem. If you are new to the broader topic, vulnerability scanning provides useful background on how automated security scanning fits into an AppSec program.

Key Takeaways

• SCA (Software Composition Analysis) identifies open source and third-party components in a codebase and checks them against CVE databases.
• 90-97% of commercial applications consist of open source components (Sonatype and Black Duck data).
• SCA produces a Software Bill of Materials (SBOM) and flags CVEs, license violations, and outdated packages.
• The core limitation: SCA confirms a library is present but cannot confirm whether the vulnerable function is ever executed at runtime. As a result it cannot verify whether the vulnerability poses an actual risk to the application
• Runtime SCA resolves this by identifying whether vulnerable functions are actually executed within the application, reducing actionable CVE findings by 99%.

What Is SCA?

Software Composition Analysis (SCA) is an automated security methodology that identifies open source and third-party components in a codebase and matches them against vulnerability databases to detect known CVEs, license compliance issues, and outdated dependencies.

Why SCA Exists

Between 90% and 97% of commercial applications consist of open source components. Dependency trees commonly include hundreds of transitive packages, layers of libraries that your direct dependencies pull in without you explicitly choosing them. Manual tracking became impossible at this scale, and SCA was developed to automate the process.

The key distinction to establish early: SCA tells you a component is vulnerable. It does not tell you whether that vulnerability is exploitable in your specific deployment.

How SCA Works

SCA tools follow a structured pipeline to assess every dependency in a project:

1. Discovery — Reads package manifests (package.json, requirements.txt, pom.xml, go.sum) and identifies direct and transitive dependencies.
2. Component identification — Matches packages against vulnerability databases such as the NVD, OSS Index, and GitHub Advisory Database.
3. CVE matching — Correlates package versions against known vulnerability entries.
4. Licence analysis — Identifies licenses and flags compliance conflicts, such as GPL code used inside a proprietary commercial product.
5. SBOM generation — Produces a Software Bill of Materials listing all components and their versions.
6. Prioritization — Ranks findings by CVSS severity score, and in some cases by EPSS and KEV status.
7. Reporting — Delivers findings to a developer dashboard or CI/CD pipeline.

It is worth noting that both static/manifest scanning (reads dependency files) and binary/dynamic scanning (scans compiled artifacts) still operate pre-deployment, not in production.

What SCA Finds

Security Vulnerabilities

SCA surfaces known CVEs in both direct and transitive open source dependencies. When CVE-2021-44228 (Log4Shell) was published, SCA tools immediately identified every application that included log4j-core versions 2.0-2.14.1. However, SCA could not determine whether those applications actually received user-controlled input that was logged via log4j, which was the actual attack condition required for exploitation.

License Compliance Issues

SCA flags open source licences that conflict with the project type. A common example is GPL-licensed code appearing inside a proprietary commercial product, which can create significant legal exposure.

Outdated Dependencies

SCA identifies packages with available security patches and marks deprecated packages that no longer receive maintenance updates.

The Core Limitation: SCA Cannot Tell You What Executes

Presence vs. Execution

SCA confirms a vulnerable library exists in the codebase. It cannot confirm whether the vulnerable function is ever called at runtime.

Reachability

Even if a function is present in a dependency, it may only be exploitable if user-controlled input can reach it through a specific call path. SCA has no view of execution paths in production. A library can be loaded, a vulnerable function can exist, and the risk can still be effectively zero because no code path ever reaches it.

CVE Noise at Scale

In enterprise applications with hundreds of dependencies, a typical SCA scan produces hundreds of high and critical findings. The majority are in functions never called at runtime. Security teams spend significant time triaging findings that present no real risk, pulling attention away from vulnerabilities that actually matter.

The best way to know which vulnerabilities are actually exploitable is to monitor which functions execute at runtime.

Runtime SCA: SCA at the Moment of Execution

Runtime SCA addresses the noise problem that traditional SCA cannot solve on its own.

Traditional SCA matches library versions against CVE databases. It runs pre-deployment or on a schedule. It cannot assess runtime exploitability.

Runtime SCA monitors live production execution. It shows which vulnerable functions are actually called. It correlates that data with CVE information to surface only findings where the vulnerable function is actively executed.

The result: instead of hundreds of flagged CVEs, the team sees only findings where the library is loaded, the vulnerable function is called, and the call path is reachable from external input.

Raven's Runtime SCA monitors production execution and shows which vulnerable functions actually run, reducing CVE noise by 99%. For more on this approach, see runtime security.

SCA vs SAST: Which Do You Need?

SAST (static application security testing) scans first-party code you wrote. SCA scans third-party libraries you use. These are different attack surfaces with no overlap.

Both are needed for complete pre-production coverage. Neither, on its own, provides runtime exploitability context.

For a full breakdown of where each tool fits, see the SAST vs SCA comparison.

Conclusion

SCA identifies known CVEs in open source dependencies and is essential in any modern AppSec program. Its fundamental limitation is that it cannot tell you which vulnerabilities are actually exploitable in production. Runtime SCA resolves this by monitoring live execution and reducing CVE noise by 99%.

See how Raven's Runtime SCA shows which vulnerable functions actually execute, so your team focuses only on real risk.

‍