AI
The Blast Radius: What Happens After Code Execution on a Pod
An attacker who gains code execution on a Kubernetes pod has two moves. The first is container escape: reach the node, grab the kubelet config and secrets, and the cluster is compromised. The second is lateral movement. By default, Kubernetes has no network segmentation, so a foothold in one pod gives access to any other pod across namespaces. Both paths lead to the same outcome. This talk frames every technique around shrinking what Schendel calls the blast radius.
Filtering the SBOM by What Actually Runs
The average application container carries about 100 vulnerabilities. But most packages installed in an image never load into memory. A Python web server might have 70-80 packages installed but use only half. Kubescape’s relevant vulnerability feature uses eBPF to record which files each container opens at runtime, filters the SBOM to that set, then cross-references against Grype to surface only what can actually be exploited. In Schendel’s production systems this cut the total vulnerability count by 80%.
Why Function-Level Vulnerability Filtering Backfires
Some tools filter further, to the function level: only flag a CVE if the vulnerable function was actually called. Schendel calls this a mistake on three counts. Fewer than 1% of CVEs identify which function is vulnerable, so the approach doesn’t scale. eBPF recording only observes the first few minutes of container startup, missing code paths triggered by unusual input. A server that processes only Word documents during testing might process PDFs in production, calling a different function entirely. Patches also ship at the package level, not the function level.
Seccomp Profiles and Network Policies from Observed Behavior
Kubescape’s eBPF agent monitors system calls and network connections alongside file activity. System call traces produce per-workload seccomp profiles. Schendel tested recent container escape CVEs and found that a seccomp profile in place blocks their exploitation. Network traces produce network policies that prevent lateral movement between pods that shouldn’t talk. Both apply as Kubernetes CRDs and integrate with Cilium and Calico. Manually writing seccomp profiles is effectively impossible since no developer knows which syscalls their application uses. Generating from behavior solves that.
Wiring Policy Generation into CI/CD
The CI/CD workflow runs in a test namespace: deploy Kubescape as a DaemonSet, start eBPF recording, deploy the app, run the full test suite, stop recording, generate seccomp profiles and network policies, apply them, rerun tests to confirm nothing broke, then commit policy files to git. Recording runs in parallel with tests, adding no extra wall time. The main caveat: incomplete test coverage produces overly restrictive policies that break in production. Schendel found this forced his team to write better integration tests, which he frames as a side benefit.
Q&A
Can teams review and tune generated policies before applying them? Yes. Policies are Kubernetes CRDs manageable like any other resource, and teams can add or remove system calls. Policies can also be pre-baked in a dev environment and applied directly to production, skipping the learning period there. ▶ Watch (27:20)
Does this have to run on every commit, or can it run per release? Schendel recommends running it at release time: complete all testing, generate updated policies, and commit them before the production push. ▶ Watch (28:26)
Does policy generation slow down the test pipeline? No. Kubescape’s eBPF DaemonSet learns in the background while tests run, so generation is parallel with the test suite and adds no wall time. ▶ Watch (29:24)
Notable Quotes
everything so it’s basically game over Amit Schendel · ▶ Watch (2:37)
this is actually kind of a mistake Amit Schendel · ▶ Watch (6:44)
look at you he won’t understand what Amit Schendel · ▶ Watch (12:08)
Key Takeaways
- Filtering the SBOM by files actually loaded at runtime cut vulnerabilities by 80% in production.
- Function-level vulnerability filtering is less safe than package-level because recording windows miss later code paths.
- Seccomp profiles generated from syscall traces blocked exploitation of recent container escape CVEs.
- Network policies generated from eBPF-observed connections prevent lateral movement with no manual policy authoring.
- Running the full generate-apply-retest loop at release time adds no wall time since recording is parallel with tests.
About the Speaker(s)
Amit Schendel is a Senior Security Researcher at ARMO, the company behind Kubescape. His work spans security research and low-level programming, with a focus on kernel drivers for both Windows and Linux. He writes in C++, Python, and Go, and concentrates on problems at the intersection of cybersecurity, system-level development, and cloud technologies.