RBAC decides who can create what, NetworkPolicy decides who can talk to whom, Pod Security Standards restrict what a pod can do from the moment it’s created. These three mechanisms share one thing in common: they act before or at the moment a pod starts, never after. Once the pod is running, seemingly compliant with all these rules, nothing else watches what’s actually happening inside it.

The blind spot static controls don’t cover

A container respecting runAsNonRoot, with a signed image, with minimal RBAC permissions, can still get compromised via an application vulnerability exploited at runtime: a command injection opening a shell, a compromised library reading sensitive files, a process attempting local privilege escalation. None of the static controls already covered detect this behavior, since they validate a configuration at creation time, not a behavior during execution.

Falco: watching syscalls live

Falco relies on eBPF (the same mechanism letting Cilium replace kube-proxy) to watch every process’s system calls in real time, comparing them against rules describing abnormal behavior. A shell spawned inside a container that should never spawn one, a read of /etc/shadow, an attempted write to a system binary: each Falco rule describes a precise pattern to watch for.

# Falco rule: detects a shell spawned in a container,
# a pattern with normally no reason to exist
- rule: Terminal shell in container
  desc: A shell was spawned inside a container
  condition: spawned_process and container and shell_procs
  output: "Shell spawned in container (user=%user.name container=%container.name)"
  priority: WARNING

What this changes compared to image scanning

An image scan (see the article on container image scanning and signing) detects known vulnerabilities in an image’s components, before deployment. Falco detects abnormal behavior during execution, independent of any known CVE: a perfectly scanned image with no listed vulnerability can still be exploited by a novel attack chain, something only runtime-observed behavior reveals.

The real challenge: tuning, not deployment

Installing Falco is the easy part; the real work is tuning rules for a specific environment, or alert volume becomes unmanageable. A generic rule like “shell spawned in a container” fires a legitimate alert for a manual debugging container (see the article on ephemeral container debugging), which has nothing to do with an intrusion. Without explicit exceptions for these known cases, the team receiving the alerts quickly learns to ignore them, canceling out the tool’s entire benefit.

# Explicit exception for a known legitimate case,
# without which every manual debug session fires a false alert
- macro: allowed_debug_shell
  condition: container.name = "debug-session"

Takeaway

RBAC, NetworkPolicy, and Pod Security Standards all act before or at the moment a pod starts, leaving a total blind spot on what happens once it’s running. Falco fills that blind spot by watching syscalls in real time via eBPF, detecting abnormal behavior independent of any known CVE, a capability no image scan can offer. The real work isn’t deployment but tuning rules to eliminate predictable false positives (manual debugging, legitimate tools), without which alert fatigue makes the tool useless, one of the pillars of reliability and observability that covers security in depth, not just at admission time.