Three of the four production environments in our early-access program had active exploitation attempts against dependencies their SCA scanner had deprioritized. Not flagged as unexploitable. Deprioritized. Reachability scoring, CVSS context adjustments, or plain queue depth had moved the finding past the last remediation sprint. The scanner was correct that the vulnerable dependency existed. It was wrong about whether anyone would try to exploit it.
We began gathering runtime telemetry from early-access deployments in late 2025. This post reviews what six months of data reveals about the distance between scan findings and confirmed exploitation events in production.
The Reachability Gap
Modern SCA and SAST tools have improved their handling of reachability. Call graph analysis can assess whether a vulnerable function is reachable from an application's entry points. For many findings, that filtering is accurate: a crypto library imported but never called cannot be exploited through the application's HTTP surface. Reachability filtering is a meaningful advance over an unfiltered CVE list.
The challenge appears at the boundaries. Call graph analysis works statically against compiled or interpreted code. It cannot observe an attacker sending input that activates a path the analyzer labeled unreachable, a transitive dependency loading code dynamically through reflection or class loaders, or a legitimately reachable path becoming exploitable through parameter manipulation absent from the static model.
Static reachability answers, "Can this path be reached during normal operation?" It does not answer, "Can an attacker reach this path while controlling the input?"
Six Months of Runtime Telemetry
Across our early-access deployments, four production environments running between three and eight services each, Oligo's eBPF instrumentation captured these event categories that static analysis had missed or pushed down in priority.
Attempts to exploit "low reachability" findings
In three environments, we saw exploit attempts aimed at CVE-matched dependencies that the team's SCA tool had rated low priority based on reachability context. Each attacker arrived at the vulnerable function through an indirect route: URL-encoded parameters entering a deserialization step, or HTTP header injection steering execution through a path the static graph had not connected to the main application entry points.
This does not indicate that the SCA tool failed. The attacker had a different code model from the static analyzer. In these three instances, the attacker's model was more accurate.
Fileless execution through trusted tools
Two environments revealed exploitation that never placed a binary on disk. An injected payload reached a Python interpreter or bash subprocess, ran entirely in memory, and ended within seconds. A file scanner would detect nothing. The eBPF runtime trace captured the execve chain, arguments, open file descriptors, and the outbound network connection that followed within 800ms.
SSRF access to metadata endpoints
One environment recorded an SSRF attempt against a cloud metadata service endpoint. The application's WAF blocked metadata endpoint patterns in URL parameters. The SSRF evaded that control because the malicious destination was assembled server-side from user-controlled data rather than supplied directly as a URL parameter. The kernel's connect() syscall observed the final resolved address regardless of how the application layer constructed it.
Where Static Analysis Consistently Falls Short
We are not claiming static analysis has no value. The narrower point is that it cannot show whether an attack is happening now or identify which theoretical findings attackers are actively targeting.
Static analysis creates a finding at one moment, using a code snapshot. Exploitation continues against a live system. Between them are zero-day and N-day exploits that appear before the next scan cycle, techniques that bypass the specific deployment configuration the static model missed, supply chain compromises introduced after scanning, and attacks that combine multiple low-severity issues into a high-severity path that no individual finding identified.
Volume creates another challenge. A mature production codebase may produce hundreds of SCA findings each sprint. No team can patch at that pace. Teams need to know which findings represent active threats and which indicate theoretical exposure. Static analysis cannot provide that distinction by design because it cannot see runtime state.
Runtime Telemetry as Ground Truth
eBPF instrumentation observes running code rather than source or bytecode snapshots. When a vulnerable function runs, the kernel observes it. When attacker-controlled input caused that execution, the surrounding syscall context differs from normal behavior: unusual argument patterns, network connections opened immediately before or after, and process trees that depart from the behavioral baseline.
This is observation at the kernel boundary, where userspace code cannot falsify execution state. An attacker may obfuscate a payload, but cannot stop the kernel from recording that execve ran, which PID called it, its parent process, and the file descriptors open at that moment.
For a security team, the practical difference is that we can show more than "this CVE exists in your dependency tree." We can show "this CVE was triggered at 14:32 UTC by a request from this IP, the vulnerable function ran with these arguments, and it spawned a child process that connected to this external host within one second." That evidence changes the triage decision.
Using Telemetry to Rank Scan Findings
A direct use for runtime data is to feed it into scanner prioritization. If you have 400 open SCA findings and telemetry shows that 12 underlying functions were called in production during the last 30 days, you have a far better ordering than CVSS score alone can provide. Patch the functions that executed first, whatever their theoretical severity score. Functions never executed in production can be deferred, but should not be deprioritized on the assumption that they are unreachable.
Oligo captures function-level execution traces and correlates them with CVE-matched functions in the dependency tree. This does not replace your SCA tool. It adds runtime execution evidence as a filter layer around static findings, allowing the remediation queue to represent actual exposure instead of theoretical exposure.
What Runtime Monitoring Does Not Replace
Shift-left scanning identifies many issues before production: hardcoded secrets, known vulnerable packages, SAST-detectable injection patterns, and configuration errors. These are worth finding early, and early remediation costs less than runtime discovery. Runtime monitoring is not an argument against pre-production scanning.
The point is that pre-production scanning is not enough by itself. Some vulnerabilities reach production whether or not they were scanned. New exploits can target known CVEs that existed before the latest scan cycle. Runtime monitoring answers the question static analysis cannot: "Is this vulnerability being exploited right now?"
Our six months of telemetry indicates that the second question is active more often than static-analysis-only programs assume. The gap between theoretical exposure and an exploitation attempt is shorter than the scan cycle between finding and fix.