Security has a before, a during, and an after. Runtime security is the “during”.

The three moments of protecting software

Every piece of software has a life with three stages. First it is built, when source code and dependencies are put together into a container image. Second it is deployed, when Kubernetes decides where and how that image will run. Third it is running, when the application is alive, handling real users and real data. Each stage has its own security tools, and a mature team uses all of them because each one catches problems the others cannot.

Build-time security looks for known weaknesses before anything ships, such as outdated libraries with published vulnerabilities. Deploy-time security checks the plan before it is carried out, for example refusing a workload that asks for dangerous permissions. Runtime security looks at what the workload actually does once it is alive. This last stage matters because the first two work with what is known and declared, while attackers specialize in what is unknown and undeclared.

Why scans and policies are not enough

A vulnerability scanner can only report weaknesses that someone has already discovered and published. A brand-new flaw, often called a zero-day, does not appear in any database on the day it is exploited. Admission policies can only judge what a workload asks for at the start. They cannot see what a program decides to do an hour later. A perfectly clean image can be tricked into downloading a malicious tool, a stolen password can let an intruder open a shell inside a healthy pod, and a compromised dependency can quietly start contacting a stranger’s server.

In all of these cases nothing was wrong at deployment time. The danger appears only through behavior: a process that should never start, a file that should never be read, a network connection that should never be opened. Runtime security exists to see that behavior and call attention to it quickly, ideally within seconds.

Why containers make runtime visibility harder

Traditional servers ran a handful of long-lived programs, and administrators knew them well. A Kubernetes node may host dozens of short-lived containers from many teams, started and stopped automatically at any hour. They all share the same operating system kernel on the node, which means one compromised container can sometimes reach for the kernel to affect its neighbors. Because containers are so numerous and so temporary, nobody can log into each one to look around. We need an automated observer that understands containers, pods, and namespaces, and that works at the one place all containers share: the kernel.

Falco is a free, open-source tool that listens to what your machines and containers do and shouts when behavior breaks the rules.

What Falco is, in plain words

Falco is a behavioral detection engine. It continuously collects events from the Linux kernel, compares each event against a list of rules that describe suspicious behavior, and sends out an alert whenever a rule matches. It does not scan files, it does not look for virus signatures, and it does not require changes to your applications. It simply observes what programs do and judges whether that behavior is normal.

The name comes from the falcon, a bird known for sharp eyesight and fast reactions, which is a fitting picture for a tool whose whole job is to notice problems quickly from above.

A short history

Falco was created in 2016 by the company Sysdig, which had already built deep expertise in capturing and understanding system activity inside containers. In 2018 the project was donated to the Cloud Native Computing Foundation, the same neutral home that hosts Kubernetes and Prometheus. It moved from the early sandbox stage to incubating in 2020, and in February 2024 it reached the highest maturity level, called graduated. Graduation is a strong signal that the project has a healthy community, contributors from many different companies, solid governance, and real production adoption.

The project also publishes a public roadmap toward a 1.0 release, with themes such as making the modern eBPF driver the default, offering a lighter image that ships without a bundled driver, clearer guidance for first-time users, and a more extensible plugin framework. Those themes tell us where the community sees the tool heading: easier to install, easier to operate, and easier to extend.

Four layers turn raw kernel activity into a meaningful security alert.

From a single action to a single alert

Whenever a program on a Linux machine wants to do something that touches the outside world, such as opening a file, starting another program, or connecting to a network address, it must ask the kernel for permission through a request called a system call. Falco sits quietly next to the kernel and receives a copy of those requests. It never blocks or slows the original request in a noticeable way. It only watches.

The journey from request to alert has four stages. A driver inside the kernel captures the event. A userspace library collects the events and enriches them with context, such as which container, pod, and namespace the program belongs to. A rules engine checks each enriched event against the loaded rules. Finally, output channels deliver any resulting alert to people and systems.

flowchart LR
  A["Application in a container"] --> B["System call to the kernel"]
  B --> C["Falco driver captures a copy"]
  C --> D["Userspace library adds container and Kubernetes context"]
  D --> E["Rules engine evaluates the event"]
  E -->|"Rule matches"| F["Alert produced"]
  E -->|"No match"| G["Event discarded"]
  F --> H["Output channels: logs, webhooks, Falcosidekick"]
        

The four layers explained

Why watching the kernel is such a strong idea

There are two common places to observe a running program. One is inside the application, using an agent or library that the application loads. The other is from the outside, at the operating system. The first approach needs changes in every application and can be tampered with by the very program being watched. The second approach needs no change to the applications, works for every language and framework, and is much harder for an attacker to switch off. Falco takes the second approach, and that single design choice explains most of its strengths.

To understand Falco, you only need to understand one idea: programs must ask the kernel for everything.

What is a system call?

A program running on Linux lives in a restricted area often called user space. It cannot directly touch the disk, the network card, or other programs. When it needs any of those, it politely asks the kernel, which lives in a privileged area. That polite request is a system call. Reading a file is a system call. Starting a new program is a system call. Opening a network connection is a system call. Changing a file’s permissions is a system call.

Why system calls reveal attacks

Almost every attack, no matter how clever, eventually has to do something observable through system calls. To steal a password file, the attacker must read it. To install a cryptocurrency miner, the attacker must write a new program to disk and start it. To phone home, the attacker must open a network connection. To dig deeper into the machine, the attacker must change permissions or load special kernel features. The attacker may hide their tools well, but they cannot avoid asking the kernel for help.

The blind spot Falco covers

Network firewalls watch traffic between machines, but they cannot see what happens inside a machine. Application logs show only what developers decided to record. System calls, by contrast, form a complete and honest diary of what every process actually did. This is why Falco is often described as giving you “ground truth” about your workloads.

The driver is the small piece that actually collects events. Choosing the right one matters.

What a driver does

The driver is a tiny program that runs inside the kernel, taps into system calls, and passes compact copies of each event up to Falco running in user space. It is designed to do as little work as possible, because anything that runs in the kernel must be extremely careful not to slow the machine down or cause instability.

The driver options

Falco has supported several kinds of drivers over the years. They all produce the same events, but they differ in how they are built, how portable they are, and how much trust they require.

What eBPF means, without the jargon

eBPF is a feature of the Linux kernel that lets small, carefully checked programs run safely inside the kernel. Before such a program is allowed to start, the kernel runs it through a strict inspector called the verifier. The verifier refuses programs that could crash the machine, loop forever, or read memory they should not touch. This gives eBPF a safety record that custom kernel modules cannot match, and it is the reason eBPF has become the foundation of modern observability and security tools.

A bare event is almost meaningless. Context is what makes an alert useful.

Two libraries do the heavy lifting

Falco is built on top of two shared libraries maintained by the same project. The first, often called libscap, is responsible for capturing events from the driver and also from saved capture files. The second, often called libsinsp, takes those events and builds a live picture of the machine: every running process, every open file, every network connection, and how they relate to each other. When the rules engine evaluates a condition such as “the parent of this process is a web server”, it is libsinsp that remembers who the parent is.

Why enrichment matters so much

Suppose an alert says only that process 48213 opened a sensitive file. That is nearly useless to an engineer on call. Now suppose the alert says that a shell started by the command line tool kubectl exec, inside the payments pod in the production namespace, running image version 2.4, as the root user, just read the password file. That alert tells a complete story in one sentence. The second alert is possible because Falco enriches events with container and Kubernetes details.

Where Kubernetes details come from

Falco learns container details by talking to the container runtime on the node, and it learns cluster details through a Kubernetes metadata component that collects information about pods and namespaces and hands it to the engine. This is how an event that began as a low-level kernel record ends up labeled with the human-friendly names your team already uses.

flowchart TD
  K["Kernel events"] --> S["Capture library"]
  S --> I["Inspection library: processes, files, connections"]
  R["Container runtime metadata"] --> I
  M["Kubernetes metadata: pods, namespaces, labels"] --> I
  I --> E["Rules engine"]
  E --> O["Enriched alert"]
        

Rules are the heart of Falco. They are simple to read, even for non-programmers.

What a rule is

A Falco rule is a short, human-readable description of behavior that deserves attention. Each rule has a name, a description, a condition, an output message, a priority, and optional tags. The condition is the interesting part. It is a sentence-like test over the fields of an event, for example “a new process was started, and it is a shell, and it is inside a container, and it is attached to an interactive terminal”. When the test is true, the rule fires.

Building blocks that keep rules tidy

Writing long conditions again and again would be tiring and error-prone, so the rule language offers reusable pieces. A list is a named collection of values, such as the names of all common shells. A macro is a named, reusable piece of condition, such as “this event happened inside a container”. Rules then combine lists and macros like building blocks, which makes them short, readable, and easy to maintain. When a macro is improved, every rule that uses it improves too.

Exceptions: telling Falco about legitimate behavior

Every real environment has legitimate tools that look suspicious in isolation. A backup agent may read many sensitive paths. A debugging container may start shells on purpose. Instead of deleting a useful rule, you add an exception that describes the specific, known-good situation, for example the name of the container image allowed to do this one thing. The rule keeps guarding everyone else while the trusted case stays quiet.

Where rules come from

Most teams start with the community-maintained default rules, which cover common threats across hosts, containers, and Kubernetes. The project sorts shared rules into maturity levels, so you can choose between only the most battle-tested rules or a wider set that includes newer ideas. On top of that, teams add their own custom rules for behavior specific to their own applications. Rule bundles can be installed and updated with the lifecycle helper, so improvements arrive without manual copying.

An alert is only useful if the right person sees it at the right urgency.

The priority ladder

Falco uses the classic syslog severity ladder. From most to least urgent the levels are emergency, alert, critical, error, warning, notice, informational, and debug. In practice most detection rules sit at notice, warning, error, or critical. Good teams decide in advance what each level means for their organization, such as “critical pages the on-call engineer immediately, warning goes to a chat channel, notice is kept for investigations”.

Where alerts can go

Falco can write alerts to standard output, which is the natural choice on Kubernetes because the cluster’s logging system already collects container output. It can also write to files, send to the system log, run a program, or send messages to a web address. In most clusters the simplest durable pattern is this: write alerts as structured JSON to standard output, let your existing log collector pick them up, and use Falcosidekick for fan-out to chat, paging, and storage destinations.

What makes an alert actionable

A strong alert answers five questions at a glance: what happened, where it happened, who or what did it, when it happened, and how serious it is. If an alert leaves out any of these, responders waste precious minutes hunting for details. When tuning your outputs, review a sample of real alerts and ask whether a tired engineer at three in the morning could decide what to do within one minute.

System calls show what happens on nodes. The Kubernetes audit log shows what happens to the cluster itself.

The second source of truth

Some dangerous actions never touch a node in an obvious way. Creating a powerful role binding, reading a secret through the API, or launching a privileged pod are all requests sent to the Kubernetes API server. Kubernetes can record such requests in an audit log. Falco can read that log through a plugin and apply rules to it, in the same way it applies rules to system calls.

flowchart LR
  U["User or service account"] --> A["Kubernetes API server"]
  A --> L["Audit log events"]
  L --> P["Falco audit plugin"]
  P --> E["Rules engine"]
  E --> X["Alert: risky cluster change"]
  N["Node system calls"] --> D["Falco driver"]
  D --> E
        

What audit rules can catch

Plugins: extending what Falco can read

The plugin framework lets Falco consume other event streams beyond the kernel, such as cloud provider activity logs and software supply chain events. Each plugin brings its own fields and matching rules, but the experience for the operator stays the same: one engine, one rule language, one alert pipeline. This is why many organizations describe Falco as a single place for threat detection across hosts, containers, clusters, and cloud accounts.

Falco must run on every node, because it watches the kernel of the node it lives on.

The daemon set pattern

Because each node has its own kernel, one Falco instance is needed per node. Kubernetes has a built-in workload type for exactly this need, called a DaemonSet, which automatically places one copy of a pod on every eligible node, and starts another copy whenever a new node joins the cluster. The official installation method uses a package manager for Kubernetes, known as Helm, which bundles Falco, its settings, its rules, and optional companions into a single, repeatable installation.

flowchart TD
  subgraph C["Kubernetes cluster"]
    subgraph N1["Node 1"]
      F1["Falco pod"]
      W1["Workload pods"]
    end
    subgraph N2["Node 2"]
      F2["Falco pod"]
      W2["Workload pods"]
    end
    subgraph N3["Node 3"]
      F3["Falco pod"]
      W3["Workload pods"]
    end
  end
  F1 --> S["Falcosidekick"]
  F2 --> S
  F3 --> S
  S --> D["Chat, paging, SIEM, storage"]
        

Permissions and trust

Because Falco loads an observer into the kernel, it needs elevated permissions on the node. Older drivers required fully privileged containers. The modern eBPF approach can run with a narrower set of specific capabilities, which follows the principle of least privilege more closely. Either way, Falco itself becomes a high-value target, so its namespace, service account, and configuration should be locked down and watched carefully.

A sensible rollout plan

Falco decides that something is wrong. Falcosidekick makes sure the right people and systems hear about it.

The problem it solves

Every team uses a different mix of tools: one chat app for conversation, another system for paging, a log platform for search, a security information system for compliance, and maybe an object store for long-term records. If Falco had to speak directly to every one of them, its core would grow enormous. Instead, Falco speaks one simple language, and a companion service called Falcosidekick translates and forwards alerts to a very large number of destinations, commonly described as more than fifty.

What it adds beyond simple forwarding

Design advice for alert routing

Spotting an intruder in seconds is wasted if the response takes hours.

Why automate any response at all?

Attackers move quickly. A cryptocurrency miner can be running within moments of entry, and a data thief can copy files in minutes. Waiting for a human to read an alert, log in, and act may take far longer than the attack. Automated response closes that gap for situations where the right action is clear and the cost of acting wrongly is low.

What Falco Talon does

Falco Talon is a response engine that listens to Falco’s alerts and runs predefined actions when specific rules fire. Typical actions include labeling a pod so it can be isolated by network policy, terminating the offending pod so the controller recreates a clean one, or collecting evidence from the workload before it disappears. Each action is tied to specific rules and conditions that you define in advance, so behavior stays predictable.

flowchart LR
  A["Falco alert"] --> B["Response engine"]
  B --> C{"Matching response policy?"}
  C -->|"Low risk, clear case"| D["Automatic action: label, isolate, or terminate pod"]
  C -->|"High impact or unclear"| E["Notify human for decision"]
  D --> F["Record what was done"]
  E --> F
        

Choosing the right level of automation

Understanding the attacker’s story makes the rules feel natural.

A typical intrusion, step by step

Most container attacks follow a recognizable path. The attacker finds a way in, usually through a vulnerable web application or a leaked credential. They get command execution inside a container. They look around, fetch tools, try to reach sensitive data or credentials, attempt to escape or move sideways, and finally pursue their goal, such as stealing data or mining cryptocurrency. Falco can raise an alert at many of these steps, which is valuable because even if the attacker evades one rule, another may catch them.

flowchart LR
  A["Initial access: vulnerable app"] --> B["Command execution in container"]
  B --> C["Discovery: reading config and credentials"]
  C --> D["Tool download and new executable"]
  D --> E["Lateral movement or escape attempt"]
  E --> F["Impact: data theft or crypto mining"]
        

Behavior patterns and the rules that watch for them

A detection tool that cries wolf is worse than none, because people stop listening.

Why noise happens

Default rules are written to be broadly useful, which means they cannot know what is normal in your cluster. Your monitoring agent, your service mesh sidecar, your backup job, and your deployment tooling may all do things that match generic suspicious patterns. If you do not teach Falco about them, it will report them again and again.

A repeatable tuning loop

A security tool that slows your applications or silently stops working is a liability.

Resource cost

Falco uses processor time and memory on every node. The amount depends mainly on how busy the node is and how many rules are loaded. Because filtering happens early, adding rules that match only a few event types costs little, while very broad rules that inspect every event cost more. Plan resource requests and limits from measurements taken in your own environment, not from guesses, and test on your busiest nodes, since they set the worst case.

Dropped events: the silent risk

If the node produces events faster than Falco can read them, the buffer that carries events from the kernel to user space can fill up, and some events are dropped. A dropped event is an event Falco never judged, which could be the very one that mattered. Falco reports drop counts so you can detect this condition. Treat sustained drops as an operational incident: investigate overly broad rules, increase resources, or adjust buffer sizes.

Kernel upgrades and driver health

When nodes upgrade their kernel, the driver must still work with it. The modern eBPF approach greatly reduces this concern because it adapts at load time instead of needing a matching prebuilt file. Even so, the safest practice is to upgrade nodes gradually and confirm that Falco is healthy on the first upgraded nodes before continuing.

Falco is one layer in a stack. Knowing what the other layers do shows you where Falco fits.

Detect, prevent, and harden

Security tools for Kubernetes fall into three families. Preventive tools stop bad things before they start, like admission controllers that refuse unsafe workloads. Hardening tools shrink what a workload is allowed to do, like profiles that restrict system calls or file access. Detective tools, where Falco belongs, watch what happens and report it. A strong program combines all three, because prevention can be bypassed, hardening can be too loose, and detection is the safety net under both.

Falco compared with newer eBPF-based tools

Other open-source projects also use eBPF for observability and security, and some can enforce policy directly in the kernel by blocking an action rather than only reporting it. The trade-off is a familiar one. Enforcement is powerful but riskier, because a wrong rule can break a healthy service. Detection is gentler and easier to adopt, and its rule language and ecosystem of integrations are mature. Many organizations start with detection to learn their environment and add enforcement later for a small number of well-understood behaviors.

Every tool has a shape. Knowing Falco’s shape helps you use it where it shines.

Reading the trade-offs correctly

None of these limits are reasons to avoid Falco. They are reasons to deploy it thoughtfully. The need for tuning, for instance, is true of every detection product in the world; it simply cannot know your normal behavior until you tell it. The privilege requirement is the price of seeing what the kernel sees, and it is manageable with proper isolation of the Falco namespace. And the fact that Falco reports instead of blocks is a deliberate design choice that keeps the observer simple, safe, and easy to trust.

Teams that succeed with Falco tend to follow the same handful of habits.

Learning from common failures is cheaper than learning from your own.

These illustrative scenarios show how different organizations typically apply runtime detection.

Default rules give you coverage. Custom rules give you protection that fits your business.

Start from behavior, not from tools

New rule authors often begin by asking, “Which attack tool should I look for?” That question leads to fragile rules, because attackers rename tools, repackage them, and switch to others. A sturdier approach is to ask, “What behavior would my service never legitimately show?” A payment service should never start a shell. A static web server should never open a connection to a database it has no business with. A batch job should never write into system directories. Rules built on behavior survive changes in attacker tooling, because the behavior they describe stays unacceptable no matter which tool performs it.

A checklist for each new rule

Common pitfalls in rule design

One cluster is a project. A fleet is an operation, and it needs consistency.

The fleet challenge

Organizations rarely have just one cluster. They have development, staging, and production, often in several regions and sometimes across several cloud providers. If each cluster runs a slightly different Falco configuration, coverage becomes uneven and nobody can say with confidence what is protected. The goal of fleet operations is to make the same security intent apply everywhere, with controlled differences where the environment truly demands them.

Declare, version, and roll out

The most reliable pattern is to describe your Falco setup, including rules, exceptions, driver choice, and outputs, as configuration stored in version control. A deployment tool then applies that configuration to every cluster from one source of truth. Changes go through review, are tested in a low-risk environment, and are promoted gradually. This approach, commonly called GitOps, also gives you a history of who changed what and why, which is valuable during audits and investigations.

flowchart LR
  A["Rule change proposed"] --> B["Peer review"]
  B --> C["Test in staging cluster"]
  C --> D["Canary: small production group"]
  D --> E["Full production rollout"]
  E --> F["Monitor alert volume and drops"]
  F -->|"Problem found"| G["Roll back to previous version"]
        

Handling differences between environments

Central visibility

Alerts from every cluster should include a cluster name so they can be sent to one central place without confusion. A central store lets analysts search across the entire fleet, spot an attacker moving between environments, and compare alert volumes to find clusters that are unusually noisy or suspiciously quiet.

A powerful security tool is also an attractive target. It deserves the same care you give your most sensitive systems.

Why Falco is a high-value target

Falco runs with elevated access on every node, sees the commands and file paths of every workload, and holds the credentials needed to send alerts to other systems. An attacker who can silence Falco gains freedom to act unseen. An attacker who can read its alerts learns how much you know about them. An attacker who can change its rules can create blind spots on purpose. So the protection of Falco is not an afterthought; it is part of the design.

Layers of protection

Alerts contain sensitive information

Command lines, file paths, user names, and image names can reveal sensitive details, and command lines sometimes contain passwords or tokens that users typed. Treat the alert stream as confidential data. Limit who can read it, set retention to match your policy and legal obligations, and consider whether certain fields should be masked before long-term storage.

The best time to decide how to react is before the alert arrives.

The first five minutes

When a serious alert arrives, the responder faces three questions in rapid succession. Is this real? How far has it gone? What should be done right now? A good workflow turns these into a short, repeatable sequence so that stress does not lead to improvisation.

flowchart TD
  A["Alert received"] --> B{"Known benign activity?"}
  B -->|"Yes"| C["Add precise exception and close"]
  B -->|"No or unsure"| D["Check related alerts"]
  D --> E{"Signs of compromise?"}
  E -->|"No"| F["Monitor and record findings"]
  E -->|"Yes"| G["Contain workload"]
  G --> H["Preserve evidence"]
  H --> I["Replace workload and rotate credentials"]
  I --> J["Improve rules and prevention"]
        

You do not need to do everything at once. A staged path lets value arrive early and risk stay low.

Three stages of adoption

Metrics that tell the truth

Thinking about cost honestly

Falco itself is free, but running it is not. Costs include the processor and memory it uses on each node, the storage for alert history, the engineering time to tune and maintain rules, and the people who respond to alerts. The largest cost, by far, is usually human attention. This is why quality matters more than quantity: a smaller number of precise, trusted alerts saves more money than a flood of noisy ones, and tuning work pays for itself quickly.

Kubernetes has its own special doors and windows. Knowing them tells you what to watch.

Why Kubernetes threats are different from ordinary server threats

A traditional server attack usually stays on one machine. A Kubernetes attack can spread through the orchestration layer itself. Every pod normally receives a credential that lets it talk to the cluster interface. Every node trusts the control plane. Every namespace shares the same underlying network unless told otherwise. An attacker who understands these relationships can turn a small foothold in one pod into influence over many workloads. Falco helps because it can see both the low-level activity inside the pod and the high-level cluster actions recorded in audit events.

A shared map of attacker behavior helps you see what you can catch and what you cannot.

What the framework is

MITRE ATT&CK is a public catalog that describes how real attackers behave, organized into stages called tactics, each containing specific techniques. Tactics include gaining initial access, executing commands, persisting after restarts, escalating privileges, evading defenses, stealing credentials, exploring the environment, moving sideways, and finally causing impact. Many Falco rules carry tags that point to the matching technique, so your alerts can be grouped and counted by attacker stage.

Reading your coverage honestly

Using the map to decide what to build next

A coverage map is not meant to reach one hundred percent. It is meant to start conversations. If you discover that credential access is strongly covered but lateral movement is thin, you can decide whether to write more rules, add network policy, or accept the risk with a clear record of the decision. Reviewing the map each quarter keeps detection work aimed at real gaps instead of at whatever is easy to write.

A rule that has never been tested is a hope, not a control.

Why rules deserve tests

Software teams would never ship an application feature without testing it, yet security rules are often deployed on faith. Rules can quietly stop working after an update, after a change in an image, or after a refactoring of shared macros. Testing gives you proof that important detections still fire and that harmless activity still stays quiet.

flowchart LR
  A["Write or change rule"] --> B["Automated syntax and loading check"]
  B --> C["Replay known-good activity: expect silence"]
  C --> D["Simulate harmless suspicious behavior: expect alert"]
  D --> E["Review results"]
  E --> F["Promote to production"]
        

Three kinds of checks

Purple team exercises

A purple team exercise brings together people who play the attacker role and people who play the defender role, working side by side. The attackers perform agreed, safe simulations of real techniques in a controlled environment, and the defenders check whether their tools noticed. Each missed technique becomes a concrete task: write a rule, tune an exception, or fix an alert path. Repeating these exercises a few times each year steadily raises confidence and quality.

Most problems fall into a few families. Recognizing the family speeds up the fix.

A simple method for any problem

Keep these short definitions handy while reading dashboards, rules, and incident reports.

Quick answers to the questions beginners ask most often.

On its own, Falco detects and reports. Blocking or reacting is done by companion tools such as a response engine, by your own automation, or by separate preventive controls like network policies and confinement profiles.

No. Falco watches the kernel on each node, so it works the same for any language or framework and requires no changes to application code or images.

The observation work is designed to be light, and filtering happens early. Real overhead depends on node activity and the number of rules, so measure in your own environment and set resource requests from those measurements.

On recent distributions the modern eBPF probe is generally the recommended choice because it needs no kernel headers or on-node compilation. Check your kernel version and node operating system, and keep an older option in mind for older kernels.

Often yes, but support depends on the provider and node image, especially for kernel-level access and audit log access. Test on a small pool first and read your provider’s guidance.

A scanner inspects software for known weaknesses before it runs. Falco watches live behavior while it runs. They answer different questions and work best together.

Start with the stable default set, tune it until it is quiet, then add more rules gradually. More rules are not automatically better; precise rules that people trust are better than many rules that people ignore.

If the event buffer overflows, some events are dropped and Falco reports the drop count. Monitor that metric and respond by simplifying overly broad rules, adding resources, or adjusting buffer settings.

Yes. With the audit plugin it can evaluate Kubernetes audit events using the same rule language, covering actions like secret access and privileged pod creation.

Send urgent alerts to the tool your on-call team uses, and send all alerts to a searchable store with a sensible retention period. The full history is invaluable when investigating incidents after the fact.

No. It also runs on ordinary Linux hosts and container hosts, and through plugins it can analyze cloud activity logs. Kubernetes is simply where it is most commonly deployed.

Run it as a per-node workload, monitor the number of healthy Falco pods against the number of nodes, and alert on any mismatch.

Kubernetes security does not end when a workload passes its scans and policy checks. Containers live for hours or days, share a kernel with their neighbors, and face attackers who specialize in behavior that no earlier check could predict. Falco answers that challenge by watching system calls and Kubernetes audit events, enriching them with container and cluster context, and comparing them against readable rules that describe suspicious behavior. Its companions route alerts to the right people and, where it is safe, trigger a measured response. Used with tuning, ownership, and layered prevention, it turns an invisible runtime into one you can see and understand.