When Prevention Fails
SAST, DAST, SCA, and container scanning are all preventative controls — they try to stop known vulnerabilities from reaching production. But prevention is never perfect:
- A zero-day vulnerability is discovered in your production application today, before any scanner has a signature for it.
- An attacker finds a logic flaw that DAST missed because the attack required a specific sequence of authenticated requests.
- A compromised dependency (supply chain attack) executes malicious code that passed all pre-deployment checks.
- An insider threat or stolen credential gives an attacker legitimate access.
For these scenarios, you need a different category of control: runtime security.
How Falco Works
Falco (a CNCF graduated project, originally by Sysdig) is the leading open-source runtime security tool for Linux and Kubernetes. It works by hooking into the Linux kernel — either via an eBPF probe or a kernel module — to observe every system call made by every process running on the host.
System calls are the fundamental interface between user-space programs and the OS kernel. Every file read, network connection, process spawn, and privilege escalation goes through a system call. By monitoring at this level, Falco sees everything, regardless of what language the application is written in or how it was packaged.
You define rules that describe what "normal" looks like for your workloads. Falco alerts when behavior deviates from those rules.
Examples of built-in Falco rules:
# Alert if a shell is spawned inside a container
- rule: Terminal shell in container
desc: A shell was spawned in a container
condition: >
spawned_process and container
and shell_procs and proc.tty != 0
output: >
A shell was spawned in a container
(user=%user.name container=%container.name
shell=%proc.name parent=%proc.pname)
priority: WARNING
# Alert if sensitive files are read
- rule: Read sensitive file untrusted
desc: An attempt to read a sensitive file by a non-trusted program
condition: >
sensitive_files and open_read
and not proc.name in (trusted_programs)
output: >
Sensitive file opened for reading
(user=%user.name file=%fd.name
container=%container.name)
priority: ERROR
Common Falco alert scenarios:
| Suspicious Behavior | What It Likely Indicates |
|---|---|
Web server (nginx/apache) spawns /bin/bash |
Remote Code Execution (RCE) attack |
Container reads /etc/shadow |
Credential harvesting attempt |
| Application makes outbound connection to unexpected IP | Data exfiltration or C2 beacon |
| Container mounts the host filesystem | Container escape attempt |
kubectl executed inside a running pod |
Attacker exploring the cluster |
Falco integrates with alerting systems (Slack, PagerDuty, SIEM tools) so that security teams are notified in real time when suspicious behavior is detected.
Interviewers at security-conscious companies often ask: "How would you detect if a container was compromised at runtime?" The answer should mention behavioral anomaly detection, not just scanning. Specifically: deploy a tool like Falco that monitors syscalls and alerts on deviations from baseline behavior (e.g., a web server spawning a shell). Complement this with network policy enforcement (Kubernetes NetworkPolicy or a service mesh) to limit blast radius if a container is compromised.
Key Point: Runtime protection is detective, not preventative. It does not stop an attack from starting — it detects that an attack is in progress and triggers a response. The goal is to minimize dwell time (how long an attacker operates undetected). The industry average dwell time before detection is measured in weeks; a well-tuned Falco deployment can reduce this to seconds.