What we still need to verify : 1 point in this profile is not yet confirmed against vendor documentation.
- Catalog category is listed as iac-security; Falco is a runtime detection tool and may belong under container-security
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Falco consumes the Linux system call stream and evaluates it against rules in near real time. It collects events through an eBPF probe, with a kernel module driver as the older alternative, so it observes process execution, file access, network connections and privilege changes at the kernel boundary rather than inferring them from logs. Events are enriched with container and Kubernetes context, which turns "a shell was spawned" into "a shell was spawned in this pod, from this image".
Rules are YAML. Each rule names a condition expressed in a filter syntax over event fields, an output template, a priority and tags, and rules compose through reusable macros and lists. The default ruleset covers the familiar container attack signals: a shell opened inside a container, writes below system binary directories, reads of sensitive files, outbound connections from unexpected processes, and attempts to modify the container runtime socket. Falcosidekick is the usual fan-out layer to chat, SIEM and cloud event buses.
Where it fits
Falco is a production runtime control, deployed as a DaemonSet across a Kubernetes cluster or as a host agent. Security operations owns it, because the output is detection signal that someone has to triage, not a build gate a developer can fix in a pull request. Two things must be true first: you need an on-call process for the alerts, and you need enough understanding of normal workload behavior to tune the rules.
Strengths
- Kernel-level visibility means it sees behavior regardless of language, runtime or whether the binary came from your build pipeline.
- Rule syntax is readable enough that an operator can write and review detections without learning a new language.
- Broad Kubernetes context enrichment makes alerts actionable rather than requiring a separate lookup to identify the workload.
- CNCF governance and a large deployed base mean the default ruleset reflects real-world attack patterns, not vendor theory.
Limitations
- Detection only. Falco alerts, it does not block, so pairing it with an enforcement layer is usually necessary.
- Tuning burden is substantial. Legitimate workloads that exec into containers, run package managers or write to unusual paths will trip the defaults.
- Syscall volume has real overhead on busy nodes, and the eBPF probe imposes kernel version requirements that can complicate older or managed environments.
Who it suits
Right for teams running containerized workloads at a scale where runtime compromise is a credible concern and there is a security operations function to receive alerts. Wrong for a team with no alert triage capacity, or one that primarily wants to prevent bad configuration from reaching a cluster, which is an admission control problem instead.
Used Falco? Recommend it under your own name and title.
Recommend this tool