Software Composition Analysis used to be straightforward. A tool walked your package manifest, matched versions against a CVE database, and produced a list. By 2024 that approach generated so many false positives that most AppSec teams started ignoring the output. Next-gen SCA, the category label that emerged in 2025 and crystallized in 2026, is the industry's response to the failure mode. This post explains what actually changed and what to look for if you are buying or replacing tooling.
The core insight is that a CVE on a dependency does not equal risk. Risk requires that the vulnerable code be reachable from your application's execution paths, that the affected configuration be active in production, and that the exploit be either available or imminent. Traditional SCA ignored all three. Next-gen SCA tries to evaluate each of them, with varying degrees of rigor depending on the vendor.
What does reachability analysis actually mean?
Reachability is the marquee feature of the new generation and the term gets used loosely. Honest reachability analysis walks the call graph of your application, plus its direct and transitive dependencies, and determines whether the specific vulnerable function or class is on a path reachable from your application's entry points. Snyk, Endor Labs, Semgrep, and a few others ship some form of this. The technique requires per-language tooling because the call graph for a JVM application is fundamentally different from the call graph for a Go binary, and most vendors are stronger in some languages than others. Java and Python coverage is generally good; Go, Rust, and C++ are inconsistent. A vendor pitch that claims uniform reachability across all languages should be tested on your actual code before you sign.
How does runtime context change prioritization?
Runtime context adds the question of whether the vulnerable code is actually loaded and exercised in production, which is a stronger signal than static reachability. eBPF-based runtime sensors from vendors like Oligo, Rad, and ARMO observe which library functions are invoked under real traffic. The findings often surprise teams: a dependency that looks critical in the SBOM is actually loaded by a code path that has not executed in eight months, while a low-severity finding sits in a hot loop that runs millions of times per day. In our work with a fintech customer last quarter, runtime context reduced their actionable SCA queue from 4,800 findings to 312 in a week. That is not a marketing number; it is what happens when you stop scoring vulnerabilities you do not run.
What is the role of exploit signal in next-gen SCA?
Exploit signal is the third leg. CISA KEV, EPSS, and commercial threat intelligence feeds tell you which CVEs are actually being exploited in the wild or are likely to be exploited within 30 days. A next-gen SCA tool should fuse exploit signal with reachability so that a reachable CVE on KEV is your top priority and a reachable CVE with EPSS below 1% can wait for the next sprint. The math gets interesting when you weight these together. The teams that did this rigorously in 2025 patched 60 to 80% fewer CVEs than peers running CVSS-only prioritization and had fewer incidents, because they were patching the right ones. Volume of patches is not the goal; correct sequencing is.
How do next-gen SCA tools handle transitive dependencies?
Transitive depth is where the older tools fall apart. A typical Node.js application has 4 to 7 levels of transitive dependencies and a package tree of 800 to 2,000 unique versions. Tag every transitive CVE as a finding and you produce a queue nobody will ever drain. Next-gen tools differentiate transitive findings by whether the calling code path actually invokes the vulnerable function, which usually filters out 90% or more of transitive noise. Lockfile-aware analysis, lockfile reconstruction from container layers, and SBOM ingestion at multiple build stages all matter here. The vendors who treat the SBOM as a first-class input rather than a side-channel are the ones producing usable results.
What should buyers ask vendors in 2026?
Three questions cut through the marketing. First, ask for a live demo on your own codebase, specifically asking the tool to identify the reachable subset of CVEs in a real repository and explain its reasoning. Vendors who can show the call graph traces are doing the work; vendors who hand-wave are not. Second, ask how the tool handles language coverage gaps. A vendor that admits Go reachability is weaker than Java reachability is being honest; one that claims parity in every language is selling. Third, ask how the tool integrates with your CI to enforce policy. A scanner that finds issues but cannot block a PR is a dashboard, not a control.
How Safeguard Helps
Safeguard built reachability, runtime context, and exploit signal into a single decision layer rather than three siloed features. Griffin AI fuses call-graph analysis from ingested SBOMs with runtime evidence from your deployed services and exploit feeds from KEV and our zero-day intelligence, producing a ranked queue your team can actually drain. Policy gates enforce thresholds in CI, blocking PRs that introduce reachable critical CVEs while letting unreachable lows through with a note. TPRM extends the same scoring to your suppliers, so you understand which third parties are introducing reachable risk into your stack. Next-gen SCA without the operational loop is still a list; Safeguard closes the loop end to end.