eBPF Sensors and the 18-Minute Kubernetes Attack Window

Any platform lead who has ever spun up a fresh AKS cluster on a Friday afternoon knows the tension: you haven't finished writing the NetworkPolicy and the bots are already knocking. Eighteen minutes. That's the median grace period before an AKS cluster gets its first attack probe, according to a Wiz report. EKS gets a slightly more generous 28. Both numbers are shorter than most on-call handovers.

The Numbers

Eighteen minutes is not enough time to do anything a human normally does. It's not enough time to review a Terraform plan properly. It's not enough time for a Slack thread about whether the dashboard should be exposed. It's certainly not enough time for the weekly vulnerability scan to run, produce a PDF, and get triaged by the security team.

As CyberSecurityNews reported, the 18-minute AKS and 28-minute EKS windows come from Wiz's own Kubernetes Security Report, and the ten-minute gap between the two managed services is almost certainly noise from bot scan patterns rather than any real defensive advantage in EKS. Treat both as roughly the same problem: your cluster is on the target list before your CI pipeline finishes the first deploy.

Put that in operational terms. If you run a 10-person platform team and you're rotating an on-call engineer through Kubernetes provisioning, you now need automated hardening baked into the cluster bootstrap, because a human reviewer cannot beat a bot to the punch. That is a real budget line. In production incidents I've seen at fintech shops running managed Kubernetes, the "we'll harden it after the demo" cluster is exactly the one that ends up mining Monero by Monday morning.

The other number worth pulling out: good runtime tools operate in seconds for detection latency. Compare that to the 18-minute attack clock and the math is obvious. You cannot outrun automated attackers with human-driven review cycles. You have to compress detection into the same order of magnitude as the attackers' automation, which is single-digit seconds.

Default Kubernetes ships with broad permissions, open dashboards, and service accounts wired up with more access than they need. That combination, plus a public IP, is what makes those 18-minute numbers reproducible rather than anecdotal. Bots don't need a zero-day when the front door is unlatched.

What's Actually New

eBPF itself isn't new. The extended Berkeley Packet Filter has been hooking into the Linux kernel for years, and Falco, Tetragon, and Cilium have been shipping runtime detection built on it for most of that time. What's changed is that the agentless posture crowd has now folded eBPF into their platforms rather than treating it as a competing category.

Wiz built its reputation on scanning cloud environments without deploying agents. Adding Wiz Sensor as an opt-in, agent-based add-on to Wiz Defend is a real architectural admission: you cannot see in-memory exploitation from outside the node. Static scanning checks what's packaged in the container image against known CVEs. It tells you nothing about what's actually loaded into memory once the container is running. A vulnerable package that never gets imported is theoretical. A benign-looking binary that gets abused for lateral movement is live.

The Wiz Sensor validates vulnerabilities against what's loaded into memory, not just what's on disk. That's the genuinely useful engineering claim, because it collapses the noisy CVE queue that every security team drowns in. Half of what your SBOM scanner flags is code that never executes. Confirming reachability at runtime is how you stop paying two engineers to chase phantom findings.

The other new-ish piece: the Wiz Runtime Sensor for Windows, released in June, uses a lightweight kernel module that hooks into Windows security APIs and forwards activity data to user space where detection logic runs. Both Linux and Windows sensors report into the same platform. For anyone running hybrid clusters (and there are more of those in enterprise iGaming and legacy fintech than vendors like to admit) that unified telemetry pipeline is the actual differentiator, not the eBPF branding.

My take: the story here isn't "eBPF is cool." eBPF has been cool since 2018. The story is that the agentless vendors have quietly conceded runtime needs an agent, and they're racing to bolt one on before the pure-play runtime tools eat their expansion revenue.

What's Priced In for Security Teams

If you've been paying attention to Kubernetes security for the last three years, most of this is already in your threat model. You already know default configurations are dangerous. You already know service accounts are over-permissioned because narrow scopes break things and nobody has time to debug RBAC on a Tuesday. You already know living-off-the-land binaries like curl, bash, and package managers can't be scanned away, because your application legitimately needs them. Teams I've worked with on payments infrastructure have been mapping this to MITRE ATT&CK techniques for containers for years.

What's not priced in, and this is where I see teams still getting caught, is the operational cost of the eBPF agent itself. eBPF is Linux-specific. It only works on Linux nodes. That means every Windows node, every managed service that abstracts the node away, every serverless container runtime that doesn't give you kernel access, is a coverage gap. Your dashboard will show green while entire slices of your fleet are unmonitored.

The uncomfortable read: most teams buy runtime detection, deploy it on the Linux worker pools they control, and quietly ignore the fact that their Windows nodes, their Fargate tasks, and their GKE Autopilot workloads sit outside the sensor's reach. The Windows sensor release closes one of those gaps. The others remain.

Contrarian View

Here's the argument I'd push back on: that adding an eBPF agent to every node is obviously the right answer. It isn't obviously anything. Kernel-level agents have a history of causing outages that dwarf the incidents they were meant to prevent. Anyone who lived through a certain July 2024 morning knows what happens when a kernel module misbehaves at scale.

eBPF is safer than a raw kernel module because it runs in a verified sandbox, but "safer" is not "safe." Every additional hook into syscalls, process execution, and network paths is CPU you're spending on observation rather than serving requests. On high-throughput workloads, that overhead is real, and I've seen teams roll back runtime sensors after benchmarking showed a measurable latency tax on p99.

The contrarian position: for a lot of workloads, hardening the cluster at provisioning time (locked-down RBAC, no public dashboards, admission controllers, image signing) buys you more security per dollar than adding a runtime sensor on top of a badly configured cluster. Runtime detection is what you add after the basics are done, not instead of them.

Key Takeaways

• The 18-minute AKS and 28-minute EKS attack windows mean cluster hardening has to be automated at provisioning, not reviewed by humans afterward.
• Static image scanning cannot see in-memory exploitation or living-off-the-land abuse of curl, bash, and package managers. Runtime visibility is the only way to catch those.
• eBPF-based sensors (Falco, Tetragon, Cilium, Wiz Sensor) close the Linux runtime gap, but eBPF is Linux-only. Windows nodes need a separate kernel module approach.
• Validating vulnerabilities against what's loaded in memory (rather than what's on disk) is the single most useful feature for cutting CVE queue noise. Prioritize tools that do this.
• Before adding a kernel-level agent to every node, lock down defaults, tighten service accounts, and close open dashboards. Runtime detection is a layer on top of good hygiene, not a replacement for it.