About 18 minutes. That’s how long it takes for an AKS cluster to face its first attack attempt after it’s created. EKS clusters have even less breathing room, just 28 minutes from creation. Those are poignant findings from Wiz’s Kubernetes Security Report.
They also expose a mismatch, as today’s Kubernetes security protocols are often still built around the assumption that there’s time to notice a problem before it becomes an attack, and this data says there usually isn’t.
That mismatch matters most in how security teams choose their tools, since a platform built only to spot problems in advance can’t do much about a window that’s already closed.
Broadly speaking, tools take one of two approaches to finding problems: agentless platforms that scan an environment from the outside, and agent-based tools that watch what’s happening from inside a running system.
Many cyber pros still treat these as opposites, as if a platform has to choose one or the other. That split hasn’t kept up with the technology.
The gap between spotting a risk and catching an attack in progress is now all but gone. Wiz, for example, built its name on agentless posture visibility, scanning cloud environments and mapping risk without deploying a single agent.
It has since added real-time detection built on eBPF, a kernel-level technology that can catch an attack once a cluster is live and already under fire.
No human is finding your company and deciding to attack it in 18 minutes. It’s all automation. Bots are constantly scanning the internet for exposed endpoints, and your Kubernetes cluster just showed up on the list.
New clusters are easy targets for a few reasons. Default configurations ship with broad permissions and open dashboards. Unless the team actively locks them down before the cluster goes live, they stay wide open.
Service accounts are also often given more access than they need, either to make sure narrow access doesn’t break anything, or simply because it takes too much time.
With these realities, it’s no wonder attacks happen in minutes, and the only way to stop them is to monitor the cluster continuously, not check in on it once a week.
The extended Berkeley Packet Filter, or eBPF, hooks directly into the Linux kernel and can observe syscalls, process execution, network connections, and file access as they happen in real time.
It does all of this without touching the application code itself.
In contrast to this approach, pre-deployment static scanning looks at a container before it runs, checking what’s packaged inside it against known vulnerabilities.
But a clean result at that stage doesn’t mean much, because it doesn’t tell you what’s actually loaded into memory once a container is running.
The container may spawn an unwanted process, or open connections to somewhere it shouldn’t that could jeopardize the entire cluster.
The only way to catch this is runtime visibility, which is what eBPF provides.
When talking about static scanning, it’s important to understand its limitations. Way too many security teams rely on it to solve everything. In-memory exploitation is a clear example.
These types of attacks are only visible while the code is executing in memory. There’s no file sitting in the image for a static scan to flag.
Living-off-the-land binaries create a similar problem. These are legitimate, pre-installed tools such as curl, bash, or a package manager, that already exist inside a container image because the application genuinely needs them.
The static scan won’t flag them as malicious, but an attacker can certainly abuse them.
One of the ways they can abuse these binaries is for lateral movement. One compromised pod can use trusted binaries to reach out to another pod, but that traffic won’t be visible unless real-time monitoring is in place.
Several tools now operate on this kernel-level model, giving continuous visibility into what a container is doing in real time. Falco, Tetragon, Cilium, and Wiz Sensor all use eBPF to watch that activity.
Wiz Sensor is worth calling out specifically, since it connects that same kernel-level visibility to identity, exposure, and data context that most standalone runtime tools don’t have on their own.
It’s an opt-in, agent-based add-on to Wiz Defend, deployed directly onto nodes to get the kernel-level visibility that agentless scanning can’t provide on its own.
Once it’s running, Wiz Sensor validates vulnerabilities against what’s loaded into memory, not just what’s installed on disk.
A package can sit in an image flagged as vulnerable but never actually load into a running process. Wiz Sensor is what tells you the difference between a theoretical risk and one that’s live.
It’s important to note that eBPF is Linux-specific. It hooks into the Linux kernel, which means it only works on Linux nodes.
A Kubernetes cluster running Windows nodes requires a different solution, creating a real problem for environments that run hybrid clusters.
That’s precisely what pushed Wiz to release its Runtime Sensor for Windows this past June, extending the same runtime detection model to Windows nodes using telemetry built for that environment.
This tool uses a lightweight kernel module that hooks into Windows security APIs and forwards activity data to user space, where the actual detection logic runs.
It brings the same real-time visibility eBPF provides on Linux, without needing eBPF itself.
Both sensors report into the same platform, giving a hybrid cluster one consistent risk picture that’s easy for defenders to look at.
There are a few main things to look at when evaluating a runtime tool.
Detection latency should be a top priority. If it takes a tool hours to fire an alert, it’s not much better than a periodic scan.
The whole value of runtime detection comes from speed. Good runtime tools operate in seconds, not minutes, let alone hours.
Node-type coverage across Linux, Windows, and hybrid environments is also important. You want a single tool that can cover all of them, reporting into one platform instead of leaving Windows nodes as an afterthought or a separate product entirely.
Integration with existing CNAPP tooling also deserves attention. Runtime detection doesn’t replace agentless scanning, it builds on it, and the strongest CNAPP platforms treat the two as a single connected capability rather than separate products.
The two should feed off each other to provide a full risk view.
A scan tells a team what could theoretically go wrong. A runtime sensor confirms what’s happening on a live system right now. Security teams that operate with both have the advantage during a live attack.
A cluster that’s attacked within minutes of creation can’t be protected by a strategy that only checks in once a day.
That’s why the gap between agentless visibility and real-time detection was inevitably going to close, and now it has.
Agentless scanning still matters. It’s the fastest way to map what’s exposed before anything runs.
But once a cluster is live, only a runtime sensor can answer what’s really going on inside it.
Microsoft has pushed out an emergency, out-of-band Windows 11 update after its September Patch Tuesday…
CDR is the runtime, real-time half of cloud security: while CSPM tells you what’s misconfigured,…
Your SaaS estate M365, Salesforce, Workday, Slack, hundreds of others is a sprawl of misconfigurations,…
DSPM finds sensitive data you didn’t know you had, classifies it, maps who can reach…
Open-source packages are meant to save developers time. In the GemStuffer campaign, that trust became…
Google has released an important Chrome 153 security update that fixes 42 vulnerabilities across the…