Your CVE is reachable. But is it exploitable?

Dependency vulnerability management currently relies heavily on reachability analysis, which determines if vulnerable code within a dependency is actually called by an application. While this significantly reduces alert noise compared to simply scanning every dependency included in a lockfile—a major advance over previous SCA methods—reachability alone is insufficient for determining true risk. Merely having the function callable does not equate to exploitability; vulnerabilities often require external attacker-controlled conditions, specific configuration states, or elevated privileges to manifest damage.
Further refinement requires exploitability analysis, which moves beyond code paths to assess if an adversary can satisfy all necessary preconditions for a bug to fire. For instance, in one case study involving Lodash, reachability confirmed the vulnerable function was called, but exploitability analysis could downgrade the priority because hardcoded inputs prevented attacker control over the sensitive parameter.
These analyses are dynamic: an initial verdict of "not exploitable" is only valid relative to the current code and deployment. Changes—such as a new input path or configuration update—can fundamentally alter the exploitability assessment, necessitating continuous evaluation that integrates both code flow and environmental context.

CVSS rates vulnerability severity on a 0 to 10 scale based on the flaw itself.
EPSS estimates the probability of a CVE being exploited in the wild within 30 days.
KEV is CISA’s Known Exploited Vulnerabilities catalog, listing confirmed exploits.
Reachability analysis checks if application code can execute a vulnerable function by mapping call graphs.
Function-level reachability confirms if specific buggy functions are called, rather than just if the package is imported.
CISA's VEX lists "vulnerable code not in execute path" (reachability) and "vulnerable code cannot be controlled by adversary" (exploitability).
For CVE-2021-23337 in Lodash, an attacker controls the option input if request data is spread into template options.
Aikido’s CVE Exploitability Analysis reads repository code along with container context, including Dockerfile and base image.

The central narrative here concerns the evolution of software security triage—a shift from broad signal detection (CVSS severity) toward precise risk modeling. The process moves systematically from general hazard assessment (CVE ID) to presence in scope (Reachability), and finally to actual impact potential (Exploitability). This progression mirrors a growing maturity in threat intelligence, demanding that technical findings be contextualized within the operational reality of a specific deployment.
The assumption underpinning this entire analysis is that security tooling can accurately model emergent complexity. We are moving past 'what could happen' toward 'what can happen to *me* right now.' However, this reliance on automated context—such as container details or code paths intersecting with configuration—introduces new systemic vulnerabilities: the reliability of the models themselves. If the execution path mapping is flawed, or if external factors (like a latent prototype pollution bug) alter exploitability after initial assessment, the decision to ignore a finding becomes a high-stakes gamble based on potentially transient states.
The primary cost in this shift is the intellectual overhead required for maintenance; security posture is no longer a snapshot but a continuous verification task. Who profits from this precision? Developers and engineering teams gain focus by eliminating noise, allowing them to prioritize truly critical issues over theoretical ones. But who bears the risk when the automated context fails—the developer, the compliance officer, or the end-user exposed by an unmodeled interaction?
How much confidence should be placed in any automated verdict of "not exploitable" if that verdict depends on the integrity of the entire upstream dependency graph and container configuration chain? If exploitability analysis is moving toward runtime context integration, what new architectural assumptions must we make about security tools to support this level of deep environmental introspection without introducing performance overhead or cascading failure points?
Patterns detected: none