On February 29, 2024, Falco became the first runtime security project to graduate the Cloud Native Computing Foundation — a status Kubernetes itself reached nearly six years earlier, in March 2018, and one that only a handful of projects (Kubernetes, Prometheus, Envoy, containerd, and a small list of others) hold at all. Falco had been open-sourced by Sysdig back in 2016 and spent eight years moving through CNCF Sandbox and Incubating before graduation, which says something about how long it takes a kernel-level detection engine to earn broad trust. But Falco is no longer the only serious open-source option. Cilium's Tetragon, built by Isovalent and now under the CNCF umbrella, enforces directly in-kernel via eBPF rather than only observing. Aqua Security's Tracee ships roughly 330 prebuilt syscall and security-event detections out of the box, curated by Aqua's Nautilus research team. All three are free, all three use eBPF (Falco can also fall back to a kernel module), and all three get pitched as "the" answer to Kubernetes runtime security. They are not interchangeable. This post compares their architectures and tells you which one fits which environment.
What makes Falco the default choice for most teams?
Falco's core design is a syscall stream — captured via an eBPF probe or a legacy kernel module — matched in userspace against a YAML rules engine. That architecture makes it the most flexible of the three: rules are human-readable, community-maintained, and extendable with custom conditions in Falco's own rules language, and Falco's plugin framework extends detection beyond syscalls into cloud provider logs, Kubernetes audit events, and other structured data sources. That breadth is why Falco has the largest surrounding ecosystem of the three projects — more third-party rule sets, more vendor integrations, and more Kubernetes-specific documentation from its eight years of public development. The tradeoff is architectural: because events stream to a userspace engine for matching, Falco is fundamentally an observability and alerting tool. It tells you something suspicious happened; it does not, by itself, stop the syscall from completing. For teams that want broad, customizable detection coverage with the largest community rule library to draw from, and that are comfortable pairing alerts with a separate response workflow, Falco remains the most battle-tested starting point.
When does Tetragon's in-kernel enforcement matter more than broad rule coverage?
Tetragon is a sub-project of Cilium, developed by Isovalent under Apache-2.0 license (source at cilium/tetragon on GitHub), and it takes a structurally different approach: filtering and policy decisions happen directly in-kernel via eBPF, not after an event has already been shipped to a userspace process. That distinction matters for two reasons. First, enforcement: Tetragon can block or kill a process's syscall in real time, in-kernel, rather than only alerting after the fact — closer to a kernel-level firewall for process behavior than a log pipeline. Second, overhead: because policy matching happens before data crosses into userspace, Tetragon avoids paying the cost of streaming every observed event out for evaluation. Tetragon is also natively Kubernetes-aware, treating pods and namespaces as first-class identities in its policies rather than bolting Kubernetes context on afterward. The clearest fit is a cluster already running Cilium as its CNI — Tetragon shares tooling and mental model with it — or any environment where the requirement is "stop this action," not "tell me about this action."
Why would a team pick Tracee over Falco or Tetragon?
Tracee, maintained by Aqua Security (aquasecurity/tracee on GitHub) and billed as "Linux Runtime Security and Forensics using eBPF," differentiates on depth and curation rather than architecture alone. Out of the box it captures roughly 330 syscalls and custom security events, with detection logic — fileless execution, unexpected kernel module loading, and similar techniques — built and maintained by Aqua's dedicated Nautilus research team, the same group that publishes Aqua's broader cloud-native threat research. That gives Tracee an edge for teams that want strong forensic-grade visibility without hand-writing their own detection rules from scratch, since the content ships pre-curated by researchers whose full-time job is tracking emerging container attack techniques. Tracee also doubles as the open-source engine underneath Aqua's commercial CNDR and Dynamic Threat Analysis products — the same pattern Sysdig follows with Falco — so a team that outgrows the open-source tier has a direct, technically consistent commercial upgrade path rather than a rip-and-replace migration to an unrelated vendor.
How do the three projects differ on enforcement versus observation?
The sharpest technical line between them is what happens after a detection fires. Falco is observation-first: its userspace rules engine is built to alert, and any blocking action requires wiring Falco's output into a separate response system yourself. Tracee is similarly observation-first, focused on producing rich forensic events rather than enforcing policy in-kernel. Tetragon is the outlier, applying its filtering and enforcement logic directly in the kernel path, which is what enables real-time blocking with lower overhead than a stream-everything-to-userspace design. This is not a maturity gap — it is a deliberate design choice reflecting each project's origin. Falco was built as Sysdig's answer to "what is happening in my containers," Tracee as Aqua's answer to "what happened, forensically, in detail," and Tetragon as Cilium's answer to "how do I stop this at the network and syscall layer I already control." Picking based on whether your priority is alert breadth, forensic depth, or enforcement latency will get you to the right project faster than picking based on GitHub star count.
Can you run more than one of these tools together?
Yes, and several teams do, because the three tools are not strictly redundant. A common pattern is running Falco or Tracee for broad, alert-oriented detection coverage across a cluster while relying on Tetragon specifically on nodes or workloads where in-kernel blocking is worth the additional operational complexity of enforcement policies — for example, on internet-facing workloads where killing a reverse shell in milliseconds matters more than logging it for later review. The real cost of running multiple eBPF-based tools simultaneously is operational: each one loads its own eBPF programs, maintains its own rule or policy language, and produces its own event format, which means a security team ends up correlating alerts across two or three separate consoles unless something downstream unifies them. That correlation gap — not the detection engines themselves — is usually the harder problem to solve once a cluster grows past a handful of nodes.
How Safeguard fits into a runtime security stack
Safeguard doesn't compete with Falco, Tetragon, or Tracee at the kernel-collection layer — its own eBPF runtime collector is rolling out for Linux rather than generally available today, and Safeguard's runtime rule engine is designed to consume and correlate runtime signal, not replace kernel-level syscall capture. Where it adds value on top of tools like these is correlation: Safeguard's rule engine maps runtime detections (reverse shells, crypto-miners, container escapes, fileless execution, privilege escalation, LOLBin chains) to MITRE ATT&CK techniques and feeds them into a CNAPP layer that checks whether a flagged workload is simultaneously running, network-reachable, exposed to an untrusted boundary, and over-privileged. A detection that fires on an isolated, non-exposed pod gets triaged differently than the same detection on an internet-facing, root-privileged one — and that correlation, plus gated response actions (alert, block, kill, quarantine, isolate) landing in one unified findings view, is what a team gets by pairing any of these three open-source engines with a platform built to reason about the findings they produce.