Not All eBPF Sensors Are Created Equal: Why Depth Matters in Runtime Security

Many security vendors use eBPF, but only a few unlock its full potential. Here’s why how you use eBPF matters more than the fact that you use it.

The Rise of eBPF in Cloud Security

In security, eBPF is celebrated for its ability to gather telemetry with low overhead and high fidelity. It has become a check-box feature in modern security solutions, advertised prominently by vendors with the common capabilities, such as:

• Real‑time, kernel‑to‑user‑space visibility without the crashes and outages that intrusive EDR kernel modules or drivers can cause.
• Zero code changes and no application restarts, achieving the protection typically associated with RASP solutions while avoiding their disruptive redeployments.
• Minutes-to-value deployment in modern Kubernetes environments - a plug-and-play Helm chart installs the eBPF sensor seamlessly.

However, that popularity has also bred a dangerous misconception: that merely using eBPF confers deep runtime visibility and sophisticated detection capabilities. The truth is that most solutions only scratch the surface of what eBPF can offer for security. The real power of eBPF lies not in whether it’s used, but in how it’s used.

The Check-List Trap: eBPF as a Syscall Sniffer

Most runtime security tools today use eBPF as a glorified syscall sniffer - the most trivial core events you can monitor on a host. eBPF’s ability to capture syscalls ticks a feature box, yet leaves massive blind spots. 

The shortfalls of this shallow, basic use of eBPF include:

• High False-Negative Rates: Syscalls alone can’t reveal intent. Without knowing who triggered a syscall, how it was reached, or why it occurred, critical attacks go undetected. A fork() during system startup is expected, but the same call from injected shellcode is a red flag, and shallow tools can’t tell them apart.
• High False-Positive Rates: The number of false-positives alerts is extremely high, and for tools that lack proper context, every deviation looks dangerous. Tools that rely solely on syscall pattern-matching tend to overreact, generating floods of alerts for benign behavior. Security teams are left manually triaging noise, eroding trust in the system and increasing the risk of alert fatigue.
• Lack of Alert Context: Raw syscall logs don’t explain what triggered an event or where it originated in the application. Without stack traces, code-level attribution, or environment correlation, alerts lack the root-cause clarity needed for fast, confident response. You know what happened, but not why, how, or what to fix.

Deep Application Inspection - Where Depth Delivers Value

At Oligo, we pioneered a patented technology called Deep Application Inspection (DAI), a fundamentally different approach to runtime security using eBPF.

DAI approach is built on a core principle: runtime security is only as strong as its context. Instead of treating eBPF as a passive event tap, DAI uses it as a foundation for reconstructing rich behavioral narratives by correlating low-level events with high-level application logic. It’s not only about collecting more data - it’s about understanding what that data actually means in real time.

To understand the impact of this depth, think of runtime security as a funnel: each layer relies on the integrity of the one below. At the base are the essentials - raw data, enrichment, and data quality. This is where most tools fall short - and where the biggest gains can be made.

By establishing a strong, reliable, layered foundation, the detection logic above it can make confident, accurate, insightful decisions, resulting in a different class of runtime security:

1. Targeted Alerts, Not Noise: Instead of logging every syscall indiscriminately, DAI evaluates each action in context. Was a database write triggered by a trusted, known-safe code path - or by an unexpected input chain? By answering these questions in real time, DAI filters out routine behavior and suppresses benign noise, allowing only meaningful anomalies to rise to the surface.
2. Exploit Detection Beyond the Surface: Advanced attacks often mimic legitimate operations to evade detection. DAI traces execution flows across kernel and user space, correlating multiple runtime signals. This lets us detect exploits even when they appear harmless in isolation - revealing the true intent behind subtle behavior shifts.
3. Meaningful, Actionable Alerts: With function-level visibility, every alert includes the exact location in code where it originated. Security teams don’t just see what happened - they understand why it happened, how it reached that state, and what needs fixing. That level of root-cause clarity shortens incident response and speeds remediation.

In the example below, a seemingly benign whoami command was executed as part of an RCE exploit chain. While most tools would ignore this activity due to its harmless appearance at the syscall level, Oligo identified the exploitation by tracing the command back to its true origin within the application’s execution flow. By correlating runtime behavior with applicative context, we surfaced a critical security event that would otherwise go undetected.

Building Blocks of DAI: From Strong Base to Sharp, Actionable Insights

While most tools treat eBPF as a passive data tap, Oligo treats it as a precision instrument, layering observability, enrichment, and reliability into a complete detection pipeline. Here's how Oligo uses eBPF to unlock the potential of each layer:

Raw Data

Most tools stop at syscall logging. But the Linux kernel is more than a syscall dispatcher: it's the control plane for everything happening in the system. Oligo's sensor taps into this rich telemetry layer, capturing deep and diverse signals that reflect both user-space activity and kernel-level state that expose threats before they escalate.

• User-space activity: The kernel observes everything applications do - from access requests to memory behavior. Oligo captures signals like segmentation faults, illegal instructions, LSM hooks, and memory operations. These events expose early signs of exploitation, such as crashes, privilege misuse, or shellcode injection, often exposing threats that syscall tracing alone would miss or misinterpret.
• Kernel as Code: We treat the kernel not just as a source of events, but as live code to inspect. With eBPF, we instrument precise execution paths inside the kernel, tracing runtime flow at instruction-level detail. This surgical visibility reveals control flow anomalies, misuse of internal APIs, or low-level exploit attempts, surfacing threats that never manifest at the syscall layer at all.

Data Enrichment

Raw signals alone don’t tell a story. Oligo enriches every captured event with real-time context that clarifies behavior, exposes intent, and eliminates ambiguity, turning raw telemetry into meaning.

• Stack Trace Reconstruction: Most eBPF-based sensors observe the system layer but miss the application layer entirely. They see what syscall was made, but not which function, file, or code path triggered it. Oligo bridges that gap by reconstructing full user-space stack traces at runtime, pinpointing the exact applicative origin of each event. Achieving this level of visibility across languages and deep-tech use cases is far from trivial. Dynamic runtimes, JIT compilation, and complex patterns like Java Uber Jars often obscure the execution trail.
• Event metadata: Capturing that an event occurred isn’t enough - what matters is what it carried. Extracting rich metadata such as syscall arguments, signal context, return values, and decoded payloads (like HTTP headers, SQL queries, or DNS lookups) enables systems to detect intent, not just activity. This depth of semantic understanding is powerful, but often overlooked due to the complexity of parsing and runtime variability.
• Workload Context: We correlate every signal with its runtime execution environment, such as pod, container, image, namespace, node, and process lineage. By anchoring each signal to its precise execution environment, we distinguish benign behavior from abuse, even when they look identical at the syscall level.

Data Quality

For runtime security to be effective, it must not only capture the right data but also operate reliably in production. If instrumentation is too aggressive, it can add latency, consume excessive resources, or even destabilize the very systems it’s meant to protect.

Oligo’s sensor runs today in some of the largest cloud estates - protecting Fortune-level and high-growth tech companies at scale. Here are the core pillars of our design:

• Low Overhead: Our sensor is the industry’s most efficient and lightweight, using under 360 MB of memory to deliver deep insights with a minimal footprint. It adds less than 1 % latency, so even the most time-critical workloads keep running at full speed.
• High Reliability: In production environments with real-world traffic volumes, eBPF tools often drop data. Any lapse in visibility during peak load risks a false-negative - an outcome we refuse to accept.
• Wide Compatibility: Oligo’s Sensor spans diverse kernel versions, supports ARM and AMD, and runs in containers or bare-metal - coverage that took substantial, non-trivial architecture and engineering.
• Configurability: Our solution is highly tunable, allowing it to fit any environment and scale, adapting seamlessly to each business’s specific needs and constraints.

Future of eBPF in Security: Depth is the Key

eBPF is game-changing technology, but most tools put an eBPF checkmark next to “syscall capture” and stop there. That shallow cut leaves gaps wide enough for exploits and floods teams with noise.

Oligo’s Deep Application Inspection shows what eBPF can really deliver: It traces each kernel signal back to the exact function, library, and container that triggered it, enriches the record with stack and environment context, and sustains this depth through reliability in production. That way, telemetry becomes an insight: why an event occurred, not merely what occurred.

Depth isn’t cosmetic, it is the boundary between runtime trivia and runtime truth. When you evaluate sensors, look past the eBPF logo and ask for proof of enrichment, correlation, and performance - otherwise, you are choosing built‑in blind spots.

See Oligo’s sensor in action today.