🦅 Falco for Runtime Detection — Practical Guide, Legacy Notes, and 2026 Patterns

Intro: Falco remains one of the most important open-source runtime detection tools for cloud-native environments. The core idea from the Falco book still holds: detect suspicious behavior from runtime events, enrich them with container and Kubernetes context, and route the signal to people or systems that can act.

What this page covers

• what Falco is good at and what it is not good at;
• how older Falco examples map to the current project;
• practical installation, rule, output, and tuning examples;
• where Falco fits next to SIEM, CloudTrail, audit logs, and incident response.

What Falco is good at

Falco is strong when you need:

• near-real-time detection of unexpected runtime behavior;
• signals from syscalls, container context, Kubernetes metadata, and cloud plugins;
• low-latency rule evaluation close to the workload;
• event forwarding to alerting, observability, and response systems.

What Falco is not

Falco is not:

• a full vulnerability scanner;
• a replacement for cloud audit logs;
• a substitute for good RBAC and Pod hardening;
• magic without rule tuning and ownership.

Legacy versus current Falco reality

Recommended deployment choices

For Kubernetes

Use Helm unless you have a strong reason not to.

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

For host-based testing or lab work

Use packages or a local container, depending on how close you want the lab to production.

docker run --rm -it --privileged falcosecurity/falco:latest /usr/bin/falco --version

Old snippet versus current snippet

Older style from book-era examples

curl -L -O https://download.falco.org/packages/bin/x86_64/falco-0.32.0-x86_64.tar.gz
tar -xvf falco-0.32.0-x86_64.tar.gz
sudo cp -R falco-0.32.0-x86_64/* /
sudo falco-driver-loader
sudo falco

Current-friendly approach

• prefer package-manager or Helm installation;
• prefer modern eBPF where supported;
• use falcoctl-managed rule lifecycle where appropriate;
• keep custom rules isolated from upstream defaults.

Practical rule example

- rule: Terminal shell in container
  desc: Detect an interactive shell started in a container
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, ash) and
    not proc.pname in (pause)
  output: >
    Terminal shell in container
    (user=%user.name container=%container.name image=%container.image.repository
    pod=%k8s.pod.name namespace=%k8s.ns.name cmd=%proc.cmdline)
  priority: WARNING
  tags: [container, mitre_execution, tty]

Practical tuning notes

Reduce noise by carving out expected activity

Use lists and macros for:

• approved admin tools;
• expected package managers in build namespaces;
• known maintenance jobs;
• platform namespaces you do not want to alert on the same way as product namespaces.

Use severity intentionally

• NOTICE or INFO for learning mode or new rules;
• WARNING for suspicious but plausible admin actions;
• ERROR or CRITICAL for behavior that should never happen in production namespaces.

Keep outputs investigation-friendly

Include:

• process name and command line;
• container image and container name;
• pod name and namespace;
• user and parent process where available.

Practical snippet — custom rules mounted through Helm values

customRules:
  product-security-rules.yaml: |-
    - macro: product_namespaces
      condition: k8s.ns.name in (billing, identity, checkout)

    - rule: Write below /etc in product namespace
      desc: Detect writes below /etc for application containers
      condition: >
        product_namespaces and container and evt.type in (open, openat, openat2)
        and fd.name startswith /etc and evt.is_open_write=true
      output: >
        Unexpected write below /etc
        (namespace=%k8s.ns.name pod=%k8s.pod.name container=%container.name file=%fd.name proc=%proc.cmdline)
      priority: ERROR
      tags: [filesystem, container, config-drift]

Practical snippet — Falcosidekick event routing

falcosidekick:
  enabled: true
  config:
    webhook:
      address: http://event-router.security.svc.cluster.local/falco

This keeps Falco focused on detection while letting another service handle fan-out, chat, webhooks, case creation, or response hooks.

Practical CloudTrail plugin note

Falco is not only for syscalls. For AWS-oriented use cases, the CloudTrail plugin path is especially useful for:

• console login without MFA;
• unusual IAM actions;
• sensitive cloud control-plane changes;
• tying runtime and cloud-control events together.

Where Falco fits in the bigger stack

Practical response patterns

Falco should usually trigger one of these:

• enrich and route to SIEM;
• create an alert in chat/on-call tooling;
• snapshot runtime context for investigation;
• optionally trigger a narrow automated action for high-confidence rules.

Do not start by auto-killing everything. Build confidence first.

Common mistakes

• enabling many default rules without tuning ownership or namespace context;
• forgetting to ship events anywhere durable;
• expecting Falco to replace posture management or vulnerability management;
• writing highly specific rules that nobody maintains;
• treating all shell events as equally urgent.

Related pages

• Logging and Telemetry Strategy
• High-Signal Detection Patterns and SIEM Examples
• 🧭 Runtime Investigation Playbook for Kubernetes and Containers
• ☸️ Kubernetes Hardening

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.

v3.2 companion page

For a broader runtime strategy that places Falco next to other runtime and control-plane signals, see 🛎️ Runtime Detection Stack — Falco, Tetragon, and Cloud Signals.