Falco Explained: Runtime Security Rules for Linux and Kubernetes, Tuning with Exceptions, and Sysdig Secure

Falco is the open-source answer to a question every Kubernetes security interview reaches eventually: "the image was scanned and the admission policy passed, so how would you know if someone got a shell in the container anyway?" Falco watches what processes actually do at run time and tells you when it looks wrong.

What it is

Falco is a runtime threat detection tool for Linux, created by Sysdig in 2016 and a graduated Cloud Native Computing Foundation project since February 2024. It reads system call events from the kernel and, through plugins, other event sources such as Kubernetes audit logs and cloud logs, and evaluates them against rules written in YAML. It detects; it does not block.

Sysdig Secure is Sysdig's commercial cloud security platform. Its runtime detection policies are built on Falco rules, macros and lists. It adds managed policies, extra event sources such as cloud audit logs and identity providers, container response actions (stop, pause, notify) and investigation features.

How it works

Drivers. The modern eBPF probe is the default. It is embedded in Falco and needs a kernel with BTF and the BPF ring buffer, which usually means 5.8 or later. The kernel module is the alternative for older kernels and needs full privileges. Falco 0.44 (26 May 2026) removed the legacy eBPF probe, the gVisor engine and gRPC output. Falco fails to start if configuration for those features remains, so check before upgrading.

Rules have a condition written over event fields, an output message, a priority (EMERGENCY down to DEBUG), tags and optional exceptions. Reusable macros and lists keep conditions readable. Only the stable ruleset (falco_rules.yaml) ships by default; incubating and sandbox rules must be installed explicitly.

How to use it

Day one: deploy on a cluster

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install --replace falco --namespace falco --create-namespace \
    --set tty=true falcosecurity/falco

The chart deploys Falco as a DaemonSet with driver.kind=auto, which tries the modern eBPF probe and falls back to the kernel module. The Falco Operator is now the project's recommended Kubernetes deployment method, and Helm remains supported. To test the pipeline, start a shell in a test container: the stable rules alert on it.

Week one: route alerts and write your first rule

Turn on Falcosidekick (falcosidekick.enabled=true) to forward alerts to chat, a SIEM, a queue or object storage. Then write a rule for something specific to your environment. For example, alert when anything other than your deployment tooling writes below a web root inside a container:

- rule: Unexpected write below web root
  desc: A process other than the deploy agent wrote to the web root
  condition: >
    open_write and container and fd.name startswith /var/www/
    and not proc.name in (deploy-agent)
  output: >
    Write below web root (file=%fd.name proc=%proc.name
    container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [filesystem, container]

Every day: tune with exceptions, not deletions

• Use exceptions that name the expected actor, action and target. Falco's documentation recommends being specific, for example "this image's entrypoint may write this path", and avoiding exceptions based only on a process name, which attackers can copy.
• Override in a local file. Put changes in a rules file loaded after the defaults, using override: with append or replace for lists, macros and rules. The older append: true syntax is deprecated.
• Track rule health. Count alerts per rule per week. A rule nobody reads is either noise to tune or a gap in routing.

Where it stops

• Detection only. Falco alerts; blocking or killing needs another layer, such as Sysdig Secure's container actions, an admission controller or your automation.
• Linux only for the system call source.
• Privileged by design. The probe needs elevated privileges on every node, which makes the DaemonSet itself sensitive.
• Drivers follow versions. Falco 0.44 userspace does not work with 0.43 drivers, so plan upgrades together.
• Rules see events, not intent. Good rules need knowledge of what normal looks like in your workloads.

How it comes up in interviews

• "How would you detect a shell spawned inside a production container?" Explain system call monitoring, the rule, the metadata in the alert and the response path.
• "Falco is generating 5,000 alerts a day. What do you do?" Find the noisy rules, write specific exceptions, move low-value rules to lower priority, and measure.
• "Image scanning versus runtime detection: why both?" What is installed versus what actually runs.

Sources

Checked on 13 November 2026: CNCF announcement of Falco's graduation (29 February 2024); Falco documentation on kernel event sources, Kubernetes setup, rule basic elements, exceptions and overriding; Falco 0.44.0 release blog (26 May 2026); falcosecurity/rules and falcosecurity/charts repositories; Falcosidekick README; Sysdig documentation on threat detection policies and installing Shield on Kubernetes.