Key Takeaways
- Most vulnerability scanners report what could be present, not what can actually be reached in your running application.
- Reachability analysis asks whether execution can reach the vulnerable code, which is distinct from exploitability (the existence of a working proof‑of‑concept).
- Static analysis and SCA tools suffer from high false‑positive rates because they treat reachability as a pure code‑traversal problem and ignore the specific conditions required to trigger a flaw.
- Large Language Models (LLMs) improve reachability analysis when supplied with structured context—such as abstract syntax trees, call graphs, and translated vulnerability conditions—rather than raw code snippets.
- Containerized workloads widen the gap between present and reachable vulnerabilities; scanners that ignore multi‑stage builds and entrypoint configurations flag harmless build‑time dependencies.
- By focusing remediation on the truly reachable subset, teams can concentrate on the “right 10 percent” of findings they can realistically fix each month, reducing noise and improving security ROI.
The Gap Between Present and Relevant Vulnerabilities
Modern scanning tools generate far more findings than engineering teams can remediate. The Cyentia Institute estimates that only about one in ten vulnerabilities can be addressed in a given month, not because processes are broken but because the volume of alerts outpaces available engineering capacity. This mismatch forces teams to triage by severity scores alone, wasting effort on issues that may never be executed in production. The core problem is that scanners answer the question “Is this vulnerability present?” rather than “Can the application’s execution reach the vulnerable code?” The latter determines whether a finding poses real risk.
Understanding Reachability vs. Exploitability
Reachability is a property of a specific deployment: given how an application is built, configured, and run, can an attacker traverse from an entry point to the vulnerable function? Exploitability, by contrast, is an intrinsic property of the vulnerability itself—whether a working proof‑of‑concept exists in the wild. A flaw may be highly exploitable in theory yet completely unreachable in a particular service because the required code path is never invoked, the necessary input format never occurs, or the dependent library is stripped out at build time. Prioritizing solely by CVSS or EPSS scores conflates these two distinct concepts and can lead to misguided remediation efforts.
Limitations of Existing Scanners and SCA Tools
Static analysis and Software Composition Analysis (SCA) platforms excel at enumerating dependencies and flagging known vulnerabilities, but they treat reachability as a simple code‑traversal problem. They ask whether a vulnerable function appears in any call graph reachable from an entry point, without examining the conditions that must be satisfied for the flaw to trigger—such as specific input formats, authentication states, or configuration flags. Consequently, these tools either over‑flag conservatively, inflating the alert backlog, or miss subtle cases where the vulnerability conditions are met through indirect or framework‑managed flows. Neither outcome provides the precision security teams need to act efficiently.
Role of LLMs in Enhancing Reachability Analysis
Large Language Models can reason about complex code patterns, but only when given the right context. Feeding an LLM a raw code snippet and asking “Is this vulnerability reachable?” often yields confident yet incorrect answers because the model lacks awareness of control flow, data dependencies, and the precise triggering conditions described in the vulnerability advisory. A more effective approach supplies the model with structured inputs: an abstract syntax tree, a focused call graph, relevant code slices, and a translation of the vulnerability description into concrete pre‑conditions (e.g., required parameters, state flags). With this context, the LLM can evaluate whether the necessary data flow ever occurs, discern impossible branches, and highlight paths that static tools flagged incorrectly. Benchmarks across models—including Llama 3.1, Qwen3, and security‑fine‑tuned Foundation‑Sec‑8B—show measurable reductions in false positives when context quality is high, though human validation remains essential for edge cases involving runtime assumptions or framework‑managed control flow.
Containerized Environments Amplify the Gap
The problem of present‑versus‑reachable vulnerabilities intensifies in containerized workloads. Standard container scanners inspect every layer of an image and report vulnerabilities found in build‑time dependencies, even when those layers are excluded from the runtime image by multi‑stage Dockerfiles, custom entrypoints, or stripped‑down base images. A vulnerable library that exists only in a build stage—such as a GCC toolchain or a compile‑only utility—poses no risk to a running microservice, yet scanners treat it as if it were present in production. Reachability analysis that incorporates container structure (e.g., distinguishing build stages from final runtime layers, respecting entrypoint exclusions) can immediately dismiss such findings, allowing engineers to focus on code that actually executes.
Operational Impact: Focusing on the Right 10 Percent
When remediation capacity is limited to roughly one finding per ten per month, the strategic question shifts from “How can we work faster?” to “How can we ensure we are fixing the right ten percent?” Reachability analysis narrows the alert set to those vulnerabilities that are both present and executable in the specific deployment, grounded in actual call chains, data flows, and container runtime realities. By combining traditional static analysis, container‑aware scanning, and LLM‑based reasoning enriched with structured vulnerability context, security teams obtain a smaller, more reliable, and defensible list of actionable issues. This focus reduces wasted effort, accelerates meaningful risk reduction, and aligns security work with the true behavior of the application in production.