Container Runtime Security
Guide to container runtime security using eBPF, Falco, and behavioral analysis for detecting zero-day exploits and anomalous container behavior.
Continue your mission
Guide to container runtime security using eBPF, Falco, and behavioral analysis for detecting zero-day exploits and anomalous container behavior.
# Container Runtime Security
Container runtime security is the practice of monitoring, detecting, and blocking malicious behavior inside containers while they are actively running in production. It exists because static analysis, image scanning, and pipeline controls operate on artifacts before deployment, but attacks frequently occur after a container starts. A vulnerability patched in no registry can be zero-day in production; a package that was clean at build time may have been tampered with upstream; an authenticated user may abuse a legitimate application to spawn a shell. Runtime security closes that gap by observing container behavior at the kernel level, comparing it against defined or learned baselines, and responding automatically when anomalies appear. It is the enforcement layer that operates when all other defenses have already been passed.
---
Container runtime security refers to the continuous observation and enforcement of expected behavior for containerized workloads during execution. It operates at the boundary between the container and the host operating system kernel, inspecting system calls, network connections, file system changes, and process activity as they happen in real time.
This discipline is distinct from several adjacent practices that are frequently conflated with it. Image scanning examines container images before deployment, identifying known vulnerabilities in installed packages. Static analysis reviews Dockerfiles and infrastructure-as-code for misconfigurations at authoring time. Pod security policies and admission controllers enforce constraints at scheduling time, before a container ever runs. Container runtime security begins where all of those stop: at the moment of execution and for the full duration of a container's life.
It is not the same as host intrusion detection, which monitors the underlying virtual machine or bare-metal host. Runtime security is container-aware, meaning it understands namespaces, cgroups, container identities, and Kubernetes metadata. A host IDS would see a suspicious process; a container runtime security tool would see that process, identify which pod it belongs to, note the deployment name, and correlate it with network egress in the same container, all within a single event.
Subtypes include behavioral detection (anomaly-based), rules-based detection (signature-like policies for known bad patterns), file integrity monitoring for container filesystems, network traffic analysis inside container networks, and kernel exploit detection through system call filtering. Some platforms combine all of these; others specialize. Both open-source tools such as Falco and commercial platforms such as Sysdig Secure, Aqua Security, and Palo Alto Prisma Cloud fall within scope.
---
Container runtime security tools intercept or observe activity between the container process and the Linux kernel. Two primary mechanisms accomplish this: system call interception using eBPF (extended Berkeley Packet Filter) probes, and kernel modules that hook into the system call table directly.
eBPF-Based Observation
eBPF allows programs to run inside the Linux kernel without modifying kernel source code or loading traditional kernel modules. A runtime security tool attaches eBPF probes to kernel functions, such as execve (process execution), open (file access), connect (network connection initiation), and clone (process or thread creation). Every time a container process triggers one of these calls, the eBPF probe fires, captures the relevant data, and passes it to a userspace agent for evaluation. Because eBPF runs in a sandboxed kernel environment, the overhead is low and the visibility is comprehensive. Falco, the CNCF-graduated runtime security project, operates through an eBPF driver by default in modern deployments, though it also supports a kernel module driver for older kernel versions.
Rules Evaluation and Detection
Falco rules are written in YAML and express conditions over a structured event stream. A rule detecting a shell spawned inside a container might read: if the system call is execve, the process name is bash or sh, and the container is not in an explicit allowlist, generate an alert. Rules include priority levels (WARNING, ERROR, CRITICAL), output fields that format the alert message, and tags that map to MITRE ATT&CK techniques. The rule engine evaluates each captured event against all applicable rules in microseconds. When a condition matches, the output is written to the configured sink: standard output, a file, a Falco sidekick forwarder to Slack, PagerDuty, a SIEM, or a webhook endpoint.
Behavioral Baselines and Drift Detection
Commercial platforms extend the rules-based model with machine learning baselines. During an initial learning period, the platform observes all container activity and constructs a behavioral profile: which processes run, which files are read and written, which network destinations are contacted, which system calls are made. After the learning window closes, deviation from that profile constitutes drift and triggers an alert or block. This approach catches zero-day exploitation where no rule was written for the specific behavior, because the behavior itself is simply not part of the baseline.
File Integrity Monitoring
Container filesystems are expected to be immutable after deployment. A correctly built container has no reason to write new binaries to /usr/bin, modify /etc/passwd, or alter library files in /lib. File integrity monitoring (FIM) continuously hashes files in designated paths and detects modifications. When a web server container writes a new executable to a system directory, that is a strong indicator of post-exploitation activity, regardless of what the file is or whether it matches a known signature.
Network Monitoring and DNS Analysis
The network layer reveals attacker intent after initial compromise. Runtime security tools monitor connection attempts from containers to external IPs, correlating them against threat intelligence feeds. DNS resolution monitoring catches beaconing: a container that suddenly resolves a domain it has never resolved before, particularly a newly registered domain or one associated with command-and-control infrastructure, is exhibiting suspicious behavior independent of any specific vulnerability signature.
Concrete Scenario: Exploited Web Application
A Node.js application container passes all image scans because it contains no known CVEs at build time. Three weeks after deployment, a researcher discloses a remote code execution vulnerability in a dependency. Before the team patches and redeploys, an attacker exploits the vulnerability, achieving code execution inside the container. The attacker runs curl to download a secondary payload, then executes it.
Without runtime security, this activity completes silently. With Falco running an eBPF driver on the node, three detections fire within seconds: the first when the container spawns curl (a process not in the baseline); the second when a new binary is written to the container filesystem; the third when the new process makes an outbound connection to an IP flagged in a threat intelligence feed. The Falco sidekick forwards the critical alert to the team's SIEM, which triggers an automated response playbook. Kubernetes terminates the pod within 90 seconds of the initial exploit. The attacker's foothold is destroyed before lateral movement begins.
Implementation Considerations
Deploying runtime security in Kubernetes requires a DaemonSet that runs the agent on every node. Kernel version compatibility must be confirmed before rollout; eBPF-based drivers require kernel 4.14 or later. Privileged access for the agent is unavoidable because observing kernel activity requires elevated permissions. This access must itself be secured and audited. Rule tuning is operationally significant: default rulesets generate noise in most production environments. Teams should expect a tuning period of two to four weeks before alert fidelity is high enough for automated response.
---
The business impact of undetected container compromise is measured in data exfiltration, credential theft, cryptomining resource consumption, and regulatory exposure. Containers present a unique risk profile because they are designed to be short-lived, ephemeral, and high-volume. An attacker who achieves code execution inside a container and is not detected can pivot to secrets mounted as environment variables, service account tokens with broad Kubernetes API permissions, or network-accessible internal services. Runtime security detects the pivot attempts themselves rather than waiting for downstream consequences.
The Limits of Pre-Deployment Scanning
A persistent misconception is that comprehensive image scanning makes runtime security redundant. This is operationally false. CVE databases lag behind vulnerability disclosure; zero-days by definition have no database entry. Supply chain attacks such as the SolarWinds compromise and the 2021 ua-parser-js npm package hijacking introduced malicious code into packages that passed all automated checks at build time. Runtime security detects the malicious behavior when it executes, regardless of whether a signature exists for it.
Real-World Consequence: Cryptomining at Scale
In 2020, Aqua Security's threat intelligence team documented a campaign in which attackers scanned for exposed Docker daemon APIs, deployed their own container images, and ran cryptomining software inside victim infrastructure. Organizations with no runtime security ran the attackers' workloads for weeks before noticing abnormal cloud compute bills. Organizations with runtime security detected the anomalous process execution (a cryptocurrency miner is not a normal application workload) within minutes of container startup. The difference in blast radius was measured in thousands of dollars of compute cost and in whether the attackers established persistence on the underlying host.
Regulatory and Compliance Drivers
NIST SP 800-190, the authoritative guidance on container security, explicitly calls for runtime monitoring as a required control layer. PCI DSS 4.0 requires monitoring of all system components for unauthorized activity. Without runtime security, demonstrating compliance with these requirements for containerized workloads requires manual processes that do not scale.
---
The Planetary Defense Model (PDM) treats container runtime security as a core component of the Threat Intelligence and Detection (TID) domain, with significant overlap into Vulnerability and Supply Chain Defense (VSD). CDA's methodology, Predictive Defense Intelligence (PDI), is expressed in the operational principle: "See the threat before it sees you."
In the context of container runtime security, PDI means that detection must be anticipatory and behavioral, not reactive and signature-dependent. CDA designs runtime security programs around the assumption that every container fleet will eventually contain a compromised workload. The question is not whether an exploit will occur, but how quickly it will be detected and contained. CDA calls this the Detection Time Objective (DTO), a measurable operational metric analogous to Recovery Time Objective in business continuity planning.
CDA's operational approach includes three elements that differentiate it from generic deployment of runtime security tools. First, CDA maps Falco rules and commercial platform policies directly to MITRE ATT&CK for Containers techniques, ensuring that every detection has a documented adversary behavior behind it and a defined response playbook. This prevents the common failure mode of generating alerts with no operational context.
Second, CDA integrates runtime security telemetry into a threat intelligence feedback loop. When a container in a client environment attempts to connect to a command-and-control IP, that indicator is submitted to shared threat intelligence platforms, benefiting the broader defensive community. PDI treats runtime detection as a data collection function, not just an alerting function.
Third, CDA treats rule tuning as an ongoing operational commitment, not a one-time configuration task. Container workload behavior changes as applications are updated. CDA's runtime security engagements include quarterly tuning reviews, baseline refresh cycles aligned with major application releases, and tabletop exercises simulating container compromise scenarios. The goal is a detection capability that degrades gracefully as the environment evolves rather than generating alert fatigue that causes responders to disable it.
---
---
---
CDA Theater missions that address topics covered in this article.
Guide to AWS Security Hub for centralized finding aggregation, continuous compliance monitoring, and automated remediation across AWS organizations.
Vendor assessment guide for HashiCorp Vault.
Wireshark is the leading network protocol analyzer for traffic capture and security investigation.
Written by CDA Editorial
Found an issue? Help improve this article.