Falco Runtime Security Setup: 13 Steps, 90 Min [2026]

A container running a web app spawns a shell at 3 a.m. Nobody logged in. No deploy went out. That single event, caught by a kernel-level watcher instead of a human scrolling logs, is the entire pitch behind Falco, the CNCF-graduated runtime security tool that has become the default answer to “how do we know what’s happening inside our containers right now.” This guide walks through installing Falco 0.45.0 on a live Kubernetes cluster, writing custom detection rules, wiring alerts into Slack through Falcosidekick, and automating a kill-pod response with Falco Talon, so a suspicious process gets stopped before it finishes doing damage.

Falco started life at Sysdig in 2016, was donated to the Cloud Native Computing Foundation in 2018, and reached CNCF graduated status in 2024, putting it in the same tier as Kubernetes itself and Prometheus. The project counts more than 9,200 GitHub stars and over 220 contributors, and its latest release, version 0.45.0 from September 21, 2026, added raw byte matching inside rule conditions along with new reload status and control endpoints. None of that matters if you can’t get it running in your own cluster in under two hours, so that’s what this tutorial sets out to do.

Image scanners and admission controllers answer the question “is this container allowed to start.” Falco answers a different, arguably harder question: “is this running container still behaving the way it’s supposed to.” That distinction has become more urgent as attackers shift toward living-off-the-land techniques inside containers that passed every pre-deployment check cleanly. A compromised npm package, a malicious base image layer, or a stolen cloud credential used from inside a legitimate pod all look fine at build time. They only reveal themselves once something inside the container starts acting differently, which is exactly the moment a kernel-level watcher like Falco is built to catch.

This tutorial assumes you already have a working Kubernetes cluster, whether that’s a managed service like EKS, GKE, or AKS, or a self-managed cluster running on bare metal or a homelab setup. Every command below works identically across all three major clouds, with the one exception being the Kubernetes audit log integration in Step 11, where each provider exposes the webhook configuration slightly differently.

Prerequisites: What You Need Before Starting

Falco talks directly to the Linux kernel, so the version list below matters more than it would for a typical application deployment. Mismatched kernel versions are the single most common reason a first install fails.

Component	Minimum Version	Notes
Kubernetes	1.26+	Tested through 1.33 on EKS, GKE, and AKS
Linux kernel	5.8+	Required for the modern eBPF driver (default since Falco 0.36)
Helm	3.12+	Used for every install and upgrade command in this guide
Falco	0.45.0	Released September 21, 2026
Falcosidekick	2.31.1	Routes alerts to Slack, PagerDuty, Elasticsearch, and 50+ other outputs
Falco Talon	0.4.2	No-code response engine for automated remediation
kubectl	1.26+	Matched to your cluster’s minor version
Container runtime	containerd, CRI-O, or Docker	Falco reads metadata from all three

You’ll also need cluster-admin access, since Falco’s DaemonSet requires privileged containers to read kernel-level syscalls, and a Slack workspace (or any webhook-compatible tool) if you want to follow the alerting steps. Budget 90 minutes for the full walkthrough, including the attack simulation in Step 6.

A quick note on cost before diving in: everything in this guide, including Falco itself, Falcosidekick, and Falco Talon, is free and open source under the Apache 2.0 license. There’s no tier to unlock and no usage cap. The only real cost is the small CPU and memory overhead the DaemonSet adds to each node, covered in detail in Step 10, plus engineering time spent tuning rules so alerts stay signal instead of noise.

What Falco Actually Watches For

Falco uses eBPF to hook into the kernel and monitor system calls, file access, and network activity without touching application code. It enriches each raw syscall with container and Kubernetes metadata, so an alert tells you not just “a process opened /etc/shadow” but which pod, namespace, and container image did it. Out of the box, the default rule set watches for a shell spawned inside a container, reads of sensitive files like /etc/shadow or /etc/passwd, unexpected outbound connections from processes that shouldn’t be making them, container privilege escalation attempts, cryptocurrency mining signatures, and unusual process execution patterns tied to known attack techniques.

That’s a meaningfully different job than what image scanners like Trivy do. Trivy catches known vulnerabilities before a container ever runs. Falco catches behavior while the container is running, which is the only way to spot a zero-day exploit or a compromised dependency that passed every scan cleanly. The two tools are complementary layers, not competitors, and most production setups run both alongside baseline Kubernetes hardening.

Choosing a Falco Driver: Kernel Module vs eBPF

Before installing, it helps to understand the three ways Falco can read syscalls off the kernel, since the choice affects both performance and compatibility. The kernel module offers the lowest overhead because it hooks syscalls directly with no intermediate BPF subsystem calls, but it has to be compiled or matched against your exact running kernel, which makes it a poor fit for clusters that mix node images or auto-update frequently. The legacy eBPF probe trades a little performance for much broader kernel compatibility. The modern eBPF driver, Falco’s default since version 0.36, follows the BPF CO-RE (Compile Once, Run Everywhere) model, with the probe code already compiled into the Falco binary, so it works across kernel versions 5.8 and above without a separate build step per node.

Driver	Relative Overhead	Kernel Requirement	Best For
Kernel module	Lowest	Exact match to running kernel	Stable, homogeneous node images
Legacy eBPF probe	Moderate	Broad, pre-5.8 kernels supported	Older or mixed kernel fleets
Modern eBPF (default)	Low to moderate (1-5% CPU)	5.8+, CO-RE compatible	Managed cloud clusters, auto-updating nodes

Unless you have a specific reason to pin to the kernel module, stick with the modern eBPF default. It’s what the official Helm chart installs out of the box, it’s what the rest of this guide assumes, and it’s the driver the Falco maintainers actively prioritize for new feature work.

RBAC and Permissions Falco Needs

Falco’s DaemonSet needs more access than a typical application workload, and it’s worth understanding why before a security reviewer asks. Reading kernel syscalls requires a privileged security context or, at minimum, the SYS_PTRACE and SYS_ADMIN capabilities depending on the driver in use. Enriching events with Kubernetes metadata, such as which pod and namespace a syscall came from, requires a ClusterRole with read access to pods, namespaces, replicasets, and services across the entire cluster, since an alert is far less useful without knowing where it happened.

The official Helm chart creates this ClusterRole and the matching ServiceAccount automatically, scoped tightly to read-only access on the resource types Falco actually needs for enrichment. It does not grant write access to anything in your cluster by default. If your organization runs a policy engine that blocks privileged pods outright, you’ll need an explicit exception for the falco namespace, since there’s currently no way to run kernel-level syscall monitoring without some form of elevated access to the host.

Step 1: Confirm Your Cluster Meets the Kernel Requirement

Before installing anything, check the kernel version on your worker nodes. The modern eBPF driver that Falco uses by default needs kernel 5.8 or newer and follows the BPF CO-RE (Compile Once, Run Everywhere) model, meaning the probe is already compiled into the Falco binary and doesn’t need to build against your exact kernel headers.

kubectl get nodes -o wide
kubectl debug node/<node-name> -it --image=busybox -- uname -r

If any node reports a kernel older than 5.8, you have two options: upgrade the node image, or fall back to the legacy eBPF probe, which has wider kernel compatibility but needs to be built or downloaded for your specific kernel version. Managed node pools on EKS, GKE, and AKS have shipped kernels well above 5.8 since 2023, so this step usually just confirms you’re fine and lets you move on.

Step 2: Add the Falco Helm Repository

Falco ships an official Helm chart maintained in the falcosecurity/charts repository. Add it and refresh your local cache before touching anything else.

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm search repo falcosecurity/falco

The search command confirms you’re pulling the current chart version rather than a stale cached one, which matters because the chart bundles matching versions of Falco, Falcosidekick, and Falco Talon together. Installing an old chart is a quiet way to end up running a Falco build from a year ago without realizing it.

Step 3: Install Falco as a DaemonSet

Falco needs to run on every node, since kernel-level monitoring is node-scoped, not pod-scoped. The Helm chart deploys it as a DaemonSet automatically.

helm install --replace falco falcosecurity/falco 
  --namespace falco --create-namespace 
  --set tty=true 
  --set driver.kind=modern_ebpf

The tty=true flag keeps Falco’s output attached to a terminal, which is useful while you’re watching alerts stream live during setup. You’ll typically drop it once Falcosidekick is handling output in Step 8. Give the pods a minute to pull images and initialize the eBPF probe, then confirm every node has a running Falco pod.

kubectl get pods -n falco -o wide
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=50

A healthy log stream shows the driver loading, the rule files being parsed, and a line confirming the engine started. If a pod is stuck in CrashLoopBackOff, jump ahead to the troubleshooting section before continuing.

Step 4: Understand the Default Rule Files

Falco loads rules from three locations in order: /etc/falco/falco_rules.yaml (the maintained default set, don’t edit this directly), /etc/falco/falco_rules.local.yaml (your overrides and exceptions), and everything under /etc/falco/rules.d/ (custom rule files, loaded alphabetically). Keeping your own rules out of the default file means upgrades won’t silently wipe your work.

Each rule has four parts: a condition written in a filter-expression language, an output template describing what the alert should say, a priority ranging from Emergency down to Debug (following syslog severity levels), and tags for grouping related rules. Reading through the default rules in Falco’s official rules documentation before writing your own saves time, since most of what you’d want to detect already has a close match you can clone and adjust.

Step 5: Write a Custom Detection Rule

The default rules cover common cases well, but every environment has its own normal. Say your platform team wants an alert any time a process writes to a file inside /etc in a production namespace, something the stock ruleset treats more loosely. Create a custom rules file:

# falco_custom_rules_cm.yaml
- rule: Write Below Etc in Production
  desc: Detect any file write under /etc in the production namespace
  condition: >
    open_write and fd.directory = /etc
    and k8s.ns.name = "production"
  output: >
    Unexpected write below /etc (user=%user.name command=%proc.cmdline
    file=%fd.name pod=%k8s.pod.name namespace=%k8s.ns.name)
  priority: WARNING
  tags: [filesystem, mitre_persistence]

Apply it by mounting the file as a ConfigMap and pointing the chart at it during an upgrade, which is the same mechanism you’ll use again in Step 8 when Falcosidekick comes in.

helm upgrade --namespace falco falco falcosecurity/falco 
  --set-file customRules."falco_custom_rules_cm.yaml"=falco_custom_rules_cm.yaml

Falco reloads rules without a pod restart in recent versions, so changes take effect within seconds. Check the logs to confirm the custom rule parsed without errors, since a YAML indentation mistake fails silently in older releases and loudly in 0.45.0 thanks to the improved reload status endpoint.

Step 6: Simulate an Attack to Test Detection

A rule you haven’t tested is a rule you don’t actually have. Spin up a throwaway pod and trigger the exact behavior your rule watches for, in a namespace you’ve labeled “production” for this test.

kubectl run attacker-test --image=busybox -n production -it --rm -- sh -c "echo test > /etc/malicious-test"

Within a second or two, the Falco pod on that node should emit a JSON event containing the rule name, priority, and the enriched metadata from your output template. If nothing appears, check that the namespace label matches exactly what your condition specifies, since this is the most common reason a freshly written rule stays silent during its first test.

Step 7: Install Falcosidekick to Route Alerts

Reading alerts out of kubectl logs works for a demo, not for production. Falcosidekick, now at version 2.31.1, forwards every Falco event to more than 50 destinations including Slack, PagerDuty, Elasticsearch, Splunk, and generic webhooks. Enable it during a Helm upgrade:

helm upgrade --namespace falco falco falcosecurity/falco 
  -f falco_custom_rules_cm.yaml 
  --set falcosidekick.enabled=true 
  --set falcosidekick.webui.enabled=true

The webui.enabled=true flag deploys Falcosidekick-UI, a small dashboard that stores recent events so you can search and filter them without a full SIEM in place yet. It’s a reasonable bridge for teams that haven’t committed to a platform like Wazuh but still want more than raw pod logs.

Step 8: Connect Falcosidekick to Slack

Create an incoming webhook in your Slack workspace, then pass the URL to Falcosidekick through its config. Store it as a Kubernetes secret rather than inline in a values file.

kubectl create secret generic falcosidekick-slack 
  --namespace falco 
  --from-literal=webhookurl="https://hooks.slack.com/services/XXX/YYY/ZZZ"

helm upgrade --namespace falco falco falcosecurity/falco 
  --set falcosidekick.enabled=true 
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/XXX/YYY/ZZZ" 
  --set falcosidekick.config.slack.minimumpriority="warning"

The minimumpriority setting is worth tuning immediately. Leave it at the default and you’ll get flooded with Informational and Notice-level events that bury the Warning and Critical alerts that actually need eyes on them. Starting at “warning” and loosening later, once you understand your environment’s noise floor, beats the opposite approach of starting loose and tuning down after a channel gets muted by a tired on-call engineer.

Step 9: Deploy Falco Talon for Automated Response

Alerting gets a human involved. Falco Talon, currently at version 0.4.2, is a no-code response engine that acts on Falco events directly, without waiting for someone to read a Slack message. Its available actions include killing the offending pod, labeling it for forensic isolation, applying a restrictive network policy, deleting the Kubernetes object outright, or invoking an AWS Lambda function for custom workflows.

helm upgrade --namespace falco falco falcosecurity/falco 
  --set falcoTalon.enabled=true

Define a response rule that matches a Falco rule name and specifies an action:

# talon_rules.yaml
rules:
  - name: isolate-cryptomining-pod
    match:
      rules:
        - "Detect crypto miners using the Stratum protocol"
    action:
      name: networkpolicy
      parameters:
        allow: []

Start with isolate or label actions rather than kill or delete. A false positive that kills a production pod is a self-inflicted outage, and you want a few weeks of confidence in a rule’s accuracy before letting it terminate anything automatically.

Step 10: Set Resource Limits on the DaemonSet

Falco with the modern eBPF driver typically adds 1 to 5 percent CPU overhead per node and under 1 percent memory overhead, based on community benchmarks against representative Kubernetes workloads, though I/O-heavy workloads that generate high syscall volume will push that higher than CPU-bound ones. Set explicit requests and limits so a noisy node doesn’t starve Falco itself, which would defeat the point of running it.

helm upgrade --namespace falco falco falcosecurity/falco 
  --set resources.requests.cpu=200m 
  --set resources.requests.memory=512Mi 
  --set resources.limits.cpu=1000m 
  --set resources.limits.memory=1024Mi

Watch actual usage for the first week with kubectl top pods -n falco and adjust. Nodes running syscall-heavy workloads like databases or log aggregators will sit closer to the limit than idle app tiers.

Step 11: Add the Kubernetes Audit Log Plugin

Syscall monitoring covers what happens inside a container, but it misses control-plane events like a ServiceAccount being granted cluster-admin or a Secret being read through the API server. Falco’s k8saudit plugin ingests the Kubernetes audit log stream so those events feed into the same rule engine and the same Slack channel.

helm upgrade --namespace falco falco falcosecurity/falco 
  --set driver.kind=modern_ebpf 
  --set collectors.kubernetes.enabled=true 
  --set plugins.k8saudit.enabled=true

Your API server needs an audit policy configured and webhook backend pointed at the plugin’s listener, which on managed clusters means working through your cloud provider’s specific audit logging integration rather than editing the API server flags directly. EKS, GKE, and AKS each expose this differently, so check your provider’s current docs for the webhook endpoint format before this step.

Falco on Managed Kubernetes: EKS, GKE, and AKS Differences

The Helm install in Step 3 works the same on any CNCF-conformant cluster, but a few provider-specific quirks are worth knowing ahead of time rather than discovering during a troubleshooting session. On Amazon EKS, you don’t get direct access to the control plane’s API server, so wiring up the k8saudit plugin in Step 11 means routing through CloudWatch Logs or a Lambda-based forwarder rather than editing API server audit flags, since AWS manages that component for you. Bottlerocket-based node groups also default to a locked-down, minimal OS, which can block the DaemonSet’s host mounts unless you adjust the node’s SELinux policy.

On Google GKE, Autopilot clusters restrict privileged pods and hostPath mounts by policy, which conflicts directly with what Falco’s DaemonSet needs. Standard GKE clusters don’t have this restriction, so teams running Autopilot for cost or operational reasons typically either carve out a Standard node pool just for security tooling or accept that Falco isn’t compatible with a pure Autopilot setup yet. Azure AKS is the most permissive of the three out of the box, closely mirroring a self-managed cluster, though its audit log forwarding goes through Azure Monitor rather than a raw webhook, which changes the exact configuration syntax in Step 11 without changing the underlying concept.

Step 12: Export Metrics to Prometheus

Falco exposes a metrics endpoint that tracks rule evaluation counts, dropped events, and driver health, separate from the security alerts themselves. Dropped events matter because they mean Falco couldn’t keep up with syscall volume and silently skipped some, which is the kind of gap you want surfaced on a dashboard rather than discovered during an incident review.

helm upgrade --namespace falco falco falcosecurity/falco 
  --set falco.metrics.enabled=true 
  --set falco.metrics.interval=15s

curl http://falco-metrics.falco.svc:9376/metrics | grep falco_

Add a scrape config pointing your Prometheus instance at the Falco service and build a panel tracking the dropped-events counter over time. A rising trend there is an early signal that you need to either prune noisy rules or bump resource limits before you start missing real detections.

Step 13: Tune the Rule Set to Cut False Positives

The final step is ongoing rather than one-and-done. Every environment has legitimate behavior that looks like an attack to a generic rule set, most commonly engineers using kubectl exec to debug a production pod, which trips the same “shell spawned in container” rule that would catch a real intrusion. Add scoped exceptions instead of disabling the rule entirely:

- list: known_debug_users
  items: ["oncall-engineer", "sre-bot"]

- rule: Terminal shell in container
  append: true
  exceptions:
    - name: approved_debug_sessions
      fields: [user.name]
      comps: [in]
      values:
        - [known_debug_users]

Review your alert volume weekly for the first month. A healthy tuned environment settles into a low, steady rate of alerts that are each worth a look, rather than either total silence (rules too narrow) or a flood that trains your team to ignore the channel (rules too broad).

Falco vs Tetragon vs Tracee: How the Alternatives Compare

Falco isn’t the only eBPF-based runtime security tool, and it’s worth knowing what you’d be trading if you picked a different one. Tetragon, from Isovalent (now part of Cisco), focuses on enforcement at the kernel level with lower latency, since it can block a syscall before it completes rather than only alerting after the fact. Tracee, from Aqua Security, leans toward forensics and behavioral signature detection. Falco’s advantage is ecosystem maturity: CNCF graduated status, the largest rule-sharing community, and native integrations like Falcosidekick and Falco Talon that the others are still building out.

Tool	Maintainer	CNCF Status	Primary Strength	Cost
Falco	Sysdig / CNCF community	Graduated (2024)	Rule ecosystem, alerting integrations	Free, open source
Tetragon	Isovalent / Cisco	Sandbox	Kernel-level enforcement, low latency	Free, open source
Tracee	Aqua Security	Sandbox	Forensics, behavioral signatures	Free, open source
Sysdig Secure	Sysdig (commercial)	Built on Falco	Managed Falco plus compliance reporting	Paid, custom pricing

If your organization already pays for Sysdig Secure, it ships Falco under the hood with a managed rule feed, so a lot of this tutorial’s manual tuning work is handled commercially instead. Teams running everything open source should expect to own rule maintenance themselves, which is the trade a lot of platform teams are fine making in exchange for zero licensing cost. There’s also nothing stopping a team from running more than one of these tools side by side. It’s increasingly common to see Falco handling broad detection and alerting while Tetragon enforces a narrow set of hard blocks on the highest-confidence rules, using each tool for the job it does best rather than picking a single winner.

5 Common Pitfalls When Deploying Falco

• Skipping the kernel version check. Installing on a node running an older kernel without 5.8+ support causes the modern eBPF probe to fail silently or fall back in a way that leaves gaps in coverage.
• Editing falco_rules.yaml directly. That file gets overwritten on every chart upgrade. Put custom rules in rules.d or falco_rules.local.yaml instead, every time.
• Leaving minimumpriority at the default. Teams that skip this in Falcosidekick configuration get buried in Informational noise within days and mute the channel, defeating the entire point of alerting.
• Enabling Falco Talon’s kill action on day one. Automated pod termination on unvalidated rules has caused more self-inflicted outages in early deployments than it has stopped real attacks. Isolate first, kill later.
• Forgetting resource limits on the DaemonSet. An unbounded Falco pod competing with application workloads for CPU on a busy node can itself become the noisy neighbor you were trying to detect.

Troubleshooting Falco: 8 Issues and Fixes

• Pod stuck in CrashLoopBackOff. Check kubectl logs -n falco <pod> --previous for a driver load failure, usually tied to a kernel version mismatch or a missing privileged security context.
• No events appearing despite a triggered condition. Confirm the rule actually loaded with no YAML syntax errors by checking the reload status endpoint added in 0.45.0, rather than assuming silence means success.
• Driver fails to load on a custom or hardened kernel image. Switch to the legacy eBPF probe or kernel module driver, both of which need to be matched to the exact kernel build in use.
• High dropped-event count in Prometheus metrics. Falco can’t keep up with syscall volume on that node. Raise CPU limits first, and if that doesn’t resolve it, prune overly broad rules that fire on common syscalls.
• Falcosidekick shows connected but Slack never receives anything. Double check the minimumpriority filter isn’t set above the priority level your test alert is generating.
• Custom rules silently ignored after a Helm upgrade. The --set-file or -f flag path may not match what the previous release used. Helm doesn’t merge values across releases automatically unless you pass them again.
• Audit log events never reach Falco via the k8saudit plugin. The API server’s webhook backend configuration is almost always the culprit. Verify the audit policy file and webhook URL independently of Falco itself first.
• Talon action never fires despite a matching alert. Confirm the rule name in the Talon config is an exact string match to the Falco rule name, since a typo here fails without an obvious error message.

Advanced Tips for Running Falco at Scale

Once the base setup is stable, a few practices separate a tool that runs from one that actually earns its keep. First, version-control every custom rule file and review changes the same way you’d review application code, since a bad rule can either blind you to a real attack or flood on-call with noise. Second, pair Falco’s runtime detections with CI/CD supply chain scanning so you’re catching threats at build time and at runtime instead of only one or the other. Third, run a quarterly tabletop exercise where someone on the team deliberately triggers a Falco rule without telling the rest of the group, the same way the simulated attack in Step 6 worked, just unscheduled, to confirm the whole alert-to-response chain still works end to end.

Fourth, if your cluster spans multiple cloud providers or a hybrid on-prem setup, centralize Falco output through Falcosidekick into a single SIEM rather than per-cluster Slack channels, so correlation across clusters is possible. And fifth, revisit Sigma rules you may already maintain for other log sources. Several community projects now translate Sigma detections into Falco rule syntax, letting you reuse detection logic instead of writing it twice for two different engines.

Complete Working Project: End-to-End Threat Response

Putting every step together gives you a working pipeline: Falco’s DaemonSet watches syscalls across all nodes with the modern eBPF driver, a custom rule flags unexpected writes under /etc in production namespaces, Falcosidekick routes anything Warning or above into a dedicated Slack channel, and Falco Talon automatically applies a restrictive network policy to any pod matching the cryptomining detection rule while leaving the kill action off until the team has a few weeks of confidence in its accuracy. Metrics flow into Prometheus so dropped events and resource usage are visible before they become an incident, and the k8saudit plugin adds control-plane visibility on top of the container-level view.

That’s a genuinely production-shaped setup, not a demo. Expect the first month to be mostly rule tuning, since every cluster’s legitimate traffic patterns look slightly different, and the gap between a noisy deployment and a trusted one is almost always time spent in Step 13, not anything more exotic.

A realistic rollout timeline looks like this: week one covers the install, the kernel check, and the first custom rule, matching Steps 1 through 6 above. Week two adds Falcosidekick and Slack routing while the team gets used to reading real alerts instead of test ones. Weeks three and four are where Falco Talon goes in with isolate-only actions, metrics land in Prometheus, and the bulk of rule tuning happens as false positives surface from real traffic patterns the lab environment never produced. Only after that month of quiet observation should a team consider promoting any response action from isolate to kill, and even then, starting with a narrow blast radius, like a single low-traffic namespace, limits the damage if a rule turns out to be broader than intended.

How Falco Fits Into a Bigger Detection Stack

Falco is one layer, not the whole stack, and it’s worth being explicit about where the boundaries sit so nobody assumes it covers more than it does. When a Falco alert fires on something serious, like a reverse shell or unexpected privilege escalation, the next move for most security teams is deeper host and container forensics, which is exactly where a tool like Velociraptor picks up the investigation, pulling process trees, file timestamps, and network connection history that Falco’s alert alone doesn’t capture. The alert tells you something happened and roughly what. The forensics tool tells you the full story of how it happened and what else the attacker touched.

On the process side, a Falco deployment is only as good as the incident response plan sitting behind it. An alert with nowhere defined to go, no owner, and no documented next step is barely better than no alert at all, which is why pairing this setup with a written, rehearsed incident response plan matters as much as any YAML rule. Teams that skip that step tend to discover the gap during their first real incident, which is the worst possible time to figure out who’s supposed to isolate the pod and who’s supposed to notify leadership. For a broader view of where runtime detection sits alongside the rest of the threat landscape, our cybersecurity threats hub tracks the vulnerabilities and incidents this kind of tooling is built to catch.

Output Example: What a Real Falco Alert Looks Like

Here’s a representative JSON event, the kind that lands in Falcosidekick and eventually your Slack channel, for the custom rule written in Step 5:

{
  "output": "Unexpected write below /etc (user=root command=sh -c echo test > /etc/malicious-test file=/etc/malicious-test pod=attacker-test namespace=production)",
  "priority": "Warning",
  "rule": "Write Below Etc in Production",
  "time": "2026-10-04T14:22:09.418273516Z",
  "output_fields": {
    "k8s.ns.name": "production",
    "k8s.pod.name": "attacker-test",
    "proc.cmdline": "sh -c echo test > /etc/malicious-test",
    "user.name": "root"
  }
}

Every field in that payload is available to format your Slack message or route conditionally in Falcosidekick, which is why the enrichment step matters as much as the detection itself. A raw syscall without the pod name and namespace attached would tell you almost nothing actionable.

Frequently Asked Questions

Is Falco free to use in production?
Yes. Falco is Apache 2.0 licensed and free for any use, including production. Sysdig Secure is a separate paid product built on top of Falco with managed rules and compliance reporting, but the open source project itself carries no license cost.

Does Falco slow down my applications?
Community benchmarks put the modern eBPF driver’s overhead at roughly 1 to 5 percent CPU per node and under 1 percent memory, with the actual number depending heavily on how many syscalls your workloads generate. I/O-heavy applications see more overhead than CPU-bound ones.

What’s the difference between Falco and Trivy?
Trivy scans container images for known vulnerabilities before they run. Falco monitors running containers for suspicious behavior in real time. Most security-mature teams run both, since one catches known risks before deployment and the other catches unknown or zero-day behavior during execution.

Can Falco run outside Kubernetes?
Yes, Falco can run directly on a Linux host or inside Docker without Kubernetes, using the same eBPF driver and rule engine. The Kubernetes-specific pieces, like k8s.pod.name enrichment, simply won’t populate in a non-Kubernetes deployment.

How is Falco different from Tetragon?
Tetragon, built by Isovalent, is designed to enforce at the kernel level and can block a syscall before it completes, giving it lower response latency for blocking use cases. Falco is primarily a detection and alerting engine with a larger rule-sharing community and more mature third-party integrations through Falcosidekick and Falco Talon.

Should I enable the kill-pod response action right away?
No. Start with less destructive actions like labeling or network isolation, and only promote a rule to automated termination after it has run for several weeks without a false positive. A premature kill action on a noisy rule can cause more outages than it prevents.

What happened to the legacy eBPF probe and kernel module driver?
Both still exist and remain supported for kernels older than 5.8 or environments where the kernel module’s lower overhead matters more than portability. The modern eBPF driver became the default starting with Falco 0.36 because it doesn’t require per-kernel compilation, but it isn’t the only option.

Does Falco replace a SIEM?
No. Falco generates the detection events. A SIEM like Wazuh or a commercial platform aggregates, correlates, and retains them across your whole environment, not just Kubernetes. Falcosidekick-UI gives you a lightweight interim view, but it isn’t a SIEM replacement for teams with compliance retention requirements.

Related Coverage

• How to Set Up Velociraptor DFIR: 13 Steps, 90 Min [2026]
• GitGuardian ggshield Setup: Block AI Coding Leaks in 13 Steps [2026]
• Korea Orders Bank Security Checks After 4 Breaches [2026]
• Set Up Authentik SSO: 13 Steps, Free vs Keycloak [2026]
• Write Sigma Rules for Threat Detection: 13 Steps [2026]