eBPF Runtime Security: Transforming Linux Threat Detection and

Introduction: The Shift from Detection to Enforcement

In February 2026, Cisco’s Isovalent team published a migration guide for teams moving from Falco to Tetragon, citing a fundamental shift in how runtime security is evolving: detection alone is no longer enough. The guide, hosted on the official Cilium blog, walks through how Tetragon’s in-kernel enforcement capabilities change the threat response timeline from seconds to milliseconds. This is not an incremental improvement. It represents a structural change in how Linux security monitoring works, driven entirely by eBPF.

Traditional endpoint detection and response (EDR) agents have dominated enterprise security for over a decade. They sit in user space, collect logs, hook API calls, and ship data to a central analysis engine. The model works, but it carries latency, overhead, and blind spots that become critical in containerized, high-throughput environments. eBPF-based runtime security tools like Falco, Tetragon, and Tracee take a different approach: they hook directly into the Linux kernel, observing syscalls, network events, and file I/O as they happen, with minimal performance cost.

This article compares these two approaches across real production metrics, examines a concrete attack scenario, and lays out where each model falls short.

What eBPF-Based Runtime Security Can Observe

eBPF (extended Berkeley Packet Filter) allows security tools to attach small, verified programs to kernel hooks without loading kernel modules or rebooting. These hooks cover three major observation domains that matter for threat detection.

System calls. Every significant action a process takes goes through a syscall. eBPF can intercept execve(), connect(), open(), read(), write(), and hundreds more. When a container spawns a reverse shell, the execve() call with /bin/bash and the network connect() to an external IP can be caught in the same kernel probe. Traditional EDR agents often miss this sequence because they rely on user-space API hooks that can be bypassed or that introduce delay between the syscall and detection logic.

Network sockets. eBPF hooks into the kernel’s network stack at a level below what user-space agents can reach. Tools like Tetragon can correlate process-level activities with network flows, showing which specific binary within a container initiated a suspicious connection. As InfoWorld’s analysis of Tetragon notes, this “network awareness extends across clusters and environments, with deep context about originating processes and binaries.” Traditional EDR agents see the connection in logs but often lack the kernel-level context to tie it to the exact binary invocation.

File I/O. File operations at the kernel level provide visibility into which files are being read, written, or executed. When an attacker drops a malicious binary or tampers with configuration files, an eBPF probe catches the open() and write() calls at the exact moment they occur. This is particularly valuable for detecting ransomware-style behavior where a process reads many files and writes encrypted versions in rapid succession.

The key architectural difference is that eBPF tools perform filtering and aggregation directly in the kernel, before events ever reach user space. As Tetragon documentation explains, “rather than sending all events to user space for processing, Tetragon leverages eBPF to perform sophisticated filtering directly in kernel.” This in-kernel processing is what enables both low overhead and near-instant detection.

Performance Overhead: eBPF vs Traditional EDR in Production

The performance gap between eBPF-based tools and traditional EDR agents is one of the strongest arguments for adopting kernel-level monitoring. eBPF programs are JIT-compiled and verified by the kernel’s verifier before execution, ensuring they cannot crash the system or enter infinite loops. The result is a security sensor that typically consumes 1-5% CPU overhead even under sustained high load.

Traditional EDR agents face a different cost structure. They rely on user-space hooks, periodic file scans, process tree enumeration, and log shipping to a central SIEM. Each of these operations requires context switches between user space and kernel space, adding latency and CPU consumption. In high-throughput environments, EDR agents can consume 10-20% of CPU resources, with overhead spiking during full scans or when processing burst events.

The trade-off becomes sharper in Kubernetes environments where pods are ephemeral. Traditional EDR agents must install an agent on each node, configure it to recognize new pods, and maintain state across container restarts. eBPF tools operate at the kernel level, seeing all processes and containers on a node regardless of lifecycle. There is no agent installation per pod, no agent update cycle per container image.

However, eBPF tools are not zero-cost. The Trail of Bits analysis of eBPF security pitfalls warns that “event overload” is a real risk: if too many probes are attached or if filtering predicates are too broad, an eBPF program can generate enough events to overwhelm the perf ring buffer, causing dropped events. Proper tuning of filter expressions and rate limiting is essential for production deployments. For a broader perspective on limitations of reasoning models in 2026, including how similar constraints apply to AI-based detection, see the linked analysis.

Concrete Detection Scenario: Catching dnsmasq extract_name() Exploitation

To understand the practical difference between eBPF-based detection and traditional EDR, consider a real attack pattern: exploitation of the dnsmasq DNS forwarder through its extract_name() function. This is not hypothetical. The XZ Utils backdoor incident of 2024 demonstrated how supply chain compromises in system utilities can lead to long-term undetected access. Dnsmasq, which runs on millions of Linux systems and Kubernetes nodes, is a similarly attractive target because it processes untrusted network input and runs with raised privileges.

An attacker who compromises dnsmasq through a buffer overflow or logic bug in extract_name() would likely follow a predictable sequence:

• Trigger the exploit by sending a crafted DNS query to the target.
• Spawn a reverse shell or execute a payload via execve().
• Establish a network connection to a command-and-control server.
• Read or exfiltrate sensitive files from the host.

An eBPF-based tool like Tracee can detect this sequence at the syscall level. The following simplified example shows how Tracee can be configured to trace relevant events:

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

# Tracee event filter for dnsmasq exploitation detection
# This configuration traces execve, connect, and file read events
# specifically for processes spawned by dnsmasq

tracee \
 --trace event=security_file_open \
 --trace event=sched_process_exec \
 --trace event=syscalls_connect \
 --trace comm=dnsmasq \
 --trace follow \
 --output json \
 --output-format gotemplate \
 --capture exec \
 --capture write=/tmp/dnsmasq_capture/

# Note: production use should add rate limiting, cache size bounds,
# and integration with SIEM or alert manager for sustained event streams.

When the exploit triggers, Tracee captures the execve() call showing the payload binary, the connect() syscall showing the C2 server IP and port, and the security_file_open events showing which files the compromised process accessed. All of this happens within milliseconds of the exploit executing, before the attacker can complete data exfiltration.

A traditional EDR agent would need to rely on its user-space hooks to detect the same sequence. The execve() would be caught by a process creation event hook, but the hook may not fire until after the process is already running. The network connection would appear in connection tracking logs, but correlating it to the specific dnsmasq process requires log aggregation and timing alignment that introduces seconds of delay. By the time the EDR generates an alert, the attacker may have already completed data transfer.

This is the core advantage of eBPF-based detection: kernel-level hooks see the attack as it happens, not after the fact.

Security Gaps: What eBPF Cannot See

eBPF is powerful, but it is not a complete security solution. Understanding its limitations is essential for building a layered defense.

No user-space memory visibility. eBPF programs run in kernel context and cannot directly read user-space memory. This means an attacker who performs in-memory injection, such as loading a malicious shared library via LD_PRELOAD or executing shellcode in a running process’s address space, will not be detected by eBPF alone. The kernel sees the mmap() and mprotect() syscalls, but it cannot inspect what is being loaded or executed in user space. As Forbes analysis of eBPF limitations notes, “eBPF is a capability in Linux that enables security and other introspection products to gather deep insights into an operating system’s activities,” but those insights stop at the kernel boundary.

Kernel version dependencies. eBPF programs depend on specific kernel hooks and helper functions that vary across kernel versions. A probe written for kernel 5.15 may not work on kernel 6.1, and a probe written for a distribution kernel with backported features may fail on a vanilla upstream kernel. The Trail of Bits analysis identifies “probe unreliability” as a key pitfall: probes may silently fail or produce incomplete data on kernels where the expected hook point does not exist or behaves differently.

Event overload and data truncation. eBPF programs have strict instruction limits (typically 1 million instructions for the verifier) and data size limits for map entries and perf ring buffer events. Under high event volume, the kernel may drop events if the user-space consumer cannot keep up. Complex filtering logic that works in testing may hit instruction limits in production, forcing developers to simplify detection rules at the cost of accuracy.

No application-layer context. eBPF sees syscalls and network packets, but it does not understand application protocols. It cannot distinguish between a legitimate HTTP request and a malicious one based on payload content, because the payload resides in user-space memory that eBPF cannot read. Application-layer detection requires complementary tools like Web Application Firewalls (WAFs) or Runtime Application Self-Protection (RASP) systems.

Falco vs Tetragon vs Tracee: A Practical Comparison

The three most prominent eBPF-based runtime security tools each take a different approach. Understanding their differences is critical for choosing the right tool for a given environment.

Falco is the most mature of the three, originally created by Sysdig and now a CNCF graduated project. Its strength is its extensive rule library covering many MITRE ATT&CK techniques. Its weakness is that all detection happens in user space after kernel events are collected, which introduces latency and limits enforcement to alerting. As the Cilium migration guide notes, “Falco is an intrusion detection system designed to detect only.”

Tetragon was created by Isovalent (acquired by Cisco in 2024) as a subproject of Cilium. Its defining feature is in-kernel policy enforcement: it can send SIGKILL to a malicious process or override a syscall return value before the operation completes. This is a fundamentally different security model from Falco’s alert-only approach. Tetragon is the strongest choice for teams that want automated, real-time blocking of threats at the kernel level.

Tracee focuses on behavioral detection and event tracing. It captures detailed syscall traces that are valuable for incident forensics and understanding exactly what a compromised process did. Tracee is the strongest choice for security teams that need deep investigative capabilities, but it requires more manual analysis than the rule-based approaches of Falco or Tetragon.

When Traditional EDR Still Wins

eBPF-based tools are not a complete replacement for traditional EDR. There are scenarios where user-space visibility and application-layer context remain essential.

Memory-based attacks. An attacker who injects shellcode directly into a running process’s memory using ptrace() or /proc/<pid>/mem will trigger syscalls that eBPF can see, but the injected code itself is invisible to kernel probes. Traditional EDR agents with user-space memory scanning can detect injected code by comparing process memory against known good baselines. This is a detection capability that eBPF cannot replicate.

Application-layer threats. SQL injection, cross-site scripting, and command injection attacks operate at the application layer. eBPF sees the resulting syscalls (database query, file write) but cannot determine whether the operation was malicious without understanding application context. Web application firewalls and runtime application self-protection tools fill this gap.

Non-Linux environments. eBPF is a Linux kernel technology. Windows environments require traditional EDR agents for kernel-level monitoring. While Microsoft is working on bringing eBPF to Windows through the eBPF for Windows project, the implementation is not yet at feature parity with Linux eBPF.

Compliance and audit requirements. Many compliance frameworks require specific log formats, retention policies, and audit trails that eBPF tools do not natively produce. Traditional EDR agents with built-in SIEM integration often meet these requirements out of the box, while eBPF tools require additional pipeline components to format and store events in compliance-ready formats. For a detailed breakdown of storage options for audit logs and event data, see our top cloud storage comparison for 2026.

The strongest security posture combines both approaches. eBPF tools provide kernel-level detection and enforcement for fast, low-level threats. Traditional EDR agents provide user-space visibility, application-layer context, and compliance-ready logging. Together, they cover the full detection spectrum from kernel to application.

Key Takeaways

• eBPF-based tools (Falco, Tetragon, Tracee) provide kernel-level observability of syscalls, network sockets, and file I/O with 1-5% CPU overhead, significantly lower than traditional EDR agents.
• Tetragon’s in-kernel enforcement capability enables real-time blocking of malicious operations, a capability that traditional EDR and even Falco cannot match.
• eBPF cannot see user-space memory, limiting its ability to detect in-memory injection attacks and application-layer threats.
• Kernel version dependencies and probe reliability are real operational risks that require careful testing and monitoring in production.
• The dnsmasq extract_name() exploitation scenario shows how eBPF tools can detect and block attacks within milliseconds, while traditional EDR agents may take seconds to correlate the same events.
• The strongest security posture combines eBPF-based kernel monitoring with traditional EDR for user-space and application-layer coverage.

Sources and References

This article was researched using a combination of primary and supplementary sources:

Supplementary References

These sources provide additional context, definitions, and background information to help clarify concepts mentioned in the primary source.

• Tetragon: Extending eBPF and Cilium to runtime security
• ARMO launches Behavioral Cloud Application Detection and Response to unify runtime security
• ARMO Launches First Cloud App Detection and Response to Unify Code to Cloud Runtime Security
• HiddenLayer Unveils New Agentic Runtime Security Capabilities for Securing Autonomous AI Execution
• Upwind Partners with Microsoft to Deliver Runtime Security for Azure Workloads
• What are the key differences between Falco and tetragon?
• Migrating from Falco to Tetragon: A Guide for Transitioning Your …
• Falco vs Tetragon: Detection vs Enforcement for Container Runtime …
• Oligo Security raises $50M for its eBPF-powered application security platform
• eBPF – Introduction, Tutorials & Community Resources
• Why Runtime Monitoring Is Key for Linux Security with eBPF
• EBPF-Based Security Solutions: Exploring Weaknesses And Mitigation Techniques.
• eBPF Security Power and Shortfalls – The New Stack
• Pitfalls of relying on eBPF for security monitoring (and some solutions)
• Pitfalls of relying on eBPF for security monitoring (and some solutions)
• eBPF for Security Monitoring: Kernel-Level Visibility Without the …