eBPF Runtime Security Tools: Falco vs. Tetragon vs. Tracee Compared

eBPF runtime security tools instrument the kernel at syscall boundaries and function entry/exit points to observe every action a process takes: file opens, network connections, process executions, privilege escalation attempts, and memory modifications.

Key instrumentation points

• Syscall tracepoints: Attach to every syscall entry and exit. This gives visibility into all process-kernel interactions: execve (process execution), open/openat (file access), connect/accept (network), ptrace (debugging / injection attacks), clone (container escapes via namespace manipulation).
• LSM hooks (Linux Security Module): eBPF programs can attach to LSM hooks, which fire before the kernel grants permission. This enables enforcement (blocking) not just detection (alerting).
• Network events via TC and XDP: eBPF programs on traffic control (TC) hooks and eXpress Data Path (XDP) can observe and drop network packets at the kernel level, before they reach userspace.

eBPF vs. kernel modules vs. ptrace

Kernel version requirements: Full eBPF security feature sets require kernel 5.8 or later for BTF (BPF Type Format, enabling CO-RE -- Compile Once, Run Everywhere). Falco has a fallback to kernel module probe for older kernels; Tetragon and Tracee require eBPF and thus a modern kernel.

Falco is the most mature eBPF runtime security tool, graduated within the CNCF. Originally built by Sysdig, it was donated to CNCF in 2018 and is now maintained as an open-source project with commercial support from Sysdig.

Architecture

Falco runs as a DaemonSet in Kubernetes (one pod per node). It loads eBPF probes (or kernel module as fallback) and monitors syscalls. A rules engine evaluates events against a rule set and fires alerts to configured outputs (stdout, file, gRPC, HTTP webhook, Slack, Falcosidekick for fan-out).

Detection model

Falco uses a declarative rules language (YAML) where rules match on syscall fields:

- rule: Terminal shell in container
  desc: A shell was spawned by a container process that is not expected to have a shell
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and not user_known_terminal_shell_in_container
  output: >
    A shell was spawned in a container with an attached terminal
    (user=%user.name container=%container.name shell=%proc.name parent=%proc.pname)
  priority: WARNING

Falco ships 100+ default rules covering: container escapes, privilege escalation (ptrace, capability abuse), sensitive file reads (/etc/shadow, /proc/self/mem), reverse shells, crypto mining patterns, and Kubernetes API server access.

Strengths

• Largest default rule library and community rule contributions
• Falcosidekick enables rich output fan-out (Slack, Teams, PagerDuty, Elasticsearch, S3, SIEM via webhook)
• Kubernetes-aware: rules can reference pod name, namespace, labels, and image
• Graduated CNCF project with broad commercial support (Sysdig, AWS Security Hub integration)
• Supports both eBPF and kernel module probe (wider kernel version compatibility)

Weaknesses

• Detection only, no enforcement -- Falco alerts but cannot block syscalls
• Rule writing requires learning the Falco condition language
• High event volume in busy clusters can create alert fatigue without tuning
• No network policy enforcement (it observes network events but cannot drop connections)

Tetragon is an eBPF security observability and enforcement platform developed by Isovalent (now part of Cisco) as part of the Cilium project. It is open source (Apache 2.0) and is designed to complement Cilium network policy with process-level enforcement.

Architecture

Tetragon runs as a DaemonSet and uses eBPF programs attached to LSM hooks, kprobes, and tracepoints. Its key architectural differentiator: it can enforce policy in-kernel, blocking syscalls before they complete, without userspace roundtrips.

TracingPolicy: enforcement, not just detection

Tetragon uses TracingPolicy Kubernetes CRDs to define monitoring rules and enforcement actions. Example: block a process from reading /etc/shadow:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-shadow-read
spec:
  kprobes:
  - call: "security_file_permission"
    syscall: false
    return: true
    args:
    - index: 0
      type: "file"
    - index: 1
      type: "int"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values:
        - "/etc/shadow"
      matchActions:
      - action: Sigkill

The Sigkill action kills the offending process in-kernel when the policy matches -- zero userspace latency, no race condition window.

Strengths

• In-kernel enforcement (block/kill) via LSM hooks -- the only open-source eBPF tool with this capability
• Deep Kubernetes integration: process trees include pod, namespace, and workload identity
• Network-aware process tracing: correlates TCP connections with the exact process and socket that created them (essential for detecting reverse shells and C2 beaconing)
• Integrates with Cilium network policy for combined network and process enforcement
• Exports events in JSON to stdout, supports Prometheus metrics, and has a Hubble UI integration

Weaknesses

• Requires kernel 5.3+ with BTF enabled (no fallback to kernel module)
• TracingPolicy authoring is more complex than Falco rules
• Smaller default policy library than Falco; requires more policy authoring effort
• Enforcement capability requires careful testing -- a misconfigured kill action can impact workload availability

Tracee is an eBPF-based runtime security and forensics tool developed by Aqua Security and open-sourced under Apache 2.0. Its differentiation is event depth -- Tracee captures far more detail per event than Falco or Tetragon, making it particularly valuable for incident response and supply chain security investigation.

Architecture

Tracee runs as a DaemonSet or CLI tool and attaches eBPF probes to hundreds of syscalls and kernel functions. It outputs structured events to stdout (JSON), gRPC, or webhook destinations. Rules are written in Rego (the same policy language as Open Policy Agent) or Go-based signatures.

Unique capabilities

• Library injection detection: Tracee can detect shared library injection attacks (LD_PRELOAD abuse, dlopen injection) that are used by rootkits to hide malicious activity from other tools
• Kernel module load events: Alerts on kernel module loading -- a common rootkit persistence technique that eBPF-based tools operating in userspace miss
• Memory event tracking: Monitors mmap, mprotect, and ptrace calls that are used in memory-only malware and process injection attacks
• Supply chain event signatures: Detects anomalous behavior from build tools, package managers, and CI/CD processes -- a container that executes curl or wget during a build step generates a different event profile than one that does so at runtime
• Network fingerprinting: Captures detailed TCP/IP connection metadata per process for network forensics

Strengths

• Highest event fidelity of the three tools -- captures argument values, return codes, and process tree context for every instrumented event
• Rego-based rules integrate with Open Policy Agent ecosystem
• Best for incident response forensics: the event detail level supports reconstructing exactly what happened
• Docker and Kubernetes native; runs as a DaemonSet or standalone on Linux hosts

Weaknesses

• Highest operational overhead of the three (more events, more data volume)
• Smaller production deployment footprint than Falco (less community rule content)
• Detection-only (no in-kernel enforcement like Tetragon)
• Rego rule authoring has a steep learning curve vs. Falco's YAML syntax

Decision framework

• You want out-of-the-box detection coverage with minimal rule authoring: Start with Falco. The default rule library and Falcosidekick output flexibility get you monitoring in a day.
• You want in-kernel enforcement (block, not just detect): Tetragon is the only open-source option. Especially relevant if you are already running Cilium for Kubernetes networking.
• You need deep forensic capability for incident response or supply chain investigation: Tracee's event detail level makes it the best tool for reconstructing incidents and detecting supply chain compromise behaviors.
• You want comprehensive coverage: Deploy Falco for broad detection alerting (SIEM integration via Falcosidekick) plus Tetragon for enforcement on your highest-risk workloads. This is an increasingly common production pattern.

Commercial options: Sysdig Secure (Falco-based, adds vulnerability scanning, compliance, and UI), Isovalent Enterprise (Tetragon-based, adds network policy visualization and enterprise support), Aqua Security platform (Tracee-based plus CSPM and image scanning).

Kubernetes deployment

All three tools deploy as DaemonSets, requiring privileged mode and access to the host PID namespace. In hardened cluster configurations, this requires explicit RBAC and PodSecurityAdmission policy exceptions.

Kernel version verification

Before deploying Tetragon or Tracee, verify BTF support on all nodes:

ls /sys/kernel/btf/vmlinux

If the file is absent, BTF is not available on that kernel. For mixed-kernel environments (common in autoscaling groups with different AMI versions), Falco's kernel module fallback provides broader compatibility.

Alert volume management

Falco in a busy cluster can generate 10,000+ events per second. Practical approaches:

• Start with the Falco default rules and disable rules irrelevant to your environment (the NOTICE and DEBUG priorities generate the most volume)
• Use Falcosidekick's built-in deduplication and alert grouping before forwarding to your SIEM
• Route WARNING and above to PagerDuty / incident response; NOTICE and below to log storage for post-incident investigation

Testing rule effectiveness

Use Atomic Red Team or Stratus Red Team to simulate the attack techniques your rules should detect. Run simulated container escapes, privilege escalation attempts, and reverse shell launches and verify alerts fire as expected before trusting your detection coverage.

Resource overhead

In production benchmarks on busy Kubernetes nodes (1,000+ req/s workloads):

• Falco eBPF probe: 1-3% CPU overhead, 50-150MB memory
• Tetragon: 2-5% CPU overhead, 100-250MB memory (higher due to enforcement path processing)
• Tracee: 3-7% CPU overhead, 150-300MB memory (highest event capture volume)

Measure on your own workload profile before committing to DaemonSet deployment at scale.