Container image scanning tells you what vulnerabilities exist in a container before it runs. Runtime security tells you what is actually happening inside a container while it runs. These are fundamentally different problems that require fundamentally different tools.
Scanning analyzes static artifacts — filesystem layers, package manifests, configuration files. Runtime security monitors dynamic behavior — system calls, network connections, file access patterns, process execution. A container image can pass every scan with zero critical CVEs and still be compromised at runtime through a zero-day exploit, a supply chain attack that injected malicious behavior into a legitimate dependency, or an attacker who gained access through a completely different vector and is now moving laterally into your containers.
This guide covers the four major approaches to container runtime security in 2026: syscall-based detection (Falco), commercial runtime platforms (Sysdig Secure, Aqua), eBPF-native enforcement (Tetragon), and the operational practices that determine whether runtime security actually stops attacks or just generates alerts that no one reads.
Why Runtime Security Catches What Scanning Misses
The argument for runtime security becomes obvious when you examine what actually happens during real container compromises. Here are the attack patterns that image scanning cannot detect:
| Attack Pattern | Why Scanning Misses It | How Runtime Detects It | Real-World Example |
|---|---|---|---|
| Zero-day exploitation | No CVE exists yet, scanner has no signature | Unusual syscall patterns: unexpected shell spawned, binary downloaded and executed | Log4Shell — containers were exploited before scanners had detection rules |
| Supply chain compromise | Malicious code injected into legitimate dependency, passes hash verification | Outbound network connection to C2 server, cryptominer process consuming CPU | SolarWinds, event-stream npm package, codecov bash uploader |
| Container escape | Escape exploits kernel vulnerabilities, not container image vulnerabilities | Privileged syscalls (mount, ptrace), access to host filesystem paths, namespace manipulation | CVE-2024-21626 (Leaky Vessels) runc container escape |
| Credential theft | Credentials are injected at runtime via environment variables or mounted secrets | Process reading Kubernetes service account tokens, API calls to cloud metadata service | IMDS credential theft from compromised pods accessing 169.254.169.254 |
| Lateral movement | Scanning checks individual images, not inter-container communication | Unexpected network connections between pods, port scanning, DNS lookups for internal services | Attacker in web pod scanning for database pods on internal network |
The critical insight is that runtime security and image scanning are complementary, not competing. Scanning reduces the vulnerability surface area. Runtime security monitors the remaining attack surface for active exploitation. Organizations that deploy both reduce container-related security incidents by an average of 82 percent compared to those using scanning alone.
How Container Runtime Detection Works Under the Hood
Every action a container takes — reading a file, opening a network connection, spawning a process, executing a system call — is mediated by the Linux kernel. Runtime security tools intercept these kernel-level events and evaluate them against security rules to detect anomalous or malicious behavior.
The Three Instrumentation Approaches
There are three ways to observe container behavior at the kernel level, each with different trade-offs:
| Approach | How It Works | Performance Impact | Safety | Tools Using It |
|---|---|---|---|---|
| Kernel module | Loadable kernel module hooks into syscall table. Full access to kernel data structures | Low to moderate (2-5%) | Low — bugs can crash the entire node. Requires privileged access to load | Falco (legacy driver), older Sysdig versions |
| eBPF | Programs compiled to BPF bytecode, verified by kernel, run in sandboxed VM | Very low (1-3%) | High — verifier prevents crashes, programs cannot access arbitrary memory | Falco (modern driver), Tetragon, Sysdig, Aqua, Datadog |
| ptrace / seccomp-bpf | Userspace tracing via ptrace or kernel-level filtering via seccomp BPF programs | High for ptrace (10-30%), low for seccomp | High — runs in userspace (ptrace) or uses restrictive BPF subset (seccomp) | Seccomp profiles (Kubernetes native), strace for debugging |
In 2026, eBPF is the clear winner. It provides kernel-level visibility with near-zero overhead and cannot crash the host. Every major runtime security tool has migrated to eBPF as its primary instrumentation method. The kernel module approach is legacy — only maintained for older kernels (pre-4.14) that lack eBPF support.
Falco: The CNCF Standard for Runtime Detection
Falco is a CNCF graduated project and the de facto standard for open-source container runtime detection. It monitors system calls made by containers and evaluates them against a rule engine that detects suspicious behavior — shell spawned in container, sensitive file read, unexpected outbound network connection, privilege escalation attempt.
How Falco Works
Falco's architecture has three components:
- Driver — the eBPF probe (or legacy kernel module) that captures syscall events from the kernel. The modern eBPF driver is the recommended option for kernels 4.14 and above. A newer "modern eBPF" driver (using CO-RE — Compile Once, Run Everywhere) eliminates the need to compile the probe for each kernel version.
- Userspace engine — the Falco binary that receives raw syscall events from the driver, enriches them with container metadata (image name, pod name, namespace, labels) and Kubernetes metadata, then evaluates them against loaded rules.
- Output channels — Falco outputs alerts to stdout, syslog, HTTP endpoints, gRPC, or the Falcosidekick companion that routes alerts to 60+ destinations (Slack, PagerDuty, Elasticsearch, Kafka, AWS SNS, and more).
Writing Effective Falco Rules
Falco rules use a YAML-based syntax with three key fields: a condition (the syscall event pattern to match), an output (the alert message template), and a priority (the severity level). Rules can reference macros (reusable condition snippets) and lists (sets of values).
The default Falco ruleset includes approximately 90 rules covering the most common container attack patterns. But the real power comes from writing custom rules tailored to your specific workloads. Here are the categories of rules every production deployment should include:
| Rule Category | What It Detects | Example Condition | Priority |
|---|---|---|---|
| Shell spawned in container | Interactive shell (bash, sh, zsh) started in a non-debug container | spawned_process and container and proc.name in (bash, sh, zsh, csh) and not user_shell_containers | WARNING |
| Sensitive file access | Process reads /etc/shadow, /etc/passwd, Kubernetes service account tokens | open_read and container and sensitive_files and not trusted_processes | WARNING |
| Unexpected network connection | Container makes outbound connection to IP not in allowlist | outbound and container and not expected_outbound_destinations | NOTICE |
| Binary not in image | Process executes a binary that was not present in the original image (drift) | spawned_process and container and not proc.name pmatch (image_binary_list) | CRITICAL |
| Privilege escalation | Process uses setuid/setgid, ptrace, or attempts to modify capabilities | syscall.type in (setuid, setgid, setns) and container | CRITICAL |
| Cryptomining indicators | Connection to known mining pools or processes with mining-related names | outbound and fd.sip.name contains "pool" or proc.name in (xmrig, minerd, cpuminer) | CRITICAL |
| Kubernetes API abuse | Pod making unexpected calls to the Kubernetes API server | outbound and fd.sport=443 and fd.sip=kube-apiserver-ip and not expected_api_callers | WARNING |
Falco in Kubernetes: The Falco Operator
Deploying Falco in Kubernetes is handled by the official Helm chart, which deploys Falco as a DaemonSet (one pod per node) with the eBPF driver. The Helm chart also deploys Falcosidekick for alert routing.
Key configuration decisions for Kubernetes deployments:
- Driver selection — use the modern eBPF driver (set driver.kind=modern_ebpf) for kernels 5.8+. This eliminates the need to build or download a probe for each kernel version and works across different distributions without modification.
- Resource limits — allocate 200m CPU and 512Mi memory per Falco pod as a starting point. Monitor actual usage for two weeks and adjust. High-traffic nodes may need more.
- Rule customization — mount custom rules as a ConfigMap. Override default rules that generate excessive noise for your workloads using rule append and exception mechanisms rather than disabling rules entirely.
- Falcosidekick deployment — deploy Falcosidekick as a separate Deployment (not DaemonSet) with 2 replicas for availability. Configure outputs to your SIEM and incident response platform.
Sysdig Secure: Commercial Runtime Security
Sysdig Secure uses Falco as its detection engine (Sysdig is the primary corporate sponsor of Falco) but adds a comprehensive commercial layer: centralized dashboard, managed rule updates, automated response actions, forensic capture, compliance reporting, and support SLAs.
What Sysdig Adds Beyond Falco
| Capability | Falco (Open Source) | Sysdig Secure |
|---|---|---|
| Detection engine | Same Falco rules engine | Same engine plus managed threat intelligence rules updated daily |
| Dashboard | None — alerts go to stdout/syslog/webhook | Centralized web UI with alert triage, search, filtering, and investigation workflows |
| Automated response | Manual — must build your own automation | Kill container, pause container, capture forensics, notify team — configurable per rule |
| Forensic capture | Not included | Captures full syscall trace, network connections, and file activity for post-incident analysis |
| Activity audit | Not included | Records all kubectl commands, API calls, and interactive sessions for audit trails |
| Drift prevention | Detection only (alert when new binary appears) | Enforcement — block execution of binaries not in original image |
| Compliance | Not included | PCI-DSS, HIPAA, SOC 2, NIST mappings with continuous evidence collection |
| Image profiling | Not included | Automatically learns normal behavior per image and generates tailored rules |
The key value proposition of Sysdig Secure is the combination of runtime-informed image scanning (using runtime data to prioritize which image vulnerabilities actually matter) with runtime detection (catching active threats). This closed loop — where runtime intelligence improves scanning prioritization, and scanning results inform runtime rule tuning — is what distinguishes a platform from a point tool.
Tetragon: eBPF-Native Runtime Enforcement
Tetragon (by Isovalent, now part of Cisco) takes a different approach from Falco. While Falco primarily detects and alerts, Tetragon can enforce policies directly in the kernel — killing processes, dropping network connections, or blocking syscalls — before the malicious action completes. This is possible because Tetragon's eBPF programs attach at the kernel level and can intervene before the syscall returns to userspace.
Tetragon vs Falco: When to Use Which
| Dimension | Falco | Tetragon |
|---|---|---|
| Primary function | Detection and alerting | Detection and kernel-level enforcement |
| Enforcement capability | Alert only — requires external automation for response | Kill process, sigkill, override return value — directly in kernel |
| Policy language | Falco YAML rules (mature, large community) | TracingPolicy CRDs (Kubernetes-native, growing community) |
| Kubernetes integration | DaemonSet via Helm, metadata enrichment, Kubernetes audit log support | Native CRD-based policies, deep Cilium integration, identity-aware enforcement |
| Community maturity | CNCF graduated (2024), 7K+ GitHub stars, wide ecosystem | CNCF sandbox (maturing), growing rapidly, strong Cilium ecosystem |
| Performance overhead | 1-3% CPU (detection only) | 1-3% CPU (detection), slightly higher with enforcement enabled |
| Best for | Detection-focused deployments, teams with existing SIEM/SOAR, broad ecosystem needs | Enforcement-focused deployments, Cilium users, teams that want kernel-level blocking |
Many organizations deploy both: Falco for its mature rule ecosystem and broad alert routing (via Falcosidekick), and Tetragon for kernel-level enforcement of critical policies (blocking container escapes, preventing privilege escalation). The two tools do not conflict — they attach to different eBPF hooks and can coexist on the same nodes.
Drift Prevention: The Highest-Impact Runtime Control
If you implement only one runtime security control, make it drift prevention. Drift prevention enforces the principle that a running container should be identical to its image — no new binaries, no modified configuration files, no additional packages installed at runtime.
Why drift prevention is so effective: 94 percent of container attacks involve modifying the container filesystem after launch. Attackers download exploit tools, install backdoors, modify configuration files, or drop cryptominer binaries. If the container cannot be modified, these attack techniques fail completely.
How Drift Prevention Works
At container start, the runtime security tool records the complete filesystem manifest of the container image — every file, its hash, and its permissions. During runtime, any attempt to write a new executable file, modify an existing binary, or execute a binary that was not in the original manifest is either detected (alert mode) or blocked (enforcement mode).
Implementation options:
- Read-only root filesystem — Kubernetes natively supports setting readOnlyRootFilesystem: true in the security context. This is the simplest approach but also the most restrictive — it blocks all filesystem writes, including to temporary directories that many applications need.
- Sysdig drift prevention — monitors for new executable files and blocks their execution without requiring a read-only filesystem. Applications can still write to /tmp, log directories, and data volumes, but cannot create or execute new binaries.
- Aqua drift prevention — similar approach with image integrity monitoring. Blocks execution of any binary not present in the original image hash manifest.
- Tetragon enforcement policies — write TracingPolicy CRDs that block exec syscalls for binaries not matching an allowlist derived from the container image.
Aqua Runtime Protection
Aqua's runtime protection takes a fundamentally different architectural approach from Falco and Sysdig. Instead of deploying a DaemonSet agent on each node, Aqua injects a lightweight runtime protection component — the MicroEnforcer — directly into each container at build time. This means runtime protection travels with the container regardless of where it is deployed.
Key differentiators:
- MicroEnforcer — embedded into the container image during the CI pipeline. Provides file integrity monitoring, process blocking, and network control without requiring a privileged DaemonSet on the host. Approximately 15 to 25 MB overhead per container.
- Dynamic Threat Analysis (DTA) — runs containers in a sandbox before production deployment, monitoring for malicious behavior (network calls to known-bad IPs, file system modifications, privilege escalation). Catches supply chain attacks that static scanning misses.
- vShield — virtual patching for vulnerable packages in running containers. When a critical CVE is published, Aqua can deploy a virtual patch that blocks exploitation of the vulnerable function without rebuilding the container image. Buys time for development teams to apply a proper fix.
- Network control — maps allowed network connections per container based on learned behavior, then blocks unexpected connections. Effectively implements microsegmentation at the container level without requiring a service mesh.
Container Incident Response Playbook
When your runtime security tool fires a critical alert, your team needs a practiced response procedure. Container incident response differs from traditional IR in several important ways:
| IR Phase | Traditional VM/Server | Container-Specific |
|---|---|---|
| Containment | Isolate host via firewall rules, disable user accounts | Kill the specific container (or pod). The replacement container starts clean from the image. Network policies isolate the namespace. |
| Evidence preservation | Create disk image, capture memory dump | Export container filesystem diff, capture Falco/Sysdig event stream, save container logs. The ephemeral nature means evidence disappears when the container is killed. |
| Root cause analysis | Analyze disk artifacts, memory forensics | Review container image for vulnerabilities (how they got in), analyze syscall traces (what they did), correlate with Kubernetes audit logs (how they moved laterally) |
| Recovery | Patch and rebuild server, restore from backup | Rebuild image with fix, push to registry, rolling update replaces all pods. Recovery is typically minutes rather than hours. |
| Hardening | Update firewall rules, patch management | Add Falco rules for the specific attack pattern, tighten Pod Security Standards, add network policies, update admission controller policies |
The Container IR Decision Tree
When a runtime alert fires, the first decision is whether to kill the container immediately or preserve it for forensics. This depends on two factors:
- Is the attack still in progress? If the attacker is actively exfiltrating data or moving laterally, kill the container immediately. A running investigation is not worth allowing continued data loss.
- Do you have forensic capture enabled? If Sysdig Secure or a similar tool is recording the full syscall stream, you already have the forensic evidence. Kill the container — the recording is your evidence. If you do not have forensic capture, consider pausing the container (docker pause / kubectl debug) to preserve its state while you export the filesystem diff and logs.
In either case, the Kubernetes scheduler will automatically create a new clean container from the original image, so killing a compromised container has minimal operational impact beyond a brief restart period.
Operational Practices That Determine Success or Failure
The difference between organizations that successfully use runtime security and those that treat it as shelfware comes down to operational practices, not tool selection.
The Detect-to-Enforce Transition
Every runtime security tool should be deployed in detect-only mode first. But the most common mistake is staying in detect mode permanently. Here is the recommended timeline for transitioning to enforcement:
| Phase | Timeline | Mode | Actions |
|---|---|---|---|
| Learning | Days 1-14 | Detect only, log all events | Establish baseline for normal behavior per workload type. Identify legitimate behaviors that trigger default rules. Build exception lists. |
| Tuning | Days 15-45 | Detect with refined rules | Apply per-image rule profiles. Reduce false positive rate to under 5 per day per cluster. Validate detection coverage with attack simulations. |
| Selective enforcement | Days 46-75 | Enforce critical rules, detect the rest | Enable enforcement for highest-confidence rules: shell in container, binary not in image, cryptominer indicators. Keep nuanced rules in detect mode. |
| Full enforcement | Days 76-90 | Enforce all tuned rules | All production-validated rules in enforcement mode. Detect-only mode reserved for new rules during their tuning period. |
Metrics That Matter
Track these five metrics to evaluate the effectiveness of your runtime security program:
- Mean time to detect (MTTD) — how quickly do you detect a container compromise after it begins? Target: under 60 seconds for automated detection.
- Mean time to respond (MTTR) — how quickly does your team contain a detected threat? Target: under 5 minutes for automated containment, under 30 minutes for manual response.
- False positive rate — how many alerts per day require no action? Target: under 5 per cluster per day. If your team sees more than this, they will start ignoring alerts.
- Detection coverage — what percentage of MITRE ATT&CK for Containers techniques do your rules cover? Target: at least 80 percent coverage of the execution, persistence, privilege escalation, and defense evasion tactics.
- Enforcement ratio — what percentage of your detection rules are in enforcement mode versus detect-only? Target: at least 70 percent enforcement after the 90-day transition period.
The organizations that treat these as real operational metrics — tracking them weekly, setting improvement targets, and holding post-incident reviews when detection fails — are the ones that actually prevent container breaches rather than just detecting them after the damage is done.
