Falco: kernel-level runtime security for Linux and Kubernetes

What Falco detects, and who is expected to run it

Falco is described in the README as "a cloud native runtime security tool for Linux operating systems", designed to "detect and alert on abnormal behavior and potential security threats in real-time". The unit of observation is the event: syscalls primarily, enriched with metadata pulled from the container runtime and from Kubernetes. That enrichment is the part that makes the output usable. A raw syscall tells you a process opened a file; the container and pod metadata tells you which workload did it, which is the difference between an unactionable line and a ticket.

The audience is platform and security engineers running Linux hosts and Kubernetes clusters. The README points newcomers at a Getting Started guide and production users at a Setup guide, and it lists concrete pre-deployment items: verify environment compatibility, define detection goals, optimize performance, choose the appropriate build, and plan for SIEM or data lake integration. That last item is the honest one. Falco produces events; it does not ship with an incident response process. The README also names a demo environment: a docker-compose file that starts falco alongside falcosidekick, falcosidekick-ui and the redis database those two need, which is the fastest way to see what the event stream looks like before wiring anything into production.

Falco was originally created by Sysdig and is a graduated project under the CNCF. The README points to an ADOPTERS.md file for organizations using it in production, and the codebase is split across several repositories under the falcosecurity organization rather than living entirely in one tree.

The split repository model: what lives where

The main repository holds the source for the Falco binary itself. The README is explicit that most of the binary's source code actually lives elsewhere: falcosecurity/libs hosts the core libraries and the kernel drivers, and the README calls that out as "the majority of the binary's source code". This matters when you go looking for a bug. A detection that misfires because of how an event was parsed is a libs problem, not a falco problem, and the issue tracker you want is a different one.

The other core repositories are falcosecurity/rules for the official ruleset, falcosecurity/plugins for integrations that extend Falco beyond syscalls and container events, falcosecurity/falcoctl for the command-line utility that manages and interacts with Falco, and falcosecurity/charts for the Helm charts, with the chart source in chart/falco. Governance and the definition of what counts as a core repository live in falcosecurity/evolution.

The trade-off is real. Modularity means each component can move at its own pace, but it also means a version of the falco binary is only meaningful in combination with a version of libs and a version of the ruleset. The README does not document a compatibility matrix between these, so pinning versions in a deployment is on you. The repository layout does show the pieces that ship with the binary: a config/ directory, a falco.yaml at the top level, a rules directory, and a chart/ directory for the Helm chart.

Installing Falco and getting a first event out of it

The README does not contain install commands. It directs readers to the Getting Started guide at falco.org/docs/getting-started/ for a first run and to falco.org/docs/setup/ for production, and it says that building from source is documented at falco.org/docs/developer-guide/source/. That is the canonical path, and it is where the actual package and container instructions live.

What the repository does give you is the demo environment. The README states that a docker-compose file is provided that can be started on a docker host and includes falco, falcosidekick, falcosidekick-ui and the redis database they require, with more detail in the docker/docker-compose section. That is the shortest route from nothing to a visible alert, because falcosidekick is the component that forwards events and falcosidekick-ui is the component that displays them.

cd docker/docker-compose
docker compose up

The thing to watch for is the driver. Falco's event source is kernel-level, and the README's description of libs as providing "essential features, such as kernel drivers" is the only hint in this material about how that is loaded. The README does not document which driver is selected by default, what kernel versions are supported, or how to fall back if loading fails. Those are questions for the Setup documentation, and they are the first thing to resolve on a new host.

For a Kubernetes deployment the entry point is the chart in chart/falco, published from falcosecurity/charts. The README does not give Helm values or a values file example, so treat the chart's own documentation as the source rather than guessing at keys.

Falco observes and alerts; it does not block

The clearest limitation is in the README's own wording: Falco is "designed to detect and alert". Nothing in this material describes prevention, blocking, or killing a process. If your threat model requires stopping an action at the moment it happens, a detection-and-alert agent is the wrong primary control, however good its rules are. You would be building the response yourself on top of the event stream.

The second constraint is the dependency on kernel-level instrumentation. The README describes Falco as "a kernel monitoring and detection agent", and libs as providing the kernel drivers. That places Falco firmly on Linux, as the first sentence of the README says. It also means the deployment's viability is tied to the host kernel and to whether you can load the driver at all. On managed Kubernetes where you do not control the node image, or on hosts where you cannot load kernel modules, this is the first thing to check, and the README does not answer it.

The third is operational rather than technical. Falco generates events continuously. The README's own pre-deployment checklist includes optimizing performance and planning SIEM or data lake integration, which is a polite way of saying that an unintegrated Falco is a noisy process writing to a local file. The ruleset is also a dependency: the official rules in falcosecurity/rules define what fires, and a rule set that is too broad produces alert fatigue while one that is too narrow produces silence. The README does not discuss tuning rules, so that work is entirely yours.

Falco compared with Tetragon and with syscall tracing tools

The comparison that comes up most is Falco against Tetragon. The distinction that matters here is architectural and it follows from what the README says about Falco: Falco is a rule engine over an event stream, where the rules are declarative and the output is an alert. The rules live in a separate repository and can be updated independently of the binary, which is why falcoctl exists as a utility for managing and interacting with Falco. The model is detection, expressed as rules, with the response left to whatever consumes the events.

An eBPF-based enforcement tool in the same space takes the opposite position: the policy is attached to the kernel hook and the action happens there. If you want to terminate a process or deny an operation, that is the shape of tool you want, and Falco's alerting model is not a substitute for it. If you want a broad, readable, community-maintained rule set that describes suspicious behavior and feeds a SIEM, Falco's separation of rules from enforcement is an advantage, because you can change detection logic without redeploying an enforcement agent.

Against plain syscall tracing on the host, the difference is the metadata enrichment. A tracer gives you the syscall. Falco's stated design adds container runtime and Kubernetes metadata to the event, which is what makes the output attributable to a workload. That is the feature worth paying the deployment complexity for.

Licence, build requirements and the cost of keeping up

Falco is Apache-2.0. The repository carries both a COPYING and a LICENSE file at the top level, and the Makefile's header reproduces the standard Apache 2.0 grant and warranty disclaimer. For most users this is a permissive licence with no copyleft obligation on your own code, but the licence text governs, not this summary, and the repository is a multi-component project: the licence of falcosecurity/libs, falcosecurity/rules, falcosecurity/plugins, falcosecurity/falcoctl and falcosecurity/charts is not stated in this material, so check each repository you actually depend on rather than assuming the main repository's licence covers the whole deployment.

The maintenance picture is straightforward. The repository is not archived, and the most recent push recorded is 2026-09-21, the same day as the 0.45.0 release, following 0.45.0-rc4 on 2026-09-18 and 0.45.0-rc3 on 2026-09-15. A release candidate sequence that tight before a final release is a normal pattern, and it means upgrades arrive on a regular cadence rather than as rare events.

That cadence is the upgrade cost. Because the binary depends on libs for its kernel drivers and on the rules repository for its detections, a Falco upgrade is not a single artifact swap. The CHANGELOG.md is the README's pointer for what changed. On the build side, the Makefile pins tooling versions explicitly, including CLANG_FORMAT_DESIRED_VERSION set to 18.1.8 and CMAKE_FORMAT_DESIRED_VERSION set to 0.6.13, and the clang-format-install target exits with an error if the installed version does not match. That is a contributor concern rather than an operator one, but it tells you the project holds its toolchain to exact versions, which is a reasonable signal about how the rest of the build is treated.

Editorial conclusion

Adopt Falco if you run Linux workloads and want a rule-based detection layer that can attach container and Kubernetes metadata to kernel events, and if you have somewhere to send the alerts. Do not adopt it as your only control: it observes and reports, it does not block, and the default driver choice (kernel module or eBPF probe) depends on your kernel and your ability to load code into it. Before rollout, verify the driver path works on your kernel version, decide whether you want the official ruleset or your own, and confirm where events land, because a Falco deployment with no output consumer is just a log file.

Frequently asked questions

Official sources

1. falcosecurity/falco on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases