CVE Triage Prioritization Using SBOM Reachability Analysis
Reachability analysis cuts through vulnerability noise by tracing which flaws actually execute.
Security analysts in 2026 are spending their mornings patching vulnerabilities that will never be triggered by a single line of running code, while exploitable flaws sit untouched in the same queue. CVE triage built around CVSS scores alone has stopped working, because the volume of disclosures has outrun every team's capacity to review them, and the government infrastructure that used to enrich those scores no longer covers most of what gets published. This piece covers why that breakdown happened, what CVSS can and cannot tell a security team, and how reachability analysis, layered on top of a properly built SBOM, turns an unworkable backlog into a list a team can actually act on.
Why CVE triage stopped working in 2026
Every analyst who has worked a vulnerability queue in the past two years recognizes the feeling of chasing a critical-severity finding for hours, only to discover the affected function is never called anywhere in the application. That wasted effort used to be an annoyance. It is now the default outcome of CVSS-only triage, because the number of CVEs flowing into that queue has grown far faster than any team's ability to work through them. The Cloud Security Alliance's April 2026 compliance playbook puts a number on that growth: CVE submissions rose 263% between 2020 and 2025, and first-quarter 2026 submissions ran roughly a third higher than the same period a year earlier. That curve has been climbing for five straight years with no sign of flattening, rather than reflecting a seasonal spike or a one-time reporting anomaly.
The institutional response to that curve arrived on April 15, 2026, when NIST formally restructured the National Vulnerability Database, moving it from a service that tried to enrich every submitted CVE into a risk-based triage queue that enriches only three categories: CVEs listed in the CISA Known Exploited Vulnerabilities catalog, CVEs affecting software used inside the U.S. federal government, and CVEs involving "critical software" as defined under Executive Order 14028 [16][1][2][3][4][9]. NIST set a goal of one business day for enrichment of KEV records specifically. Every other CVE still gets ingested, but it now carries the tag "Lowest Priority, not scheduled for immediate enrichment." NIST also stopped duplicating work where a CVE Numbering Authority has already supplied its own CVSS vector, so the agency no longer authors a second score in those cases [16][1][2][3][4][9].
Harold Booth, a NIST computer scientist and former NVD project lead, described the situation without softening it: "CVE reporting keeps increasing, and trust me, at the NVD, we see them all, and our ability to keep up is just not there." Caitlin Condon, VP of Security Research at VulnCheck, put the consequence in similarly direct terms, warning that a significant portion of vulnerabilities now appear to have no clear path to enrichment through NIST. Most vulnerability management programs were built on an assumption that no longer matches reality: that NVD would supply a normalized CVSS v3.1 base score, a CPE applicability tree, a CWE classification, and tagged references for nearly every CVE within a predictable window. That assumption now holds for a small minority of new records. Teams still running triage processes built on it are, in effect, triaging against a database that has quietly stopped doing the job they think it's doing.
What CVSS was designed to measure
It was never built to answer the question that actually matters for a given finding this week: whether this specific application, as deployed, can be reached and exploited through this flaw. Those are different questions, and conflating them is the root failure of CVSS-only triage. A CVE with a high CVSS score sitting in a library that an application loads but never calls into, from any reachable code path, does not carry anything close to that score's level of real-world risk. A lower-scored CVE in an internet-facing parser that is already being exploited in the wild may be the single highest-priority item in the entire queue, regardless of what its base score says.
Three specific gaps explain why CVSS-first prioritization breaks down at scale. First, CVSS carries no exploitation signal: the score reflects theoretical severity, with nothing in it indicating whether real attackers are using the flaw against real targets. Second, CVSS has no concept of reachability: the scoring model has no mechanism for representing whether the vulnerable function sits anywhere near an application's actual entry points. Third, environmental context mostly goes uncomputed: CVSS 3.1 does include Environmental metrics meant to adjust severity for deployment-specific factors, but producing those metrics at scale requires inputs that are expensive to generate by hand, so in practice they are rarely applied.
The consequence compounds across a team's entire workload: engineers spend cycles patching high-scoring vulnerabilities that pose no realistic threat to their specific deployment, while genuinely exploitable findings wait in the same queue, indistinguishable by score alone. SBOM analysis guidance from Kiuwan states this directly: CVSS scores alone are insufficient for vulnerability prioritization, and VEX documents, reachability analysis, and risk-based signals such as CISA KEV and EPSS are what actually make a finding actionable. None of this makes CVSS worthless. It remains a reasonable measure of theoretical severity. It was simply never designed to tell a team whether a given vulnerability can fire in their environment, and no amount of triage discipline built on top of CVSS alone can manufacture that information after the fact.
How reachability analysis filters the noise CVSS cannot
Reachability analysis answers the question CVSS cannot: can this application actually reach and execute the vulnerable function, through a direct call or through a chain of calls into a transitive dependency? A CVE sitting in a dependency is not automatically a CVE in the application that depends on it. It becomes a live risk only when the application's own code calls into the vulnerable function, whether directly or through several layers of intermediate calls. Most dependencies, and transitive ones in particular, get pulled in by package managers as broad-scope inclusions. Large portions of that code never get invoked by the application that depends on it. Most of the vulnerability surface that a traditional scanner reports never actually executes.
Existing SBOM tools, by and large, operate at the package or binary level, a coarse and context-blind view that flags a vulnerability for remediation whether or not the dependent program calls the vulnerable code. Reachability analysis adds exactly the layer of context that view is missing, by tracing execution paths outward from an application's entry points, through its direct and transitive dependencies, to show whether a given vulnerable function sits on a path that can actually run.
That tracing fits into a four-step pipeline that practitioner evidence has converged on. The first step generates an SBOM capturing every transitive dependency and cross-references it against CVE databases, producing a raw list that, for a typical mid-sized service, runs into the thousands. The second step applies KEV and EPSS filters: CISA's KEV catalog flags CVEs under active exploitation, and EPSS estimates the probability that a given CVE will be exploited based on empirical signals, with a threshold above 0.1 capturing roughly the top decile of likely-exploited vulnerabilities. CISA encourages pairing EPSS with its KEV catalog but doesn't mandate a specific EPSS threshold, and this filtering step alone cuts the queue down by a majority. The third step applies VEX statements and reachability analysis to whatever remains, and this is the step that separates a workable triage queue from a wall of noise: industry data consistently shows that most CVEs in open-source dependencies are not reachable from application code. The fourth step ranks what's left by policy: it applies organization-specific rules about service criticality, internet exposure, and acceptable remediation windows to a set of findings that is now small enough for a team to actually work through.
That pipeline doesn't depend on NVD as a single point of failure, which matters given everything the first section describes. CNAs already author the majority of CVSS v3.1 vectors themselves. CISA's Authorized Data Publisher program delivers SSVC decisions on a subset of CVEs, prioritizing the higher-risk ones, through its ADP container. EPSS v4 produces daily probability estimates for any CVE regardless of its NVD enrichment status. Reachability analysis plugs into that multi-source posture rather than waiting on any single authority to catch up.
Where the SBOM is the prerequisite, not the output
Reachability analysis is only as good as the dependency graph it runs against, and that graph comes from the SBOM. If an SBOM misses transitive dependencies, the pipeline runs its reachability analysis against an incomplete graph, and that doesn't just miss some findings, it produces false confidence in the findings it does report. A team looking at a clean reachability result from a broken graph has no way of knowing the graph was broken.
SBOM generation and SBOM analysis are distinct activities, and programs routinely treat them as the same thing. Generating an inventory tells a team what is in their software. Analyzing that inventory tells them what it means for their security posture, their remediation priorities, and their regulatory readiness. Many SBOMs in production today are generated too late in the development lifecycle, lack any context about how their listed components are actually used, or fail to reflect what truly ships inside embedded and compiled software. Any one of those gaps is enough to invalidate the reachability graph built downstream of it.
Transitive dependencies deserve particular attention here, because a significant share of real-world supply chain vulnerabilities hide inside them. Direct dependency scanning misses that category of risk entirely, and a package-level SBOM that doesn't resolve its transitive dependencies leaves the same blind spot standing. SBOM analysis has one advantage direct code scanning doesn't: it can evaluate any inventory, including one received from a supplier or third party, without needing access to that party's source code. Software composition analysis scans code an organization owns, while SBOM analysis can evaluate inventories an organization doesn't own. Mature programs run both.
Effective SBOM analysis also runs continuously rather than at a single point in time, automating CVE cross-referencing so that new CVEs affecting existing components surface as soon as they're published. Cross-referencing against multiple sources closes much of the gap NVD's restructuring opened. OSV and vendor-curated feeds often publish ecosystem-specific advisories before NVD enrichment, including CPE mapping, becomes available at all, and GitHub Security Advisories along with ecosystem-specific feeds for npm, PyPI, and Maven carry package-level context NVD may never tag.
Reproducible, pinned environments underneath this pipeline are what make it work. If the dependency set a developer runs locally differs from what actually ships to production, the reachability graph analyzed in CI reflects neither environment accurately, and that mismatch is an infrastructure problem that feeds the risk of false negatives downstream. Regulators are tightening the screws on exactly this gap. CISA's 2026 minimum elements update and the EU Cyber Resilience Act, which introduces vulnerability and incident reporting obligations starting September 11, 2026, and broader product security obligations from December 11, 2027, are turning SBOM completeness and usability into hard compliance requirements. The question regulators and customers are asking has shifted from whether a supplier can produce an SBOM to whether the SBOM they produce is accurate and usable enough to act on.
Function-level reachability in practice with current tooling
Function-level reachability analysis is now something open tooling can produce at CI scale, but the result only helps a team if the SBOM format carrying it, and the tools consuming that format, can represent and act on the evidence it contains. OWASP cdxgen v12, which shipped during the first quarter of 2026, adds reachability evidence powered by its atom static-analysis engine and ships CycloneDX 1.7 as its default output format. The atom engine builds a code property graph from an application's source tree, cdxgen resolves package URLs against the OSV database, and for each package URL tied to a known vulnerable function, it walks the call graph inward from source files to see whether that function is actually reachable.
CycloneDX 1.7 being the default format matters for a specific reason: it carries the VEX vocabulary natively, so tools that consume the SBOM downstream, including Dependency-Track and other audit consumers, can read the reachability evidence directly, without translating between formats. VEX statements are the structured mechanism the industry uses to assert that a known CVE is not exploitable in a specific product. Reachability analysis is the automated way to generate the evidence that backs up a VEX assertion, rather than an analyst producing that evidence by hand.
Static reachability analysis has real limits, so a team adopting this approach should plan around them rather than treat the output as infallible: static call graph construction is deliberately conservative, since researchers at Stony Brook University chose soundness over precision for C and C++. The resulting graph may overestimate a function's actual code footprint. Missing an indirect call edge that is genuinely feasible is the dangerous failure, since it could cause a critical vulnerability to be overlooked. Code-path reachability also has a blind spot for vulnerabilities that are gated by configuration state. CVE-2024-27316 in Apache httpd is a concrete case: exploitability there requires HTTP/2 to be enabled on the server, for instance through the mod_http2 module, and no switch in httpd.conf or.htaccess gates the attack in a way that a code-path trace alone would catch. Contextual analysis that reads configuration state has to sit alongside reachability analysis to cover that category of risk.
False-negative monitoring belongs in any pipeline built on this approach, not as an optional add-on. When a CVE later turns out to be exploitable in a given environment, the right response is to trace back whether the reachability analysis flagged it at the time, and a mature pipeline tracks that rate over time as a measure of its own reliability. That feedback loop is what turns reachability analysis from a one-time filtering exercise into a system a security team can keep trusting as both the codebase and the CVE landscape keep changing under it.
