For most of the last decade, runtime security meant an agent. You installed software on every host that hooked into the system somehow — a kernel module, a ptrace-based shim, a userspace daemon parsing logs — and it watched for bad behavior. These agents worked, but they came with a tax: meaningful CPU and memory overhead, fragility across kernel versions, and in the case of kernel modules, the genuine risk of crashing the machine they were meant to protect. By 2026 that model has been largely displaced by a better one. Extended Berkeley Packet Filter — eBPF — lets security tools run sandboxed programs inside the Linux kernel itself, observing syscalls, process execution, network activity, and file access at the source, with overhead measured in fractions of a percent and no custom kernel modules to maintain.
This shift matters most in cloud-native environments, where workloads are ephemeral, containers share a kernel, and the old model of a heavyweight agent per host simply does not fit. Three open-source tools dominate the eBPF runtime security space, and they are genuinely different in philosophy: Falco, the CNCF-graduated detection standard; Tetragon, the Cilium project's observability-and-enforcement engine; and Tracee, Aqua Security's detection-and-forensics tool. This guide explains how eBPF changed the game, then compares the three across detection, enforcement, forensics, and operational fit so you can choose deliberately.
Why eBPF won
To appreciate the three tools, it helps to understand why eBPF displaced the alternatives so decisively. The older approaches each had a fatal compromise. Kernel modules gave deep visibility but ran with full kernel privileges and could panic the system; a bug in your security agent became a kernel crash. Userspace agents were safe but blind to a lot of kernel-level activity and imposed 15-30% overhead in some configurations because of the constant context switching between kernel and userspace. Log-parsing approaches were safe and cheap but hopelessly after-the-fact and easy to evade.
eBPF threaded the needle. Programs run in the kernel, so they see everything at the source — syscalls, process creation, network packets, file opens — but they run inside a verified sandbox: the kernel's verifier statically proves an eBPF program cannot crash the system, loop forever, or access memory it shouldn't before it is ever allowed to load. The result is kernel-level visibility with userspace-level safety, at overhead consistently measured under 1% of CPU. No custom modules to compile per kernel, no panics, no heavy context-switching tax. For ephemeral, high-density cloud-native workloads, that combination is exactly what was needed, which is why eBPF became the 2026 runtime-security default rather than one option among several.
The catch — and it is worth stating plainly — is that eBPF requires a reasonably modern kernel, and the deepest features (like certain enforcement hooks) depend on kernel capabilities such as BTF and LSM support. In practice most current distributions qualify, but very old kernels remain a constraint.
Falco: the detection standard
Falco is the most established of the three. Created by Sysdig, donated to the CNCF in 2018, and now a graduated project, it is effectively the reference implementation of eBPF-based runtime threat detection. Its model is rule-driven alerting: Falco ingests the stream of kernel events via eBPF and evaluates them against a library of rules written in a readable YAML-based syntax, emitting alerts when behavior matches a rule. A rule might say "alert if a shell is spawned inside a container," or "alert if a process writes to a known sensitive path," or "alert on an outbound connection to an unexpected destination."
Falco's strengths are maturity and ecosystem. The rule language is approachable, the default ruleset encodes a large body of community knowledge about suspicious behavior, and because it is the CNCF standard, it integrates with essentially everything — Kubernetes, SIEMs, alerting pipelines, and the broader cloud-native tooling landscape. If your goal is "detect and alert on suspicious runtime behavior with a well-understood, widely-supported tool," Falco is the safe default and the one with the deepest pool of documentation, rules, and operational experience to draw on.
Its deliberate limitation is that Falco is detection-focused. It tells you something bad happened; it is not primarily designed to stop it in the kernel. That is a reasonable scope — many teams want detection feeding a response workflow rather than automated in-kernel killing — but it is the line where the other two tools differentiate themselves.
Tetragon: observability and in-kernel enforcement
Tetragon comes from the Cilium project (originally Isovalent, now part of Cisco) and approaches runtime security from the angle of deep observability plus enforcement. Like Falco it uses eBPF to observe process execution, file access, network activity, and privilege changes, producing rich, Kubernetes-aware event streams. But its defining capability is that it can act in the kernel: through LSM hook enforcement, Tetragon is the open-source eBPF tool with native block and kill capabilities, able to terminate an offending process or override a syscall synchronously, in-kernel, rather than only emitting an alert for something to react to later.
This matters because the gap between detection and response is where damage happens. An alert that a process is exfiltrating data is useful; a policy that kills that process the moment it makes the disallowed syscall is prevention. Tetragon's TracingPolicy custom resources let you declare exactly which kernel behaviors to watch and what action to take — observe, or enforce by signaling, killing, or returning an error. Combined with strong Kubernetes identity context (events are tied to pods and labels, not just PIDs), this makes Tetragon especially strong for teams that want both deep visibility and the ability to enforce policy at the kernel level. The Tetragon cheatsheet covers the policy model in detail.
The trade-off is conceptual weight. Enforcement is powerful and correspondingly dangerous — a careless kill policy can take down legitimate workloads — and the TracingPolicy model has more surface area to learn than Falco's rules. Tetragon rewards teams ready to invest in that model with prevention, not just detection.
Tracee: detection plus forensics
Tracee, from Aqua Security, occupies a third position: eBPF-based detection with an unusually strong forensics emphasis. Like the others it traces kernel events and applies behavioral signatures to flag attack techniques — anti-debugging, dynamic code loading, LD_PRELOAD injection, privilege escalation, container escape. Where it distinguishes itself is in what it can capture for investigation: Tracee can capture executed binaries, memory regions, and per-event network traffic to disk, giving an incident responder the actual artifacts of an attack rather than just a notification that one occurred.
That forensic capture is the differentiator. When a detection fires, the question is immediately "what exactly did it do?" — and Tracee is built to answer that by preserving the evidence. Its signature system (Go and Rego) is extensible, and its event and scope filtering is granular enough to focus on exactly the processes or containers of interest. For teams whose priority is not just knowing an attack happened but being able to reconstruct and analyze it, Tracee's capture capabilities are compelling. The Tracee cheatsheet lays out the event selectors and capture options.
Tracee's positioning means it overlaps with Falco on detection while extending into forensics, and overlaps less with Tetragon's enforcement focus. It is detection-and-investigate rather than detection-and-prevent.
How they compare
The three tools are best understood by their center of gravity rather than a feature checklist, because all three share the eBPF foundation and all three detect suspicious behavior. Falco centers on detection and alerting, with the deepest ecosystem and the gentlest learning curve — the standard choice when you want mature, well-supported threat detection feeding a response pipeline. Tetragon centers on observability plus in-kernel enforcement, the only one of the three that natively blocks and kills, making it the choice when prevention at the kernel level is the goal and the team will invest in its policy model. Tracee centers on detection plus forensic capture, the choice when reconstructing and analyzing attacks matters as much as detecting them.
Their relationship to the commercial landscape also clarifies things. Falco underpins Sysdig's commercial CNAPP platform; Tetragon comes from the Cilium/Isovalent lineage now inside Cisco; Tracee comes from Aqua. In all three cases the open-source tool is genuinely usable on its own, with the vendor offering a managed platform layered on top for teams that want centralized dashboards, broader CNAPP scope, and support. You can adopt any of the three open-source tools without buying anything, which is part of why this space consolidated around them.
A point worth making is that these tools are not strictly mutually exclusive. Some organizations run Falco for its mature detection ruleset alongside Tetragon for enforcement, accepting some overlap in exchange for best-of-both. More commonly, though, teams pick the one whose center of gravity matches their primary need, because running multiple kernel-instrumenting agents has its own overhead and operational cost.
A concrete detection, three ways
To make the differences tangible, take one common attack scenario — a reverse shell spawned inside a container — and see how each tool handles it. The behavior is unambiguous: a container process spawns /bin/sh (or similar) with its standard streams wired to a network socket, a pattern almost never seen in legitimate containerized workloads, which typically run a single defined process.
With Falco, you would have a rule matching "a shell spawned in a container with an attached outbound connection," and when the reverse shell launches, Falco emits an alert through its output channels — to stdout, a file, a SIEM, or an alerting pipeline. The response is whatever your downstream tooling does with that alert: page a human, trigger an automation, log it for investigation. Falco saw it and told you; acting is someone else's job.
With Tetragon, you can do the same detection, but you can also attach an enforcement action to the policy. A TracingPolicy watching for that exec pattern can carry a Sigkill action, so the moment the offending process makes the disallowed call, Tetragon terminates it in-kernel — before the shell is usable. The attack is not just detected but prevented, synchronously, without a round-trip to userspace and back. The trade-off is that you must be confident the policy will never match a legitimate process, because the consequence of a false match is a killed workload.
With Tracee, detection fires from a behavioral signature, and then its forensic capabilities engage: it can capture the executed binary, the memory of the process, and the network traffic of the connection to disk. The incident responder arrives not just to an alert but to a preserved set of artifacts — the actual malware binary, the actual exfiltration traffic — ready for analysis. The emphasis is on making the post-detection investigation as rich as possible.
Same attack, three philosophies: notify, prevent, or preserve-for-analysis. None is wrong; they reflect different answers to the question of what should happen the instant something bad is detected, and that question is the one to answer before choosing a tool.
Choosing and deploying
The decision flows from what you are actually trying to accomplish. If you want runtime threat detection with the least friction and the broadest support, start with Falco — it is the standard for good reasons and the easiest to staff and operate. If your priority is preventing bad behavior in the kernel, not just being told about it, and you run Kubernetes where its identity model shines, choose Tetragon and budget time to learn TracingPolicy and to test enforcement carefully before enabling kill actions in production. If your work is incident-response-heavy and you need to capture and analyze the artifacts of an attack, choose Tracee for its forensic capture.
Whichever you pick, a few deployment realities apply across all three. Confirm your kernels meet the requirements, especially for enforcement features that depend on LSM and BTF. Start in a detect-only posture and tune the rules or signatures against your real workloads before considering any enforcement, because the fastest way to lose trust in a runtime security tool is a false positive that kills a production process. Wire the event stream into your existing observability and SIEM rather than treating it as an island. And remember that low overhead is not zero overhead at extreme scale — validate the impact on your highest-throughput nodes. The eBPF foundation makes all three dramatically lighter than the agents they replaced, but disciplined rollout still matters.
The bottom line
eBPF rewrote runtime security by giving tools kernel-level visibility with verified, sub-1%-overhead safety, retiring the fragile kernel modules and heavy userspace agents that came before. The three open-source tools that define the space each pick a center of gravity on the same foundation: Falco for mature detection and alerting, Tetragon for observability and in-kernel enforcement, and Tracee for detection plus forensic capture. Match the tool to your primary goal — detect, prevent, or investigate — deploy it in detect-only mode first, tune against real traffic, and you get protection that finally fits how cloud-native systems actually run.
References and Resources
Tools
- Falco and what is Falco
- Tetragon — GitHub and docs
- Tracee — GitHub and docs
Background and analysis
- eBPF Runtime Security Tools 2026: Falco vs Tetragon vs Tracee
- Container Runtime Security 2026 — NomadX
- Open Source CWPP: Falco, Tracee, Tetragon Overview
Related 1337skills cheatsheets