Three eBPF projects land on every Kubernetes runtime security shortlist in 2026: Falco, Tetragon, and Tracee. They get compared as if they were three brands of the same product. They are not. They answer three different questions, and any benchmark that ranks them on one axis is measuring the wrong thing.

The expensive mistake is treating them as interchangeable. A team runs Falco for a year, gets annoyed that it "only alerts," rips it out for Tetragon "because Tetragon can block," and discovers six weeks later that it has traded a paging problem for an outage problem. Those are not the same risk decision. Let me separate the three before anyone reaches for a feature matrix.

Falco answers: did something suspicious just happen, and who do I page?

Falco is a detection engine. A rules engine matches syscall events and Kubernetes audit events against a ruleset, and routes the hits, to Slack, PagerDuty, or a SIEM, through Falcosidekick. That is the whole shape of it: see the event, match the rule, fire the alert.

It is also the most mature of the three by a clear margin. Falco graduated within the CNCF on February 29, 2024, the only one of these three that is a graduated CNCF project. It was created by Sysdig in 2016 and was the first runtime security project to enter the CNCF Sandbox, in 2018. That lineage matters less for raw capability and more for the boring things that decide procurement: governance sign-off, a credible expectation of long-term maintenance, and a security team's willingness to bet a control on it.

One thing people miss: Falco does not block by default. Its job ends at the alert. If you want it to stop something, you wire that alert into an admission controller or a response action yourself. The detection is the product. The response is your integration.

Tetragon answers: can I stop this in the kernel before it completes?

Tetragon is the enforcement tool. It is built as part of the Cilium project, originally by Isovalent (now part of Cisco), and its differentiator is in-kernel enforcement with no userspace round trip.

The mechanism is worth understanding because it explains both the appeal and the danger. Per Tetragon's enforcement documentation, it stops an action by overriding the return value of a kernel function and sending a signal such as SIGKILL to the offending process. It does this by attaching eBPF programs to kprobes, tracepoints, and LSM hooks. So it can kill a process or fail a syscall before that syscall returns. There is no "alert fires, controller reacts, maybe we catch it" gap. The action just does not complete.

That is genuinely powerful. It is also the riskiest mode you can run in production, which is the part the marketing buries.

The inversion nobody puts on the slide

In-kernel enforcement sounds strictly better than alerting. It is not. It is more dangerous, and the danger scales with exactly the feature people buy it for.

Think about what a false positive costs in each tool. A false positive in Falco pages an engineer who looks at it, sighs, and tunes the rule. Annoying. Survivable. A false positive in Tetragon enforcement mode sends SIGKILL to a legitimate process in your hot path. Now a tuning error is an outage, and it happened inline, in the kernel, before anything in userspace could second-guess it.

Detection is forgiving of imperfect rules. Enforcement is not. The capability everyone reaches for first is the one that demands the most rule maturity before you can trust it with a kill signal. Pick your tools on a CPU-overhead benchmark and you have optimized the cheapest variable while ignoring the one that actually bites: how many hours of tuning each mode needs before it is safe to leave on.

Tracee answers: what exactly happened, so I can reconstruct it?

Tracee is the forensics tool. Built by Aqua Security's research team (Nautilus), it pairs a deep event collector, tracee-ebpf, with a signatures engine, tracee-rules. Its design point is event depth. It captures far more context per event than the other two, which is precisely what you want at 2 a.m. when you are rebuilding an attack timeline or working out how far a supply chain compromise reached.

There is a tension baked into that depth, and it is honest to name it. Per-event richness is the reason Tracee is valuable for incident response, and it is also why deep tracing carries more overhead than aggressive in-kernel filtering. You pay for the detail. The trick is to pay for it on the hosts where reconstruction actually matters, not fleet-wide at full verbosity on nodes you will never forensically examine.

The constraint that decides it before features do: kernel version

Before any feature comparison, inventory your kernels. This narrows the field faster than any capability checklist.

Tetragon documents testing on LTS kernels back to 4.19. Falco retains a kernel-module fallback for older kernels where modern eBPF features, BTF and CO-RE on 5.8 and up, are not available. If you run a fleet with mixed or genuinely old kernels, or a module-restricted environment, that fact alone may eliminate options before you ever open a feature matrix. I have watched a careful tool selection collapse the moment someone finally ran uname -r across the actual fleet instead of the shiny new nodes. Do that first.

The honest counterpoint: isn't one tool simpler to run?

The strongest objection to all of this is operational: three tools is three sets of rules, three upgrade cycles, three things to keep tuned. Real cost. So why not consolidate?

Because the jobs do not actually overlap enough to collapse. Falco gives you broad detection coverage and routing. Tetragon gives you surgical kill-it-now enforcement on a few paths you understand cold. Tracee gives you the depth to investigate after the fact. Force one tool to do all three and you get a detection layer you are afraid to put in blocking mode, or an enforcement tool you are running at forensic verbosity and paying for it in overhead. The consolidation saves operational surface and loses the thing each tool was good at. The common production shape is hybrid for a reason: broad detection, narrow enforcement, on-demand forensics, each scoped so you are not running every rule at full depth on every node.

How to choose

Start from the question, not the tool. Then work down this list.

  • Write down the question first. Need to know and route alerts: Falco. Need to stop a specific known-bad action in the kernel: Tetragon. Need to reconstruct an incident in detail: Tracee. A "which is best" question with no stated job is unanswerable, and vendors love that ambiguity.
  • Check kernel versions before features. Run uname -r across the real fleet. Any nodes below 5.8, or a module-restricted environment, and your choice is decided: Falco's module fallback or Tetragon's 4.19 support may be your only viable paths. This gate comes before everything else.
  • If you can only run one, run detection. A tool that reliably tells you what happened is more valuable, and far less dangerous, than one configured to act on rules you have not earned trust in yet. Start with Falco. Add enforcement after the detection layer is quiet.
  • Never deploy enforcement on day one. Run every Tetragon policy in observe mode first. Confirm zero false positives on the target path across a real traffic window (include a deploy, a batch job, a traffic spike, whatever your hot path actually does). Only then enable the SIGKILL action, and only for that one path. Promote path by path: a known cryptominer binary, a container-escape primitive, an unexpected write to a credential path. Never enable a ruleset-wide kill at once. Treat an enforcement policy the way you treat a firewall deny rule in prod.
  • Scope Tracee to where it pays. Full event depth on bastion hosts, CI runners, and crown-jewel workloads. Not full verbosity cluster-wide, or you are buying forensic detail on hosts you will never investigate.
  • Don't pick on the overhead benchmark. The number that decides safety is tuning hours to trust, not CPU percent. Budget the tuning time explicitly before you commit to a blocking mode.

The short version: these three are not three tiers of one product. They are three jobs. Match the tool to the job, gate on your kernels, and earn your way into enforcement instead of starting there.

Sources