Software composition analysis (SCA) is the practice of automatically identifying every open-source and third-party component inside an application — including transitive dependencies four or five layers deep — and cross-referencing them against known vulnerability, license, and malware databases. A single modern web application can pull in 150-800 open-source packages once transitive dependencies are counted, yet fewer than 10% of those packages are ever directly imported by a developer's own code. SCA software scans manifests (package.json, pom.xml, requirements.txt, go.mod), lockfiles, and compiled artifacts to build a dependency tree, match each entry against sources like the National Vulnerability Database and OSV.dev, and flag components carrying known CVEs, copyleft licenses, or signs of tampering. The 2021 Log4Shell vulnerability (CVE-2021-44228), buried three to four levels deep in dependency trees at companies like Cloudflare and Amazon, is the textbook example of why manual dependency tracking fails at scale and why SCA became a baseline security control rather than an optional add-on.
What Does SCA Software Actually Scan?
An SCA tool scans your dependency manifests, lockfiles, and built artifacts to enumerate both direct and transitive open-source components, then checks each one against vulnerability and license databases. For a Node.js project, that means parsing package.json and package-lock.json (or yarn.lock, pnpm-lock.yaml); for Java, it's pom.xml or build.gradle plus resolved dependency trees; for Python, requirements.txt, Pipfile.lock, or pyproject.toml. Mature tools go further and scan container images and binaries directly, using techniques like file hashing and language-specific package fingerprinting to identify components even when no manifest is present — this matters because a 2023 Chainguard survey found that roughly 30% of production containers include software that never appears in any build manifest. Once the inventory is built, the tool queries sources such as the NVD, GitHub Advisory Database, and OSV.dev, then correlates matches with version ranges (not just package names) to reduce false positives from version-agnostic matching.
Why Do 90%+ of Application Codebases Now Contain Open-Source Code?
Because building anything competitive from scratch is no longer economically rational — Synopsys's 2024 Open Source Security and Risk Analysis (OSSRA) report found open-source code in 96% of the 1,067 commercial codebases it audited, with an average of 526 open-source components per application. Teams reach for battle-tested libraries for logging (Log4j, Winston), serialization (Jackson, Newtonsoft.Json), HTTP handling (Axios, Requests), and dozens of other common tasks rather than writing and maintaining that code themselves. The tradeoff is that every one of those 526 components is a piece of someone else's code running in your production environment, maintained on someone else's timeline, with someone else's security posture. The same OSSRA report found that 74% of audited codebases contained at least one high-risk open-source vulnerability, up from 48% the year prior — the dependency count keeps climbing faster than teams can triage it manually.
How Is SCA Different from SAST?
SCA (software composition analysis) analyzes third-party and open-source code you didn't write, while SAST (static application security testing) analyzes the proprietary code your own developers wrote. A SAST scanner looks for insecure patterns in your source — SQL string concatenation, hardcoded secrets, missing input validation — by parsing your codebase's abstract syntax tree. An SCA scanner doesn't care about your code's logic at all; it cares about which versions of which packages you've pulled in and whether those specific versions carry known CVEs, malicious code, or license terms (like AGPL or SSPL) that could create legal exposure. The two are complementary, not substitutes: a 2023 GitLab DevSecOps survey found that 39% of organizations run both SCA and SAST in their pipeline, but only 22% run SCA alone, reflecting that most security teams now treat first-party and third-party risk as separate problems requiring separate tooling.
Why Do Most SCA Alerts Never Get Fixed?
Most SCA alerts never get fixed because traditional SCA tools flag every CVE-matched package regardless of whether the vulnerable code path is ever actually called by the application, producing alert volumes teams can't realistically triage. Endor Labs' 2023 research on real-world Java and JavaScript projects found that only around 15-20% of dependencies flagged as vulnerable were reachable — meaning the vulnerable function was actually invoked, directly or transitively, from application code. The other 80%+ sat in unused code paths, dead imports, or dependencies included for a single unrelated function. When a security team is handed 400 open CVE alerts across a codebase and told 4 are exploitable, human nature (and finite engineering time) means most alerts get triaged into a backlog and never closed — a 2022 ESG survey found the median enterprise had a backlog of over 100,000 unresolved vulnerability findings across all tool categories combined.
What Should You Look for in an SCA Tool in 2026?
The three capabilities that separate modern SCA tools from 2015-era scanners are reachability analysis, native SBOM support, and automated remediation. Reachability analysis traces whether a flagged vulnerability sits on a code path your application actually executes, cutting genuine fix queues down to the fraction of alerts that matter. Native SBOM support means the tool can both generate a CycloneDX or SPDX bill of materials for your own releases and ingest SBOMs from vendors and upstream suppliers — a requirement that moved from "nice to have" to contractual obligation after Executive Order 14028 and the resulting NTIA minimum-elements guidance pushed SBOM delivery into U.S. federal software procurement starting in 2022. Automated remediation matters because identifying a vulnerable dependency and actually bumping it (without breaking a transitive constraint elsewhere in the tree) are different problems; tools that can open a working pull request with the minimum safe version bump remove the last-mile friction that keeps fixes stuck in backlogs.
How Safeguard Helps
Safeguard's SCA runs reachability analysis on every dependency it flags, so instead of a wall of CVE IDs, your team gets a ranked list of vulnerabilities that are actually callable from your application's code paths — typically cutting alert volume by 80% or more. Griffin AI, Safeguard's reasoning engine, correlates each reachable finding with your specific usage pattern and drafts the fix, including edge cases like transitive version conflicts that would otherwise block a naive upgrade. Safeguard generates CycloneDX and SPDX SBOMs automatically on every build and can ingest SBOMs from vendors and upstream suppliers to extend visibility past your own repositories. When a fix is available, Safeguard opens an auto-fix pull request with the minimum version bump needed to resolve the issue, tested against your build, so the last mile from "detected" to "merged" doesn't require a manual triage session.