Falco is a runtime security tool that detects threats while workloads are running. It observes Linux kernel events, mainly system calls, enriches them with container and Kubernetes metadata, and evaluates them against a set of rules; when a rule matches, it raises an alert. It addresses a gap left by image scanning and admission control, which check what is deployed but cannot see what a container actually does after it starts: a shell spawned inside a production pod, a sensitive file read, an unexpected outbound connection. Falco was created by Sysdig and open-sourced in 2016. It joined the CNCF as the foundation’s first runtime security project in 2018, moved to incubating in 2020 and graduated on 29 February 2024.
CNCF daily · Sprint 2, day 6 · Security & Compliance
At a glance
| Category | Provisioning › Security & Compliance |
| CNCF status | Graduated. Accepted October 10, 2018; incubating January 8, 2020; graduated February 29, 2024 |
| Written in | C++ for the engine and kernel libraries; Go for Falcosidekick, falcoctl and plugins |
| License | Apache 2.0 |
| Event sources | Linux system calls through a kernel driver; plugins for Kubernetes audit logs, AWS CloudTrail, GitHub, Okta and others |
| Drivers | Modern eBPF probe (default on recent kernels), legacy eBPF probe, kernel module |
| Release rate | About three releases a year, according to the project |
Architecture
flowchart TB
APP[Containers and processes] ==>|system calls| KERN[Linux kernel]
KERN ==>|events| DRV[Falco driver<br/>modern eBPF or kernel module]
DRV ==> LIBS[libscap and libsinsp<br/>capture and enrich]
K8S[Kubernetes API and<br/>container runtime] -.->|metadata| LIBS
PLG[Plugins<br/>K8s audit, CloudTrail] ==> ENG
LIBS ==> ENG[Rules engine<br/>conditions and macros]
RULES[Rules files<br/>YAML] ==> ENG
CTL[falcoctl<br/>rules and plugin updates] -.-> RULES
ENG ==>|alerts| OUT[Outputs<br/>stdout, file, HTTP, gRPC]
OUT ==> SK[Falcosidekick]
SK -.->|forward| DEST[Slack, SIEM, Loki,<br/>Elasticsearch, webhooks]
classDef actor fill:#eceff1,stroke:#455a64,stroke-width:1.5px,color:#1d1c1a
classDef core fill:#0f766e,stroke:#064e4a,stroke-width:2px,color:#ffffff
classDef ctrl fill:#ede7f6,stroke:#5e35b1,stroke-width:1.5px,color:#1d1c1a
classDef data fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#1d1c1a
classDef sec fill:#fce4ec,stroke:#ad1457,stroke-width:1.5px,color:#1d1c1a
classDef obs fill:#e8f5e9,stroke:#2e7d32,stroke-width:1.5px,color:#1d1c1a
class APP data
class KERN,K8S ctrl
class DRV,LIBS,ENG,PLG,CTL,SK core
class RULES sec
class OUT,DEST obs
Key: teal blocks are the project itself, blue are workloads, purple are control and platform components, red are security policy, green are observability and alert destinations. Thick arrows show the primary path, dashed arrows metadata, updates and forwarding.
| Component | Responsibility |
|---|---|
| Driver | Captures system call events in the kernel. The modern eBPF probe is built into Falco and needs no kernel headers on recent kernels; a legacy eBPF probe and a kernel module cover older systems. |
| libscap and libsinsp | The falcosecurity/libs libraries: libscap reads events from the driver, and libsinsp parses them, tracks process and file state, and adds container and Kubernetes metadata. |
| Rules engine | Evaluates each event against rule conditions written in a filter language over fields such as proc.name, fd.name, container.image.repository and k8s.pod.name. |
| Plugins | Add event sources beyond system calls, such as Kubernetes audit logs and cloud audit trails, and extra fields for rules. |
| falcoctl | Installs and updates rules files and plugins, distributed as OCI artifacts. |
| Falcosidekick | A companion service that receives Falco alerts and forwards them to dozens of destinations, with an optional web UI. |
Design principle. Falco treats the kernel as the single source of truth: every process start, file open and network connection passes through system calls, so observing them gives a complete, tamper-resistant view of what a workload does, regardless of the language or image it uses. Detection logic lives in readable YAML rules, separate from the engine, so teams can tune it without changing code.
Production reference design
A common setup runs Falco as a DaemonSet on every node of an EKS, GKE, AKS or on-premises cluster, with alerts sent to chat and a central log store.
- Check the kernel. The modern eBPF driver needs a recent kernel with BTF support (generally 5.8 or later). Managed node images from the major clouds meet this.
- Install a pinned chart version with Helm:
helm repo add falcosecurity https://falcosecurity.github.io/charts && helm repo update helm install falco falcosecurity/falco -n falco --create-namespace \ --set driver.kind=modern_ebpf \ --set falcosidekick.enabled=true \ --set falcosidekick.webui.enabled=true kubectl -n falco rollout status ds/falco - Start with the default rules, which detect common threats such as shells in containers, writes below binary directories and reads of sensitive files, and watch the alert volume for a week before tuning.
- Add rules for your own environment. For example, alert on interactive shells in a namespace that should never have them:
- rule: Shell in production container desc: An interactive shell was started inside a container in the prod namespace condition: > spawned_process and container and proc.name in (bash, sh, zsh) and k8s.ns.name = "prod" output: > Shell in prod container (user=%user.name cmd=%proc.cmdline pod=%k8s.pod.name image=%container.image.repository) priority: WARNING tags: [container, shell, prod] - Route alerts. Configure Falcosidekick outputs, for example critical alerts to Slack or PagerDuty and everything to Loki or Elasticsearch for investigation.
Typical uses include detecting intrusions and cryptominers in running containers, meeting runtime-monitoring requirements in standards such as PCI DSS, auditing Kubernetes API activity through the audit-log plugin, and watching cloud accounts through CloudTrail.
Operational considerations
- Alert fatigue. The default rules are broad. Expect noise at first, and tune it with exceptions and macros rather than disabling whole rules, so real detections are not lost.
- Overhead. Falco processes every system call on the node. Overhead is usually modest, but very syscall-heavy workloads can raise CPU use and cause dropped events; monitor Falco’s own metrics and set resource requests accordingly.
- Driver compatibility. Kernel upgrades can affect the kernel module or legacy probe. Prefer the modern eBPF driver, and include Falco in node image testing.
- Detection, not prevention. Falco alerts but does not block by itself. Pair it with an admission controller such as Kyverno for prevention, and with an automated response tool if you want to react, for example by isolating a pod.
- Protect Falco itself. It runs privileged on every node. Restrict who can change its rules and configuration, and alert if the DaemonSet stops or is modified.
Adoption
- The CNCF graduation announcement of February 2024 reported more than 30 public, self-declared adopters, naming Cisco, Shopify, Skyscanner, Vinted, Booz Allen Hamilton and GitLab.
- Engineers from Vinted, Qonto, IBM and Secureworks were quoted in the same announcement on their use of Falco, and maintainers come from companies including Amazon, Apple, IBM and Red Hat.
- Sysdig, which created Falco, builds its commercial runtime security product on the same open-source engine.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| Tetragon (part of the Cilium project) | eBPF-based observability with in-kernel enforcement | Teams that want to detect and block at the kernel level, especially on Cilium clusters |
| Tracee (Aqua Security) | eBPF-based runtime security and forensics | Event tracing and forensics with Aqua’s tooling |
| KubeArmor (CNCF Sandbox) | Policy enforcement with LSMs such as AppArmor and BPF-LSM | Restricting process, file and network behaviour per workload |
| Commercial CNAPP platforms | Managed runtime protection with dashboards and response | Organisations that want vendor support and a single console |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| Deep visibility into every process, file and network action via system calls | Detects and alerts; it does not prevent attacks on its own |
| Readable YAML rules and a large default ruleset | Default rules need tuning to avoid alert fatigue |
| Kubernetes and container metadata in every alert | Privileged DaemonSet on every node, with some CPU overhead |
| Plugins extend detection to audit logs and cloud trails | Kernel and driver compatibility must be managed |
| Graduated project with a third-party audit and broad adoption | Long-term storage, correlation and response need other tools |
Recommendation
Adopt. Falco is the standard open-source choice for runtime threat detection in Kubernetes and fills a gap that image scanning and admission policy cannot. Deploy it with the modern eBPF driver and Falcosidekick, start with the default rules in alert-only mode, and spend the first weeks tuning before wiring alerts to on-call. Use it alongside a prevention layer such as Kyverno.
References: CNCF project page · Falco documentation · Falco repository · CNCF graduation announcement · Falco Helm charts · CNCF Landscape