Falco is an open-source runtime security tool used to detect suspicious behavior in Linux hosts, containers, Kubernetes clusters, and cloud-native workloads. It observes system activity and applies rules to identify behavior that may indicate compromise, misuse, or policy violation.
Falco is commonly associated with Kubernetes and container runtime security because it can detect activity that static scanners cannot see before deployment. It was created by Sysdig, donated to the Cloud Native Computing Foundation (CNCF), and has since graduated as a CNCF project, which is part of why it shows up as the default runtime detection engine in so many Kubernetes security stacks. You can read the project details on the official Falco site.
Why runtime security matters
Pre-deployment scanning is important, but it cannot tell what a workload actually does after it runs. Runtime security watches live behavior. It can detect unexpected shell activity, file changes, network connections, privilege changes, process execution, and sensitive path access.
That matters because attackers often abuse legitimate tools once they reach a workload. A container image may pass a scan, but a compromised workload can still spawn a shell, write to sensitive directories, or connect to unusual destinations.
How Falco works at a high level
Falco observes runtime activity and compares it to rules. A rule might alert when a shell runs inside a container, when a sensitive file is read, when a process writes below /etc, or when a container makes an unexpected network connection.
Modern deployments may collect signals using kernel instrumentation or other runtime data sources. The core idea is the same: observe behavior, match against rules, and alert when activity looks suspicious.
The data source: syscalls and kernel events
Falco’s signal comes from the kernel. Every meaningful thing a workload does — opening a file, spawning a process, making a network connection, changing a namespace — is a system call. Falco taps that stream and evaluates it in real time. Historically it did this with a kernel module; today many deployments use an eBPF probe instead, which runs sandboxed in the kernel and avoids loading a custom module. eBPF is usually the preferred option on managed Kubernetes because it is safer to operate and works on locked-down node images.
Because Falco sits at the syscall level, it sees behavior regardless of how the workload was built or what language it uses. An attacker who drops a static binary into a container still has to make syscalls to do anything useful, and those syscalls are visible to Falco.
Rules, conditions, and outputs
A Falco rule has three parts: a condition (the behavior to match, written against syscall fields and container/Kubernetes metadata), an output (the message and fields emitted when it fires), and a priority (severity). Falco ships a default ruleset covering common threats, and teams layer their own rules on top. Rules can reference lists (reusable sets of values, like “sensitive directories”) and macros (reusable condition fragments), which keeps a large ruleset maintainable.
Kubernetes context is a big part of what makes Falco rules useful. A rule can say “alert when a shell is spawned in a container, unless it is in the debug namespace,” because Falco enriches syscall events with pod, namespace, and image metadata. That lets you write intent-aware rules instead of blunt process-name matches.
Example detections
- A process spawns
/bin/bashinside a running container that should never have interactive shells. - A workload writes to a binary directory like
/usr/binafter startup, suggesting tampering. - A container reads
/etc/shadowor cloud credential files it has no business touching. - An outbound connection is made to an IP outside the expected set, hinting at C2 or exfiltration.
- A process attempts to modify a Kubernetes ConfigMap or Secret through an unexpected path.
Responding to alerts
Detection is only half the job. Falco emits structured events (JSON) that you route somewhere useful. Falcosidekick is the common fan-out component: it forwards Falco alerts to Slack, PagerDuty, SIEMs, object storage, and event buses. From there, teams can trigger automated responses — for example, killing a pod, quarantining a node, or opening an incident. Keep response conservative at first; auto-killing pods on a noisy rule causes outages, so start with alerting and graduate to automated action only for high-confidence rules.
What Falco is good for
Falco is useful for:
- Kubernetes runtime threat detection
- Container behavior monitoring
- Detecting suspicious process execution
- Identifying unexpected file or network activity
- Creating custom runtime rules
- Feeding alerts into broader detection workflows
Falco is strongest when paired with asset, identity, vulnerability, and cloud context.
Limitations to plan around
Falco is a detection tool, not a prevention tool by itself. It tells you something happened; it does not inherently stop it. It also has real operational costs worth planning for:
- Rule tuning is ongoing. Default rules are broad and will produce false positives in a busy cluster. Untuned Falco becomes alert noise that teams learn to ignore.
- Performance overhead. Watching every syscall has a cost. On high-throughput nodes you may need to scope rules and drop uninteresting event classes to keep overhead reasonable.
- Kernel and driver compatibility. The eBPF probe or kernel module must work on your node OS and kernel version, which matters on managed Kubernetes where node images change.
- No built-in prioritization. Falco does not know which workloads are internet-facing or hold sensitive data. A shell in a throwaway dev pod and a shell in a production payments service look similar to Falco. That prioritization has to come from surrounding context.
The last point is the most important one for teams drowning in alerts: runtime signals need business and cloud context to be actionable.
Falco and CNAPP
Falco can provide runtime signals, while a CNAPP connects those signals with posture, identity, workload, network, vulnerability, and compliance data.
For example, a Falco alert is more urgent if the workload is internet-facing, runs with high privilege, has access to cloud credentials, or can reach sensitive data.
How Cloudanix helps
Cloudanix brings runtime context into a broader cloud security graph. Teams can combine workload signals with CSPM, CIEM, CDR, Kubernetes security, attack path analysis, and vulnerability prioritization.
Concretely, when a Falco alert arrives, the questions that determine urgency are: Is this workload reachable from the internet? What identity and permissions does the pod’s service account or node role carry? Does it have a path to sensitive data or to other high-value assets? Are there known exploitable vulnerabilities on the image? Cloudanix answers those from the unified asset graph, so a runtime signal is scored against real blast radius rather than treated in isolation. That is the difference between “a shell ran somewhere” and “a shell ran in an internet-facing pod whose service account can read the production database.” For the mechanics of that reasoning, see attack path analysis.
Cloudanix also connects runtime detection to CDR workflows and to Kubernetes posture (KSPM), so misconfiguration, drift, and live behavior are triaged in one place instead of separate consoles. This is especially valuable for the regulated and AI-forward engineering teams that run large Kubernetes footprints and cannot afford to chase every runtime alert equally.
Related pages include Kubernetes runtime security, CDR, Container Security, and vulnerability prioritization.
Best practices for running Falco
- Start in alert-only mode. Learn what normal looks like in your clusters before wiring up automated response.
- Version-control your rules. Treat Falco rules like code: review changes, test them, and roll them out through your pipeline.
- Use namespaces and labels in conditions. Intent-aware rules produce far fewer false positives than name-based matching.
- Route alerts to a real workflow. Falcosidekick into a SIEM, ticketing, or CDR pipeline beats dashboards nobody watches.
- Prioritize with cloud context. Feed Falco output into a system that knows exposure, identity, and data reachability so responders act on the incidents that matter.
- Keep the default ruleset updated. The Falco community adds detections for new techniques; drifting far behind means missing known patterns.
Frequently asked questions
Is Falco only for Kubernetes?
No. Falco is often used with Kubernetes, but it can monitor Linux host and container runtime activity more broadly.
Does Falco replace image scanning?
No. Image scanning finds known issues before deployment. Falco detects suspicious behavior at runtime.
Why does Falco need cloud context?
Runtime alerts become more actionable when teams know asset criticality, exposure, identity permissions, owner, and data reachability.
Is Falco open source?
Yes. Falco is an open-source, CNCF-graduated runtime security project commonly used in cloud-native environments.
Does Falco prevent attacks or only detect them?
Falco is primarily a detection engine. It can trigger response actions through downstream tooling (for example, killing a pod via Falcosidekick integrations), but it does not block syscalls inline the way an enforcement agent would.
