How Does Falco Detect Threats at Runtime?
Learn how Falco uses eBPF and declarative rules to detect container threats in real time, with an example rule and interview tips.
Expected Interview Answer
Falco is an open-source, CNCF-graduated runtime security tool that taps into kernel syscall events using eBPF (or a kernel module driver) and evaluates them in real time against a declarative rules engine, alerting when container or host behavior matches a suspicious pattern.
Falco’s rules are written in a YAML-based language over a set of fields describing the process, container, file, and network context of each syscall, such as proc.name, container.id, or fd.name, letting an engineer write a rule like "alert if a shell is spawned inside a container that never normally spawns one" without writing kernel code. Because the instrumentation happens at the kernel boundary, Falco sees activity that application-level logging misses entirely, including an attacker who gained code execution and is now probing the filesystem or opening a reverse shell. Falco ships default rule sets covering common attack patterns — sensitive file reads, privilege escalation attempts, unexpected outbound connections — and teams layer custom rules for their own applications’ expected behavior. Alerts can be routed through Falcosidekick to Slack, PagerDuty, or a SIEM, and can also trigger automated response such as killing the offending pod via a webhook.
- Provides kernel-level visibility that application logs cannot see
- Detects live compromise attempts, not just known vulnerable packages
- Declarative rules make custom detection logic accessible without kernel code
- Integrates with alerting and automated response pipelines
AI Mentor Explanation
Falco is like a dedicated third umpire watching every single delivery through multiple camera angles in real time, flagging any action that breaks the rules the instant it happens, rather than reviewing footage after the match. The umpire uses a written rulebook of specific patterns to check against — an illegal bowling action, an underarm delivery — much like Falco’s declarative rules checking syscall patterns. Because the review is continuous and automated, a violation that a single on-field umpire might miss gets caught instantly. The match officials can then send the decision straight to the scoreboard for immediate action.
Step-by-Step Explanation
Step 1
Instrument the kernel
Falco loads an eBPF probe (or kernel module) that streams syscall events from every running process.
Step 2
Enrich with context
Each event is tagged with container, process, and file/network fields so rules can reference real context.
Step 3
Evaluate rules
Every event is matched in real time against declarative YAML rules describing suspicious conditions.
Step 4
Alert or respond
Matches are sent to Falcosidekick for Slack/PagerDuty/SIEM routing, or trigger automated remediation.
What Interviewer Expects
- Understanding that Falco operates at the kernel syscall level via eBPF
- Ability to describe the declarative rules engine and its context fields
- Knowledge of what Falco catches that logging or image scanning misses
- Awareness of alert routing and automated response integration
Common Mistakes
- Confusing Falco with a static image vulnerability scanner
- Not knowing that rules are declarative YAML, not custom code
- Assuming Falco only monitors network traffic, ignoring syscalls and file access
- Forgetting to mention alert routing or automated response as part of the workflow
Best Answer (HR Friendly)
“Falco watches what is actually happening inside our containers at the system level, in real time. If something suspicious happens, like a container spawning a shell it should never spawn, Falco catches it immediately using a set of rules we can customize, and it can automatically alert our team or even shut down the offending workload.”
Code Example
- rule: Read sensitive file untrusted
desc: Detect reads to sensitive files by non-trusted programs
condition: >
open_read
and fd.name in (/etc/shadow, /etc/passwd)
and not proc.name in (trusted_readers)
output: >
Sensitive file opened by untrusted process
(user=%user.name file=%fd.name process=%proc.name container=%container.name)
priority: CRITICALFollow-up Questions
- How would you tune Falco rules to reduce false positives in a busy cluster?
- What is the role of Falcosidekick in a Falco deployment?
- How does Falco differ from a network-focused IDS?
- How would you trigger automated remediation from a Falco alert?
MCQ Practice
1. What underlying kernel technology does Falco typically use to observe activity?
Falco taps into kernel syscalls via eBPF (or an older kernel module) for low-overhead, real-time visibility.
2. How are Falco detection rules written?
Falco rules are declarative YAML expressions matched against enriched syscall event fields like proc.name and container.id.
3. What is Falcosidekick used for?
Falcosidekick forwards Falco alert output to a wide range of external notification and response systems.
Flash Cards
What is Falco? — A CNCF runtime security tool detecting threats via real-time kernel syscall monitoring.
How does Falco observe activity? — Via eBPF (or a kernel module) instrumenting syscalls.
How are Falco rules written? — As declarative YAML conditions over enriched event fields.
What routes Falco alerts to Slack/PagerDuty? — Falcosidekick.