Kubernetes Runtime Security: Beyond Image Scanning

Scanning your Docker images before deployment is necessary but insufficient. Critical Kubernetes CVEs in 2024-2025 demonstrate that the most dangerous attacks occur at runtime, when containers are executing. Here is how to secure your cluster beyond image scanning.

Recent CVEs: why runtime matters

CVE-2024-9042: command execution on Windows nodes

CVSS score 9.8. This vulnerability allows an attacker to execute arbitrary commands on Windows nodes of a Kubernetes cluster via the logging API. A simple unauthenticated API call is enough to achieve code execution as SYSTEM on the node. Affects Kubernetes 1.27-1.30 with Windows nodes.

CVE-2025-1767: escape via gitRepo volumes

gitRepo volumes allow a pod to clone a Git repository at startup. This CVE reveals that the repository content can be manipulated to access host node files by exploiting symbolic links. An attacker controlling a Git repository can escape the container and access the node's filesystem.

Both CVEs share a common trait: no image scan detects them. These are vulnerabilities in the orchestrator itself, exploitable only at runtime.

Build-time vs runtime: two different battles

• Build-time (image scanning): detects vulnerable packages in Docker images. Tools: Trivy, Grype, Snyk Container. Essential but insufficient

• Runtime: monitors what happens inside running containers. Detects abnormal behaviors: shell execution in a container, unexpected network access, sensitive file modifications, privilege escalation

Build-time security protects you against known vulnerabilities in your dependencies. Runtime security protects you against unknown vulnerabilities (zero-days) and malicious behaviors exploiting weak configurations.

eBPF: the kernel observability revolution

eBPF (extended Berkeley Packet Filter) allows running code in the Linux kernel without modifying it. For Kubernetes security, this means observability without significant overhead: system call tracing, network monitoring, abnormal behavior detection, all with less than 1% performance impact.

eBPF-based tools (Cilium Tetragon, Falco with eBPF driver) can detect in real time actions such as: /bin/bash execution in a production container, outbound connection to an unknown IP, /etc/shadow read, hostPath volume mount.

Falco: the de facto standard

Falco (CNCF graduated project) is the most deployed runtime detection engine. It monitors system calls and applies detection rules:

• Interactive shell in a production container

• Unexpected process (cryptominer, reverse shell)

• System file modification

• Suspicious network connections

• Kubernetes secret access

Falco generates alerts but does not block. For automated response, it must be integrated with a reaction tool or an agent like ThreatClaw.

Network Policies and Pod Security Standards

Network Policies

By default, all Kubernetes pods can communicate with each other. Network Policies restrict network traffic between pods, namespaces, and the outside world. It is the equivalent of a microsegmented firewall. Yet according to a Datadog study, fewer than 30% of production clusters use Network Policies.

Pod Security Standards

Pod Security Standards (Privileged, Baseline, Restricted) define three security levels for pods. The Restricted level forbids privileged containers, enforces a read-only filesystem, blocks privilege escalation, and requires a non-root user.

ThreatClaw: Trivy + Grype + runtime

ThreatClaw combines build-time and runtime security in its Kubernetes skills:

• Trivy: scanning images, Kubernetes configurations (IaC), licenses, and secrets

• Grype: vulnerability scanning with SBOM matching for coverage complementary to Trivy

• Configuration audit: verification of Network Policies, Pod Security Standards, RBAC, service accounts

• Runtime correlation: integration of Falco/Tetragon alerts with CTI context for enriched detection

FAQ

Trivy or Grype: which one to choose?

Both are excellent and open source. Trivy (Aqua Security) offers broader coverage (images, IaC, SBOM, secrets). Grype (Anchore) is faster for pure vulnerability scanning and has more granular package matching. Ideally, use both complementarily, which is what ThreatClaw does natively.

My cluster is small, do I need runtime security?

Yes. Cluster size is not the criterion. A small cluster exposed to the Internet with a compromised container can serve as an entry point to your internal network, mine cryptocurrency, or participate in a botnet. Runtime security is a minimal investment with high ROI.

Is eBPF supported on all clusters?

eBPF requires Linux kernel 4.14+ (ideally 5.x+). Managed Kubernetes distributions (EKS, GKE, AKS) all support eBPF. For on-premise clusters, check the kernel version. Windows nodes do not support eBPF.

How does ThreatClaw integrate with my CI/CD pipeline?

ThreatClaw can integrate into your CI/CD pipeline for build-time scanning (Trivy/Grype) and monitor runtime post-deployment. The agent correlates both: a vulnerability detected at build-time that is exploited at runtime triggers a maximum priority alert. Check our plans for details.