The question I keep getting from other security operations (SecOps) leads is some version of the same story: the pipeline gated on the image scan, the scan came back green, and the container got compromised anyway. A peer running Amazon Elastic Kubernetes Service (EKS) told me the team found a miner in a pod that had passed every admission check they had.
I've had the buyer's version of that conversation too. I help set the controls for our cloud-native security stack, and the hardest meeting I've taken with my own leadership was explaining that a clean vulnerability report can coexist with a compromised workload. The two findings answer different questions.
In brief:
- A green image scan tells you the scanner found no known Common Vulnerabilities and Exposures (CVEs) or policy issues in the image at scan time, and nothing about what the container is doing right now, where attackers operate.
- Runtime adds visibility into four high-value execution-time signals other controls see only partly: container escape and privilege escalation, processes that don't belong, drift from the image, and cryptomining in a pod.
- On Linux, these detections rely on process, file, network, syscall, and extended Berkeley Packet Filter (eBPF) kernel telemetry.
- Runtime complements image scanning, admission control, and Kubernetes audit logging rather than replacing them. Most deployments alert after behavior begins, and runtime has documented blind spots, so posture work stays necessary.
Why a green image scan doesn't mean the container is safe
The scanner and the runtime sensor answer different questions on different timelines, and conflating them is how teams end up surprised.
Build-time posture and runtime are different questions
A vulnerability-focused image scanner inspects image contents and package metadata, often producing or consuming a software bill of materials (SBOM), to identify known vulnerabilities and policy issues. Because it doesn't execute the workload, it can't see exploit attempts, process trees, downloads, filesystem changes, or outbound connections that occur after deployment.
A public image built to mine cryptocurrency can pass a CVE-focused vulnerability scan because mining is its intended purpose and depends on no software flaw. A clean image can also run on a host with flaws in its container runtime, kernel, device toolkit, or configuration that let a malicious container cross the isolation boundary.
Application logic exploited after deployment can trigger vulnerable behavior, and attackers can then download tools or mine crypto.
The timelines make that window operational. Microsoft's 2025 Digital Defense Report found cryptominers accounted for 58% of infections in compromised containers, most hit within 48 hours of deployment, with cryptomining the fastest median time to compromise.
What container runtime security actually catches
Runtime security is especially valuable for four execution-time signals: escape and privilege escalation, unexpected processes, drift from the image, and resource hijacking. Other controls can contribute evidence or block risky configurations, but they don't replace direct observation of a workload's live process and kernel activity.
Container escape and privilege escalation
Escapes are invisible to scanning because exploit behavior emerges only during execution. The high-level paths are well documented: privileged containers, host filesystem bind mounts, malicious kernel modules, and abuses of syscalls like unshare and keyctl.
The runtime-observable signal is the process activity itself, so the question that matters for a tool is whether it shows the process, container identity, syscall or kernel event, target path, and policy context that make the alert actionable.
MITRE ATT&CK's Escape to Host technique gives teams a common vocabulary for these behaviors. Its detection strategy points at signals like unshare and keyctl syscalls, host filesystem bind mounts, and kernel module loads, though not every product ships those enabled by default.
When I evaluate runtime tools now, my first demo question is which of these syscall patterns the product surfaces by default, because a tool that can't show me the kernel activity behind an escape attempt isn't watching the layer I'm paying for.
Processes that shouldn't be running in the container
A production container usually has a small, predictable process set, so an interactive shell is a high-signal event there, while in a debugging-heavy or mutable environment it may be expected. A kernel sensor can also see nsenter executing from a container, or a package manager running three weeks after deployment.
For container administration command abuse such as docker exec, kubectl exec, or the kubelet API, Kubernetes audit logs commonly show the exec request while in-container process telemetry shows the resulting shell. Correlating the two is stronger than either alone.
Discovery activity such as kubectl get pods or kubectl get nodes maps to container and resource discovery, but it usually surfaces in Kubernetes audit and control-plane telemetry rather than an in-container sensor, so treat it as a correlating signal. None of it exists at build time, because a scanner has no concept of a process tree.
Drift from the image, and crypto-mining in a pod
Drift detection compares runtime changes against the image: image layers are generally read-only, while files introduced at runtime appear in the container's writable filesystem layer, often OverlayFS's upperdir on Linux.
Runtime tools use this distinction to flag execution of binaries that weren't part of the original image, which surfaces malware, miners, and attack tools introduced after deployment, and some implementations can prevent execution.
When a vulnerable application downloads a previously unseen miner, a drift-prevention policy on an enforcement-capable tool can block it purely on the binary's absence from the deployed image, with signatures playing no role.
Monitoring-only deployments alert rather than block, though, and expected updates, package installs, or app-generated executables can trigger false positives.
Cryptomining is a common and operationally visible container abuse pattern, and the economics explain why: attackers consume the victim's cloud resources and keep the proceeds while the organization pays the infrastructure bill. Miner payloads can arrive quickly after a workload becomes reachable.
A new binary in that writable layer can indicate resource hijacking, which analysts correlate with sustained CPU and outbound connections to mining pools. Image scanning sees none of it, because none of it existed at build time.
Where the runtime signal comes from
None of the above works without telemetry from the kernel, and the mechanics matter when you're comparing tools.
Syscall and eBPF telemetry at the kernel
Some runtime sensors, like Falco, monitor syscalls through an eBPF probe or a kernel-module driver and match them against a rule set.
Others, like Tetragon, apply policy and filtering directly inside the kernel, attach to kernel functions beyond the syscall boundary, and enrich events with Kubernetes identities such as namespaces and pods.
Others, like Tracee, an eBPF-powered runtime detection and forensics tool, collect a broad set of kernel events and match them against behavioral signatures.
A scanner asks a database whether a component version has a published CVE. A runtime sensor asks the kernel which syscall a process just used, records its arguments, and ties the event to a pod. It's one of the few sources that can observe in-container process and kernel activity during an active intrusion, alongside network, identity, and cloud telemetry.
What it can't catch, and where posture still matters
Owning this layer honestly means owning its failure modes, because vendors mostly won't volunteer them in a demo.
Runtime detection and response limits
Most runtime tools alert after the behavior occurs, so response actions like killing a pod or isolating a node fire post-detection. Some in-kernel policy engines can block or kill a process before its syscall completes, but for most deployments this layer reports an attack underway after the first detected behavior.
The blind spots can be architectural, not hypothetical. An operation initiated through an interface like io_uring may not appear as the conventional syscall a rule expects, so coverage varies by sensor, hook point, kernel version, and rule set. Some products now detect suspicious io_uring use or add complementary file and kernel-security hooks.
So posture doesn't retire when runtime arrives. Image scanning alone leaves an opening for zero-days and CVE-less techniques, while runtime without scanning generates noise from findings teams could have fixed upstream. Both layers are required, and every image-layer fix is one less runtime alert for the SOC to triage during an incident.
Where container runtime fits next to the rest of the stack
Container runtime is one detection layer among several, and the ownership question decides whether its alerts get worked or ignored.
Image scanning, CNAPP, and general runtime, and who owns what
Whichever platform delivers the capability, including a cloud-native application protection platform (CNAPP), runtime visibility should integrate with security information and event management (SIEM), security orchestration, automation, and response (SOAR), and SOC workflows.
For a 24/7 response program, a console without durable alert routing, case management, and response workflows is usually insufficient.
A workable ownership model puts image scanning with AppSec and platform teams in the continuous integration and continuous delivery (CI/CD) pipeline, where it can block vulnerable builds, and runtime detection with the SOC, where analysts investigate and respond to active threats.
Platform or site-reliability teams often own agent deployment and first-line investigation, so the split depends on staffing and workflows.
If your CNAPP's runtime alerts route to the platform team's Slack channel and die there, you have a detection layer nobody operates.
This piece is about container runtime specifically. General runtime security also spans endpoints, cloud, and identity, and the full container lifecycle runs from base-image selection through registry hygiene to admission control, all of which sit outside this detection layer.
My own position after a decade of buying this stack: I put runtime detection on the SOC budget, and I ask every vendor to show me the syscall behind the alert before I sign. The scanner identifies exploitable conditions; kernel telemetry records active behavior. I need both, but only live detection generates the evidence to page my on-call during execution.
Frequently asked questions about container runtime security
What does container runtime security monitor?
Container runtime security is the detection layer that monitors containers while they execute: which processes run, which syscalls fire, which files get written, which network connections open. The detection typically runs on syscall and eBPF telemetry collected at the Linux kernel by tools like Falco, Tetragon, or Tracee.
Its job is catching active attack behavior during execution; vulnerability discovery belongs before deployment.
How is it different from image scanning?
Image scanning is static analysis before deployment: it builds an SBOM and matches components against CVE databases, but never executes code. Runtime security observes actual behavior in production, so it catches what scanning structurally can't, like escape attempts, dropped binaries, and exploitation of host-side flaws where the image itself is clean.
One identifies what could be vulnerable; the other identifies what is happening right now.
What attacks does container runtime security catch?
Four main categories. Container escape and privilege escalation, including suspicious access to /proc, namespace changes, or mounts in privileged containers. Processes that don't belong in the workload, including unexpected shells and administrative-command abuse. Drift from the original image, such as new binaries landing in the OverlayFS upperdir.
And cryptomining dropped post-compromise.
Known blind spots exist too, including activity that may bypass conventional syscall paths and fileless execution that creates no upper-layer file.
Do you still need image scanning if you have runtime security?
Yes. Runtime primarily detects behavior after it occurs, so every vulnerability you fix at the image layer is an intrusion path that never generates a runtime alert. Scanning also cuts runtime noise: fewer exploitable components means fewer behavioral alerts for the SOC to triage, and untuned runtime tooling can already produce substantial alert volume.