Falco — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about Falco runtime security.
Falco was created by Sysdig, inspired by the Linux audit system's limitations¶
Loris Degioanni (creator of Wireshark) co-founded Sysdig and created Falco in 2016. The Linux audit system (auditd) could log system calls but couldn't alert in real-time or express complex detection rules. Falco was designed to bring real-time threat detection to containerized environments using the same syscall interception approach.
Falco was the first CNCF runtime security project¶
Falco was accepted as a CNCF Sandbox project in 2018, making it the first runtime security project in the CNCF. It graduated to Incubating status in 2020, signaling the CNCF's recognition that security tooling was essential to the cloud-native ecosystem, not just an afterthought.
Falco originally used a kernel module, then switched to eBPF¶
Falco initially used a custom kernel module to intercept system calls — which required loading kernel code on every node. This was a security and operational concern. The switch to eBPF (extended Berkeley Packet Filter) probes eliminated the need for kernel modules and made Falco safer to deploy, though the kernel module remains available.
Falco rules detect the unexpected, not the known-bad¶
Unlike signature-based security tools that detect known malware, Falco detects unexpected behavior: a shell being spawned inside a container, a process reading /etc/shadow, or a network connection from a container that normally doesn't make outbound calls. This behavioral approach catches zero-day attacks that signature-based tools miss.
The default Falco ruleset detects cryptomining in containers¶
Falco ships with default rules that detect cryptocurrency mining processes inside containers — one of the most common attacks on Kubernetes clusters. Attackers who gain access to a cluster frequently deploy mining containers. Falco detects the telltale signs: high CPU usage, connections to mining pool addresses, and specific process names.
Falco processes thousands of system calls per second per node¶
A single Linux server generates thousands of system calls per second during normal operation. Falco must evaluate each relevant syscall against its rule engine in microseconds to avoid adding noticeable overhead. The eBPF-based driver achieves this with less than 1% CPU overhead in typical deployments.
Falcosidekick routes alerts to over 60 different outputs¶
Falcosidekick, a companion project, can route Falco alerts to over 60 different destinations including Slack, PagerDuty, AWS Lambda, Kafka, Elasticsearch, and Loki. This integration breadth solved a major early complaint: Falco could detect threats but had limited options for alerting and response.
The Talon project enables automated response to Falco alerts¶
Falco Talon, introduced in 2023, enables automated responses to security events — like killing a compromised pod, labeling a node for investigation, or triggering a network policy change. This moved Falco from "detect and alert" to "detect and respond," though automated response in production requires careful tuning to avoid false-positive disruptions.
Wireshark's creator co-designed Falco's system call capture¶
Loris Degioanni co-created both Wireshark (the world's most popular network protocol analyzer) and Falco. His expertise in packet capture directly influenced Falco's architecture — the approach of capturing, filtering, and analyzing system calls mirrors how Wireshark captures, filters, and analyzes network packets.