Falco vs Tetragon — Kubernetes Runtime Security Comparison

Image scanning catches known vulnerabilities before deployment. Runtime security catches what's actually happening inside running containers — a process spawning a shell unexpectedly, a file write to /etc/shadow, an outbound connection to an IP that's never been contacted before. Falco and Tetragon both do this, with different architectures and different strengths.

Architectural Difference

Falco was built by Sysdig, donated to CNCF, and graduated in 2022. It uses either a kernel module or eBPF probes to observe syscalls, then evaluates them against a rules engine written in its own YAML-based rule syntax.

Tetragon is built by Isovalent (the company behind Cilium) directly on eBPF, with deep integration into Cilium's existing network observability if you're already running Cilium as your CNI.

Writing a Rule — Detecting a Shell Spawned Inside a Container

Falco:

- rule: Terminal shell in container
  desc: A shell was spawned by a container with an attached terminal
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint
  output: >
    A shell was spawned in a container with an attached terminal 
    (user=%user.name container=%container.name shell=%proc.name 
    parent=%proc.pname cmdline=%proc.cmdline)
  priority: NOTICE
  tags: [container, shell, mitre_execution]

Tetragon:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: shell-spawn-detection
spec:
  kprobes:
  - call: "sys_execve"
    syscall: true
    args:
    - index: 0
      type: "string"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/bin/bash"
        - "/bin/sh"
      matchActions:
      - action: Post

Falco's rule language reads more like a security analyst's mental model (named conditions, semantic fields like shell_procs). Tetragon's TracingPolicy is closer to the raw kernel hook level — more powerful for custom low-level detection, steeper to write from scratch.

Where Each One Genuinely Wins

Falco wins on rule library maturity. The Falco community rules repository covers an enormous range of pre-built detections — crypto miners, reverse shells, privilege escalation patterns, container escape attempts — that you can deploy immediately without writing custom rules.

# Falco ships with this out of the box, immediately useful
helm install falco falcosecurity/falco \
  --set falco.jsonOutput=true \
  --set driver.kind=ebpf

Tetragon wins on performance overhead and network correlation. Because it's eBPF-native (not retrofitted onto an eBPF backend the way Falco's eBPF driver is), Tetragon's overhead is generally lower at high event volumes. If you're already running Cilium, Tetragon correlates process-level events with network flow data natively — "this process made this network connection" is a first-class capability, not something you're stitching together from two separate tools' logs.

# Tetragon process + network correlation — this kind of joined view 
# is harder to get cleanly out of Falco without external correlation tooling
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: process-network-correlation
spec:
  kprobes:
  - call: "tcp_connect"
    syscall: false
    args:
    - index: 0
      type: "sock"
    selectors:
    - matchActions:
      - action: Post

Falco wins on broader adoption and integrations. More mature integrations with SIEMs, alerting platforms, and managed cloud security services. If your security team already has Falco-based runbooks or your compliance tooling expects Falco's event format, switching has real migration cost.

Tetragon wins on enforcement, not just detection. Tetragon can actively block syscalls in real time (kill the process, deny the action) as part of the same eBPF program that detects it — lower latency between detection and enforcement than Falco's typical detect-then-alert-then-respond pipeline.

Resource Overhead Comparison

Falco (eBPF driver):     Moderate CPU overhead, scales reasonably with event volume
Falco (kernel module):   Lower overhead than eBPF driver in some workloads, 
                          but kernel module carries its own operational risk 
                          (kernel version compatibility, harder to update safely)
Tetragon:                Generally lower overhead at high event throughput, 
                          benefits directly from any future eBPF performance work 
                          since it's built natively on the same primitives

Honest Recommendation

Use Falco if: you want the largest library of ready-made detection rules, you're not running Cilium and don't want to adopt it just for security, or your existing security tooling/SIEM integrations are already built around Falco's event format.

Use Tetragon if: you're already running Cilium as your CNI and want runtime security that correlates naturally with the network observability you already have, you need real-time enforcement (not just detection), or you're optimizing for lowest possible overhead at high event volumes.

Neither is a clearly "better" choice in the abstract — it depends heavily on whether Cilium is already your networking layer, and whether you need Falco's broader rule ecosystem or Tetragon's deeper performance and correlation story.

If you're running Cilium already: Cilium eBPF Networking Complete Guide