Runtime security is the last detection layer before an incident becomes a breach, and Falco is the open-source default for the Kubernetes-and-Linux workload. The 0.41 release in February 2026 promoted the modern eBPF driver to the only recommended option for new deployments and retired the legacy kernel module from the supported configuration matrix. That is a meaningful shift and a good moment to revisit what a competent Falco deployment looks like in 2026.
This is not an introduction. We assume you know what Falco is. The goal is to lay out the deployment decisions that platform teams get wrong on their first attempt, with enough specificity that you can avoid the more painful mistakes. We will be opinionated where the data justifies it.
Which driver should you actually run?
Run the modern eBPF driver. The legacy kernel module is now unsupported on Falco 0.41 and the classic eBPF driver is deprecated. The modern driver uses CO-RE-style BTF for kernel compatibility, which means a single driver binary works across the full range of supported kernels without per-host compilation. Operationally, this eliminates the historical pain of kernel-module mismatches after node upgrades and it removes the privileged-init container from the daemonset.
The exception is older kernels. Modern eBPF requires kernel 5.8 or newer for full feature coverage and some critical hook points are only stable from 5.10. If you are still running RHEL 8 or earlier on production nodes, you have a kernel-upgrade dependency before you can deploy Falco cleanly. Plan for that. Trying to make Falco work on a 4.18 kernel in 2026 is an exercise in unnecessary suffering.
How should rules be tuned for production?
The default Falco rules are calibrated for broad applicability, which means they are loud out of the box. The pattern that works is to deploy in audit-only mode for at least two weeks, capture every alert with its triggering process tree, and triage them into three buckets: real signal, environmental noise, and ambiguous. Real signal goes into your detection pipeline. Environmental noise gets suppressed at the rule level with macro overrides, not by deleting the rule. Ambiguous alerts get a rule modification that tightens the predicate to exclude the known-good case.
The mistake teams make is global suppression. Disabling a noisy rule across the cluster because it fires for one specific workload throws away signal from every other workload. Use Falco's exception mechanism, which lets you attach scoped exceptions to a rule based on container image, namespace, or process. That preserves coverage everywhere except the specific case you have decided is acceptable. Document each exception with the workload it covers and revisit them quarterly, because exceptions accumulate and the conditions that justified them often go stale.
Where should alerts go?
Falco emits alerts as structured JSON over its gRPC API or as syslog or HTTP output. The right destination depends on your detection stack. For SIEM-centric environments, push to Splunk, Sentinel, or your equivalent via the HTTP output and treat Falco like any other detection source. For SOAR-style automation, route through Falcosidekick to a workflow engine. For the small number of teams running Falco Talon, you get inline response capability that can kill a process or evict a pod based on rule output, with all the operational risk that implies.
Whatever the routing, instrument the pipeline end-to-end. Falco-generated alerts that never make it to a responder are worse than no Falco deployment at all, because they create the illusion of coverage. Run synthetic alert tests at least weekly and treat a missing alert as a Sev-2 incident. The most common cause of detection failure is not Falco itself; it is a broken Sidekick configuration or a SIEM that quietly dropped the message.
What about plugins and the new sources?
Falco 0.40 stabilized the plugin SDK and 0.41 shipped first-class plugins for Kubernetes audit events, AWS CloudTrail, GitHub audit logs, and Okta system logs. The audit-event plugin is particularly worth running because it gives you the same detection language for control-plane events as for runtime events, which simplifies the rule library and lets you write rules that correlate both. The CloudTrail plugin overlaps with native AWS detection but is useful if you want a single pane of glass.
The plugins that are not yet production-ready in 0.41 include several Git hosting integrations beyond GitHub and the experimental Linux kernel module unloading detection. Treat experimental plugins as exactly that and do not put them in the critical path of any compliance control.
What is the operational cost?
The honest answer is that a well-run Falco deployment costs about half an engineer's time on an ongoing basis. The work is rule maintenance, exception cleanup, alert triage support, and the periodic upgrades. The eBPF driver eliminated most of the historical infrastructure pain but it did not eliminate the detection-engineering pain, which is where the real work lives.
Teams that deploy Falco without budgeting that ongoing cost end up with stale rules, unmaintained exceptions, and a deployment that produces noise rather than signal within a year. The technology is solid and free; the headcount is not. Plan accordingly.
How Safeguard Helps
Safeguard complements Falco's runtime detection with build-time and admission-time controls that reduce the volume of incidents Falco needs to catch in the first place. Griffin AI tracks reachable CVEs in deployed images and correlates them with Falco runtime alerts, so when Falco fires on a suspicious process, you immediately see whether the workload was running a known-vulnerable component. Policy gates block deployment of images with critical reachable CVEs, shrinking the attack surface Falco has to monitor. Our zero-CVE base image program and SBOM-driven TPRM scoring give you upstream supply chain context for every Falco alert, so a runtime detection comes pre-correlated with the supply chain risk that may have enabled it.