Falco vs Tetragon: what to evaluate for runtime security

01

What each project is

Falco is a CNCF graduated runtime security project. It consumes events, most commonly system calls collected by a kernel driver or eBPF probe, and evaluates them against a rule set written in YAML: conditions built from fields, macros, and lists, with exceptions for legitimate cases. When a condition matches, Falco emits an alert with the fields named in the rule's output template, and downstream tooling routes it.

Tetragon is an eBPF-based security observability and runtime enforcement project from the Cilium community, also hosted by the CNCF. It is configured through tracing policies: Kubernetes resources that select kernel functions or tracepoints, filter their arguments in the kernel, and optionally attach actions. Events are emitted as JSON, enriched with process and Kubernetes identity, and some actions can enforce directly in the kernel.

The two are not interchangeable and not strictly competitors. Falco's center of gravity is a detection rule library with a large default set. Tetragon's center of gravity is precise kernel-level observation with the option to enforce. Teams run one, the other, or both.

02

Evaluation dimensions

Score nothing. Instead, write down what you need in each dimension, then run the practical test in the last column on a representative workload.

Evaluation dimension			Practical test
Sensor	eBPFor kernel moduleModern eBPF probe, legacy eBPF probe, or kernel module; plugins for other sources	eBPFeBPF programs on the kernel hooks your policies select; in-kernel argument filtering	Confirm driver or BTF support on your kernel versions before anything else
Detection and policy	RulesRule conditions with macros, lists, and exceptions; published rule maturity guidance	Tracing policiesTracing policies with event selection and actions	Express one relevant scenario and a benign look-alike
Response	External toolingAssess the specific external response tooling you would deploy; do not label it universally incapable	Signals · overridesSupports return-value overrides and signal actions	Verify whether the operation is prevented and how the application handles it
Investigation	Output fieldsInspect fields emitted by the selected event source and rules	JSON eventsInspect fields emitted by the selected tracing policy	Can responders identify workload and observed sequence?
Performance impact	Measure itScales with event volume, rule count, and driver; drops events under pressure	Measure itScales with the hooks selected; in-kernel filtering reduces volume	Measure CPU, memory, and event loss on one representative node per class
System stability impact	Userspace engineUserspace engine; never blocks a workload; kernel module carries more risk than eBPF probes	In-kernel enforcementIn-kernel enforcement can fail an operation the application did not expect	Roll out any enforcement in observe or audit form first; test the failure path
Operations	You operate itMaintain rules, exceptions, and output plumbing	You operate itMaintain tracing policies and kernel compatibility	Validate change rollout and rollback

Chips describe status and scope, not a score. Performance and stability rows are things to measure in your environment, not vendor figures.

03

When Falco fits

Falco is a candidate when the team wants a rule-driven detection workflow and is prepared to maintain the surrounding pipeline: the ruleset and its exceptions, the alert routing, and whatever response tooling the team chooses. The default ruleset gives a broad starting point, and the rule language is readable by analysts who do not work in the kernel.

Expect to spend the early weeks tuning. The published style guide and exceptions mechanism exist because tuning is part of operating Falco, not a sign that something is wrong.

04

When Tetragon fits

Tetragon is a candidate when kernel-level observability and policy-controlled enforcement are central requirements: when the team needs to see specific kernel functions with their arguments, filter at the source to control event volume, or deny an operation in the kernel rather than react after the fact.

Expect the policy authoring to require kernel knowledge. Selecting the right hook, understanding its arguments, and confirming that an override is safe on your kernel version are engineering tasks, and each policy should be tested for both detection and enforcement behavior.

05

What your SOC still needs to investigate

Neither project closes an investigation on its own. Both produce events with process and container identity; both leave the join to a request, the workload's owner, the image's vulnerability status, and the outcome of an attempted operation to the responder or to other systems.

Whichever you choose, plan for the questions that follow an alert: which service is this, which request caused it, did the attempted action succeed, what happened next, and what evidence might be missing. If those answers live in five tools, the sensor choice is only part of the design.

• Workload ownership and image version: from your Kubernetes and CI metadata.
• Request context: from application tracing or access logs, where instrumented.
• Outcome of an attempted operation: from the event's return value where captured, otherwise from network or file-system logs.
• Related events in order: joined by process tree and time, not by alert title.

06

A reproducible evaluation checklist

Run the same checklist against both projects on the same cluster and the same workloads. Record versions, kernel, and dates so the comparison can be repeated after an upgrade.

• Pin versions: project release, kernel version, driver or BTF availability, Kubernetes version.
• Pick three scenarios that matter to you (for example a shell from a web process, a sensitive file read, an unexpected outbound connection) and one benign look-alike for each.
• Write the rule or policy for each scenario; note how long it took and what knowledge it needed.
• Run the attack case and the benign case; record fire / no-fire for each.
• If you need enforcement, verify the operation is prevented and observe how the application behaves when it receives the error.
• Measure CPU, memory, and event volume on a representative node before and during the test; do not extrapolate to the whole fleet from one node.
• Send the output to your responders and ask them to identify the workload and the sequence without help.
• Change one rule or policy and roll it out; confirm the change took effect where expected and nowhere else.