Abstract

Container breakout vulnerabilities continue to surface in widely deployed runtimes, and detection lags behind exploitation by a wide margin. Seccomp (Secure Computing Mode) profiles offer a kernel-level syscall filtering mechanism that both hardens containers and generates high-fidelity signals for runtime detection. When combined with audit-mode logging and a structured analysis pipeline, seccomp becomes a practical detection layer rather than a purely preventive one.

Why Syscall Filtering Matters

Containers share the host kernel. Any container process making a syscall goes through the same kernel as every other workload on that node. Breakout techniques - whether via CVEs in runc, containerd, or the kernel itself - almost always rely on syscalls that benign application workloads never invoke: unshare, ptrace, mount, keyctl, and others. A tightly scoped seccomp profile shrinks the exploitable surface to the syscalls the application actually needs.

The challenge is profile generation. Manually crafting allow-lists for complex microservices is tedious and error-prone. Tools like oci-seccomp-bpf-hook (from the containers project) and Inspektor Gadget’s trace syscalls gadget automate profile generation by tracing actual runtime behavior across staging workloads. Profiles produced this way typically allow 60-80 syscalls rather than the 300-plus available by default.

Running in Audit Mode for Detection

Seccomp’s SCMP_ACT_LOG action records syscall violations without blocking them. Deploying profiles in audit mode on production clusters lets security teams collect violation events through the kernel audit subsystem and forward them via auditd or a syslog pipeline into a SIEM. Any container generating a seccomp audit record for a syscall outside its expected profile is a candidate for investigation.

The signal-to-noise ratio is high because legitimate workloads almost never violate a well-tuned profile. An alert on unshare or mount from a web-application container carries essentially no false positives. Compare this to network-based detections, which require baselining and threshold tuning for every service.

Integration with Runtime Security Platforms

Seccomp audit events integrate naturally with eBPF-based runtime security tools. Falco supports ingesting kernel audit records alongside its own eBPF probes, and a rule matching seccomp violation + subsequent ptrace syscall from the same container process is a strong breakout indicator. Tetragon (from Cilium) can enforce and observe at the BPF layer independently, providing a complementary data source.

For Kubernetes operators, the Seccomp Operator (kubernetes-sigs project) manages profile deployment as a CRD, tying profile versions to pod specs and logging profile application events - making auditability straightforward and enabling automated remediation workflows when violations occur.

Operational Considerations

Introducing seccomp profiles to an existing fleet requires a staged rollout: audit mode first, then enforcement after a quiet period of at least one week per service. The most common operational failure is blocking a syscall that appears only in an uncommon code path - graceful degradation matters. Maintaining profiles as code alongside Dockerfiles and Helm charts, reviewed in CI with tools like oci-seccomp-bpf-hook in trace mode against integration tests, reduces drift and keeps profiles accurate as application code evolves.