Runtime security in 2026: revisit Falco, Tetragon and Tracee before you trust another runtime alert

Most teams now scan images before they ship and check manifests before they reach the cluster. Then the container starts, and for many of us the story stops there. Nobody is really watching what the process does after it is running: which binaries it starts, which files it reads, where it connects. That gap is what runtime security tools try to close. They sit on every node, watch the kernel, and raise an alert (or stop the action) when a workload behaves in a way it should not.

This post is about that runtime layer on Linux and Kubernetes nodes. It is not about checking manifests at admission time, which we covered in Kubernetes admission policy in 2026, and it is not about finding known CVEs in images, which is the job described in vulnerability scanners in 2026. Running untrusted code inside a stronger boundary is a separate topic, see container sandboxing in 2026. Tetragon comes from the Cilium project, but you do not need Cilium as your network plugin to use it; the CNI choice has its own post, Kubernetes pod networking in 2026. And since every runtime tool produces a stream of events, your log pipeline matters too, see Fluent Bit, Vector and the OpenTelemetry Collector.

Here we look at the three open source tools most teams shortlist: Falco, Tetragon and Tracee. We cover current versions, the 2026 advisories, how each collects events, rules, outputs, enforcement, costs and a step by step plan, and we end with a small, safe drill and a plain list of what we did not run.

A scenario to keep us honest

Imagine a company in Raipur that builds procurement, weighbridge and payment software for rice millers and steel traders across Chhattisgarh. The company is invented for this post. It has about 40 engineers and a three-person platform team.

The setup today:

• A production Kubernetes cluster of nine Ubuntu nodes, built with kubeadm, running the billing, weighbridge sync and payments services.
• A small staging cluster on k3s.
• Ten plain VMs for the database, the message broker and a reporting service.
• Falco was installed on production in 2023 from the Helm chart, with Falcosidekick sending alerts to a Slack channel. After a node image upgrade broke the kernel module build, someone switched Falco to the legacy eBPF probe.
• The Slack channel gets a few hundred alerts a day. Most are the same five rules. The channel has been muted by almost everyone.

Three things push the team to revisit this. First, a bank that uses their payment module has sent a security questionnaire asking how they detect and respond to suspicious activity inside running containers. Second, Falco 0.44.0 removed the legacy eBPF probe, so the current setup cannot simply be upgraded. Third, one engineer wants to replace Falco with Tetragon because “it can block, not just alert”, and another has read about Tracee. The team lead wants a calm decision.

We will come back to Raipur in the worked plan.

The short version

• A runtime alert is only useful if someone reads it and knows what to do. The muted Slack channel is the real problem in Raipur, not the tool.
• Falco (0.45.1) is the mature, rule-first detector. It ships a maintained default rule set, a simple YAML rule language and a large output ecosystem through Falcosidekick. It is CNCF graduated. In 2026 it removed the legacy eBPF probe, the gVisor engine and gRPC output, so older setups need attention before upgrading.
• Tetragon (1.7.1) is the eBPF-first tool from the Cilium project. Policies are Kubernetes resources that hook kernel functions, filter in the kernel, and can enforce by overriding a return value or sending a signal. It is powerful, but writing good policies needs kernel knowledge.
• Tracee (0.24.1) from Aqua Security is an eBPF tracer with many built-in events and Go-based detections. Its last release was in November 2025, and the main branch is still active. It is a good forensic and learning tool; check the release pace before you make it your only detector.
• All three need root or strong capabilities on every node. The agent is itself a high-value target. Patch it like one.
• Enforcement is a sharp tool. Start with detection, tune the noise, and then enforce on a few narrow, well-tested cases.

Where things stand on 28 October 2026

Falco. The latest release is Falco 0.45.1, published on GitHub at 10:49 UTC on 19 October 2026, which is 4:19 PM IST. It bundles falcosecurity/libs 0.26.1 and driver 11.0.1. Falco 0.45.0 came out on 21 September 2026 and Falco 0.44.0 on 26 May 2026. Falco is licensed under Apache 2.0. The CNCF page says Falco was accepted on 10 October 2018, moved to Incubating on 8 January 2020 and to Graduated on 29 February 2024. In the libs repository, the driver folder carries both GPL-2.0 and MIT licence texts, while the rest of libs is Apache 2.0.

Falco companions. Falcosidekick 2.35.1 was released on 26 October 2026 at 6:24 PM IST, falcoctl 0.14.3 on 26 October 2026, and the falco-rules 5.2.0 set on 7 September 2026. The Helm chart falco-9.2.1 was published on 20 October 2026. Falco Talon, a response engine in the same organisation, has a last tagged release of v0.3.0 (5 February 2025), while its Helm chart falco-talon-0.5.0 is dated 28 September 2026.

Tetragon. The latest release is Tetragon v1.7.1, published at 11:40 UTC on 25 August 2026, which is 5:10 PM IST. Tetragon v1.7.0 came on 29 April 2026, v1.6.1 on 31 March 2026 and v1.6.0 on 23 October 2025. The repository is Apache 2.0; the bpf folder carries GPL-2.0 and BSD-2-Clause licence files for the kernel side. Tetragon is part of the Cilium project, which is a CNCF graduated project, and the 2026 advisories credit Isovalent engineers with triage and fixes. The 1.7 release notes include several Windows fixes, so a Windows port is in progress, but this post deals only with Linux.

Tracee. The latest release is Tracee v0.24.1, published at 00:31 UTC on 19 November 2025, which is 6:01 AM IST that day. v0.24.0 came out on 14 November 2025. There has been no tagged release in 2026 so far, but the main branch had commits as recently as 29 September 2026. Tracee is licensed under Apache 2.0, and its eBPF C code carries a GPL-2.0 SPDX header. It is an Aqua Security open source project and is not a CNCF project. Tracee v0.23.0 removed Rego signature support, so custom detections are now written in Go.

Security in 2026

Runtime tools run with high privilege, so their own bugs matter. Here is what the projects published. We list advisories as the projects describe them.

Falco and libs. On 23 September 2026, falcosecurity/libs published advisory GHSA-jh29-p45v-8ghg (medium). Path-based rules could be silently bypassed by opening a file through an overlong path padded with redundant parts like repeated ./. The path field then became a fixed placeholder instead of the real path, so rules such as the default sensitive file rule did not match, with no warning. The fix is in libs 0.26.0 and Falco 0.45.0. This is a good reminder that a detector can fail quietly. An older Falco advisory from April 2025 (low) also explains that operations done through io_uring do not produce separate syscalls, so Falco’s syscall rules do not see them, and points to the krsi plugin as the mitigation.

Tetragon. On 27 July 2026, Tetragon published CVE-2026-65960 (high). Helm deployments that exposed the gRPC API on an unauthenticated TCP listener such as localhost:54321 could be reached by any pod on the same node running with hostNetwork. Such a pod could add or remove tracing policies and change Tetragon’s behaviour. It is fixed in v1.7.0, which also changed the default server address to a Unix socket at /var/run/tetragon/tetragon.sock. On 20 October 2026, two low advisories followed, both fixed in v1.7.1: redaction filters could leave part of an environment variable unredacted, and control characters in process arguments could inject into terminal output.

Tracee. The GitHub advisory list for Tracee showed no published advisories when we checked on 28 October 2026.

Lessons:

• The agent’s own API is an attack surface. Use a Unix socket, not a TCP port, and keep hostNetwork pods to a minimum.
• A silent miss is worse than a noisy alert. Test your important rules with real triggers after every upgrade.
• If you collect environment variables or arguments, you will collect secrets. Redact them and check that redaction works.

The first question: what do you want to happen when something bad runs?

Before comparing tools, write down the answer to one question for your top five threats: when this happens, who gets told, how fast, and what do they do? For Raipur, the list might be: a shell inside a payments pod, a new binary written and executed inside a container, a read of a mounted service account token by an unexpected process, an outbound connection from the database VM to an unknown address, and a kernel module load on a node.

If you cannot answer “who reads this and what do they do”, adding a better detector will only make a louder muted channel.

What each tool is

Falco

Falco watches system calls and other event sources, enriches them with container and Kubernetes metadata, and checks them against rules. It was created at Sysdig (the repository dates from January 2016) and was accepted into the CNCF in October 2018. The syscall source has two drivers today. The modern eBPF probe is the default; it uses CO-RE and BTF, is built into the Falco binary, and usually needs kernel 5.8 or later (the docs say the real requirement is BPF ring buffer and BTF support). The kernel module is the other option for older kernels, and it needs full privileges. The legacy eBPF probe was removed in 0.44.0. Falco also takes plugins, for example a Kubernetes audit log source and the container metadata plugin.

Rules are YAML with a condition written in Falco’s own filter language, plus output, priority and tags. Lists and macros let you reuse pieces. A maintained default rule set comes from the falcosecurity/rules repository.

Falco itself writes to stdout, files, syslog, a program or HTTP. Falcosidekick receives those alerts and forwards them; its README lists 68 output targets across chat, alerting, logs, SIEM, queues, storage and others. Since 0.44.0, gRPC output is gone.

Tetragon

Tetragon loads eBPF programs that attach to kernel functions (kprobes), tracepoints, user-space functions (uprobes), LSM hooks and, since 1.7.0, fentry. Out of the box it reports process execution and exit with full ancestry and Kubernetes identity. Everything beyond that comes from TracingPolicy resources, which say which hook to attach, which arguments to read, which selectors to filter on and which action to take.

The key design point is that filtering happens in the kernel, so only matching events reach the agent. 1.7.0 added evaluation of CEL expressions in BPF. Actions include Post (send an event), Override (make the function return an error so the operation does not happen) and Sigkill or other signals. The docs are careful here: a signal alone does not guarantee the operation was stopped, so combine it with Override when you really need to block.

Output is JSON events, available through the tetra CLI, a log file on each node and the gRPC API, plus Prometheus metrics.

Tracee

Tracee is an eBPF-based runtime security and forensics tool. It traces a large set of syscalls and kernel events, and adds derived security events such as a dropped executable or a hooked syscall. A Policy resource (YAML) chooses a scope (global, or specific workloads) and the events to record, with filters. Up to 64 policies can be loaded. Custom detections are written in Go and loaded with --signatures-dir. Output goes to destinations in JSON, table or Go template format. Tracee needs BTF, root or a set of capabilities, and some events need /proc/kallsyms.

Side by side

Licence and governance

• Falco: Apache 2.0, CNCF graduated, vendor-neutral governance, with Sysdig as a large contributor.
• Tetragon: Apache 2.0 (kernel side GPL-2.0 and BSD-2-Clause), part of the CNCF graduated Cilium project.
• Tracee: Apache 2.0 (eBPF side GPL-2.0), run by Aqua Security, not in a foundation.

Detection approach

• Falco: syscall stream to user space, rules evaluated in user space. Easy to reason about, but every event in the selected syscall set crosses to user space.
• Tetragon: hooks chosen by policy, filtering in the kernel. Very efficient when the policy is narrow, and able to hook deeper than syscalls.
• Tracee: a broad catalogue of events, filtered by policy, with detections in user space.

Rules and policies

• Falco: YAML rules with a readable condition language and a large maintained default set. A new engineer can write a useful rule on day one.
• Tetragon: TracingPolicy CRDs. You need to know which kernel function to hook and which argument index matters. The project provides a policy library to start from.
• Tracee: Policy YAML for selection, Go for custom detections. Rego was removed in v0.23.0.

Enforcement

• Falco: detection only. Response comes from outside, for example Falcosidekick calling a function or Falco Talon.
• Tetragon: in-kernel Override and signals, inline with the operation.
• Tracee: detection and forensics; we did not find an enforcement action comparable to Tetragon’s in the docs we read.

Outputs and integration

• Falco: Falcosidekick with 68 targets is the strongest ecosystem here, plus a web UI.
• Tetragon: JSON and gRPC; you ship the log file with your normal log agent.
• Tracee: JSON or template output to destinations; you ship it yourself.

Kernel and platform needs

• Falco: modern eBPF needs ring buffer and BTF (usually 5.8 or later); the kernel module covers older kernels.
• Tetragon: kernel 4.19 or later with BTF; not all features on older kernels; kernel lockdown in confidentiality mode stops it loading.
• Tracee: long-term kernels from 5.4, BTF required, x86 and arm64.

Performance

None of the three publishes a neutral benchmark we can rely on. The Tetragon 1.0 announcement in November 2023 reported 1.68% CPU overhead for tracking all process execution during a Linux kernel build, and 2.46% when also writing every event as JSON to disk. That was the vendor’s own run, on a deliberately busy workload. Tetragon also exposes per-program overhead metrics. Falco documents tuning for dropped events and buffer sizes. Measure on your own nodes with your own policies; overhead depends far more on what you hook than on the tool name.

A worked plan for Raipur

Step 1: Inventory and freeze. Record the Falco version, chart version, driver type, rules files, custom rules and every Falcosidekick output. Note kernel versions on all nodes and VMs and check that /sys/kernel/btf/vmlinux exists. Do not upgrade anything yet.

Step 2: Fix the alert path first. Move alerts from the muted Slack channel to the log store and an on-call tool. Pick the five threats from the first question and make sure each has an owner and a runbook.

Step 3: Measure the noise. Count alerts per rule for a week. In Raipur, five rules make most of the noise. For each, either add a precise exception (a known image, a known binary, a known namespace) or lower its priority. Never disable a rule just because it is loud without writing down why.

Step 4: Decide the main detector. Path A: stay on Falco, move to 0.45.1 with the modern eBPF probe, and keep Falcosidekick. Path B: move to Tetragon as the main tool. For Raipur, with Ubuntu kernels that have BTF, three platform engineers and no kernel specialist, Path A is the sensible default. The rule language and default rules carry a lot of value for a small team.

Step 5: Upgrade Falco carefully. Read the 0.44.0 and 0.45.0 breaking changes. Remove the legacy probe setting, check that nothing uses gRPC output, and review custom rules that relied on the old string matching, since 0.45.0 changed how conditions see invalid and non-printable bytes. Run in staging first. Then trigger each of the five threats on purpose and confirm the alert arrives, including an overlong path test for the sensitive file rule.

Step 6: Trial Tetragon for enforcement, narrowly. On staging only, install Tetragon 1.7.1 with the gRPC API on the Unix socket. Start with detection-only policies for two cases: kernel module loads and writes to a few sensitive host paths. After two weeks with no false positives, add Override for one case. Keep a documented way to remove the policy quickly.

Step 7: Try Tracee as a forensics tool. When an incident happens, a short Tracee capture on one node can give rich detail. Keep it as an investigation tool, not a permanent agent, until its release pace is clearer.

Step 8: Patch routine. Subscribe to the security advisories of each tool you run. Review new releases monthly. After each upgrade, run the trigger tests from Step 5 again.

When each tool is better

• Falco: broad detection quickly, readable rules, a default rule set and many alert destinations. It suits most small and medium teams.
• Tetragon: in-kernel enforcement, narrow and cheap policies, deep kernel hooks and a link with Cilium network visibility, when someone can read kernel function signatures.
• Tracee: investigation and learning, with a rich event catalogue and derived events.

When not to change

• If Falco works, alerts are read and acted on, and you can upgrade to 0.45.x, there is no strong reason to switch.
• If your only reason for Tetragon is “it can block”, first ask which exact actions you would block and who will handle the outages a wrong block causes.
• If your kernels lack BTF, fix the base image first. A new tool will not help.
• Do not run two runtime agents on the same nodes for long. You double the privilege, the cost and the alerts.

A short history

• January 2016: the Falco repository is created at Sysdig.
• 2018: Falco accepted into the CNCF Sandbox.
• 2019: Tracee repository created by Aqua Security.
• 2022: Tetragon open sourced under the Cilium project.
• November 2023: Tetragon 1.0.
• February 2024: Falco graduates in the CNCF.
• 2025: Tracee drops Rego signatures (v0.23.0); Tetragon 1.6.0 in October.
• 2026: Falco 0.44.0 removes the legacy eBPF probe, gVisor engine and gRPC output; Tetragon 1.7.0 adds CEL in BPF and fixes CVE-2026-65960.

Operational costs

• Privilege. Every agent runs as a privileged DaemonSet or root service on every node. Treat its image, chart and API like part of the control plane.
• Kernel coupling. Kernel upgrades can break drivers or hooks. Test agents on new node images before rollout.
• Event volume. Runtime events can be larger than your application logs. Plan storage and retention.
• Tuning time. Expect a few hours a week for the first two months, then less. This is the biggest hidden cost.
• Skills. Falco rules are learnable in a day. Tetragon policies need kernel knowledge. Tracee custom detections need Go.
• Upgrades. Falco shipped three minor releases in 2026, each with breaking changes listed first. Tetragon upgrade notes need reading too; 1.7.0 changed the default server address.

Decision guide

• Small team, mixed VMs and Kubernetes, want useful alerts this quarter: Falco with Falcosidekick.
• Already on Cilium, want enforcement on a few precise cases, have kernel skills: Tetragon, starting in detection mode.
• Need to investigate what happened on a node: Tracee as a short-term capture tool.
• Bank or auditor asking for evidence: any of these, plus documented rules, alert routing, runbooks and trigger tests. The evidence is the process, not the logo.

Checklist

• Kernel version and BTF checked on every node and VM.
• Agent API on a Unix socket, not a TCP port.
• Agent version current and advisories subscribed.
• Top five threats listed with owner and runbook.
• Alerts going to a place people actually watch.
• Noise per rule measured and tuned.
• Trigger tests run after every upgrade.
• Secrets in arguments and environment variables redacted.
• Enforcement policies tested in staging and easy to remove.

Common mistakes

• Muting the channel instead of tuning rules. Silence feels calm until the real alert is also silent.
• Enforcing on day one. A wrong Override can break payments at month-end.
• Upgrading Falco without reading breaking changes. 0.44.0 and 0.45.0 both changed things that old setups depend on.
• Leaving the agent API on TCP. CVE-2026-65960 showed what a same-node pod can do with it.
• Trusting a rule you never triggered. The 2026 libs path bypass was silent.
• Collecting everything. Wide hooks mean more overhead, more storage and more secrets in logs.

The drill we ran

These tools need root or strong capabilities to load eBPF programs, and our test machine is shared. So we did not install or run Falco, Tetragon or Tracee. We did a smaller, safe drill as an ordinary user, in a scratch folder, with no sudo, no package install and no system service.

1. Read-only pre-flight. The kernel reported 6.12, and /sys/kernel/btf/vmlinux was present, so BTF was available. /proc/sys/kernel/unprivileged_bpf_disabled was 2, meaning unprivileged BPF is off, which confirms that any of these agents would need root or capabilities here. The lockdown file did not exist on this kernel.
2. A Python virtual environment with PyYAML 6.0.3.
3. Three example files. A Falco list and rule for a shell in a billing namespace container, a Tetragon TracingPolicy that posts an event on access to /etc/shadow through security_file_permission, and a Tracee Policy watching dropped executables and files opened from /tmp.
4. Parse and structure check. All three files parsed, and a small script confirmed the expected top-level keys (rule fields for Falco, kind and kprobe actions for Tetragon, scope and rules for Tracee).
5. Two negative tests. A tab-indented file was rejected by the parser. A file with the key priority written twice was silently accepted, and the last value won. So a YAML parser alone will not catch a duplicated key that changes a rule’s meaning.

Not run: we did not run falco –validate, kubectl apply against the real CRDs, any agent, any trigger test or any overhead measurement. Parsing YAML proves syntax only. It does not prove a Falco field name, a kernel function name or a Tetragon operator is correct. For that, use each tool’s own validation in a throwaway VM.

Unlearn, re-learn

• Unlearn “runtime security means installing an agent”. Re-learn that it means an alert path, owners and runbooks, with an agent as one part.
• Unlearn “eBPF is always cheap”. Re-learn that overhead follows what you hook and how much you send to user space.
• Unlearn “blocking is better than alerting”. Re-learn that enforcement is for narrow, tested cases.
• Unlearn “Falco needs a kernel module”. Re-learn that the modern eBPF probe is the default and the legacy probe is gone.
• Unlearn “the security tool is safe by default”. Re-learn to patch it and lock its API like any privileged service.
• Unlearn “no alert means no attack”. Re-learn to trigger your important rules on purpose.

Sources

• Falco: Falco releases, Falco kernel event sources and drivers, Falco security advisories, libs advisory GHSA-jh29-p45v-8ghg, falcosecurity/libs releases, falco-rules releases, CNCF Falco project page
• Falco companions: Falcosidekick, falcoctl releases, Falco Talon, Falco Helm charts
• Tetragon: Tetragon releases, Tetragon overview, Tetragon enforcement, Tetragon FAQ and kernel requirements, BPF program statistics, Tetragon security advisories, CVE-2026-65960 advisory, InfoQ on Tetragon 1.0 and the vendor overhead figures
• Tracee: Tracee releases, Tracee repository, Tracee prerequisites, Tracee policies, Tracee custom events
• Related posts on Revisit.Tech: Kubernetes admission policy in 2026, vulnerability scanners in 2026, container sandboxing in 2026, Kubernetes pod networking in 2026, Fluent Bit, Vector and the OpenTelemetry Collector