Cloud-native security has spent a decade shifting left, and rightly so: signed images, scanned dependencies, and strict admission control stop an enormous amount of harm before a workload ever starts. But every one of those controls goes quiet the instant a container begins executing. The moment code runs, the questions change from what is allowed to what is actually happening, and answering them inside a shared Kubernetes cluster has historically been slow, noisy, and blind to the kernel. eBPF, the extended Berkeley Packet Filter, is the technology that closed that gap, and in 2026 it is the foundation of serious runtime security on Linux.
eBPF lets safe, sandboxed programs run inside the Linux kernel, attached to system calls, kernel functions, and network events, without patching the kernel or loading a risky module. For runtime security that is transformative: you can observe every process execution, file access, and outbound connection from every pod on a node, with low overhead and no code changes to the applications themselves. For a security operations team in Tunis monitoring clusters for EU customers under NIS2 and DORA, that combination of deep visibility and modest cost is exactly what makes round-the-clock, nearshore detection commercially viable. This article explains how the technology works, how the leading tools differ, and how to deploy it without drowning in alerts.
Why image scanning and admission control stop at runtime
Static controls answer a question about the past: was this image, at build time, free of known-bad things. Runtime is a different universe.
- ▸Zero-days and logic abuse leave no signature: a vulnerability disclosed after your scan, or an attacker abusing legitimate functionality, is invisible to image scanning by definition.
- ▸Compromise happens in memory: a reverse shell spawned from a web server, a crypto-miner launched by an exploited dependency, or credentials read from a mounted secret never touch the image on disk.
- ▸Drift is inevitable: long-running pods accumulate changes, and lateral movement between pods in a shared cluster is precisely the behavior static controls cannot see.
- ▸Compliance now expects it: NIS2 and DORA both emphasize detection and response, not just prevention, so an audit trail of runtime activity has moved from nice-to-have to expected.
How eBPF changed the detection game
Before eBPF, deep runtime visibility meant either a kernel module, which could crash the host, or a userspace agent that saw only a shallow slice of activity and was easy to evade. eBPF removed that false choice. Programs are verified by the kernel before they load, guaranteeing they cannot loop forever or read arbitrary memory, then run at native speed attached to exactly the events you care about. Because the instrumentation lives in the kernel, it sees every process on the node regardless of language, runtime, or how the container was built, and an attacker inside a container cannot easily hide from a sensor that lives beneath them.
Falco, Tetragon, and the syscall-versus-LSM debate
Two open-source projects dominate the conversation, and they embody different philosophies.
- ▸Falco: a CNCF-graduated project that consumes kernel events, increasingly via a modern eBPF probe, and matches them against a readable rule language. Its strength is a large community ruleset and a mature alerting ecosystem, making it the fastest path to meaningful detections.
- ▸Tetragon: part of the Cilium project, it leans on eBPF and Linux Security Module hooks not only to observe but to enforce, killing a process synchronously in the kernel when a rule matches, before the action completes.
- ▸The syscall question: pure syscall tracing is comprehensive but can be noisy and, in some designs, subject to time-of-check to time-of-use evasion. LSM-based hooks observe at the point the kernel makes a security decision, which is harder to bypass but covers a narrower set of events.
- ▸The practical answer: many mature teams run both patterns, using rich syscall-level detection for investigation and LSM-based enforcement for a small set of non-negotiable actions such as blocking execution of an unexpected binary.
Mapping detections to MITRE ATT&CK and OpenTelemetry
Raw kernel events are worthless without a framework to make them meaningful. The MITRE ATT&CK matrix for containers is the common vocabulary: a shell spawned inside a container maps to execution, reading a service-account token maps to credential access, and an unexpected outbound connection maps to command and control. Structuring rules around ATT&CK techniques turns a flood of events into a small number of high-signal, explainable detections that an analyst can act on.
Equally important is where the telemetry goes. In 2026 the sane pattern is to emit runtime security events as structured data through OpenTelemetry pipelines alongside logs, metrics, and traces, so detections live in the same observability fabric as everything else. That unification matters enormously for lean teams: a nearshore security operations centre in Tunisia serving several EU clients cannot afford a separate, bespoke tool for every signal type. Feeding eBPF detections into a shared, standards-based pipeline keeps cost down while preserving the data residency and tenant segregation each client's GDPR posture requires.
A numbered rollout checklist
1. Deploy sensors in observe-only mode: run the eBPF agent as a DaemonSet across every node, alerting only, so you learn normal behavior before enforcing anything. 2. Establish a baseline: spend real calendar time cataloging which processes, file paths, and network destinations are legitimate for each workload class. 3. Tune the default ruleset hard: out-of-the-box rules are generic, so suppress the expected noise aggressively or analysts will stop reading alerts within a week. 4. Map surviving rules to ATT&CK: label every enabled detection with its technique so triage and reporting share one meaning. 5. Route events through OpenTelemetry: centralize into your existing observability and SIEM stack rather than a siloed console. 6. Introduce enforcement narrowly: enable synchronous blocking only for a handful of unambiguous actions, and only after the detection has proven quiet. 7. Rehearse response: write and drill the runbook for the top techniques, because a detection nobody responds to is theater. 8. Review continuously: revisit rules as workloads change, treating detection content as living code under version control.
What to do this quarter
Install an eBPF runtime sensor on a non-production cluster this week and simply watch, because the baseline you gather is worth more than any vendor demo. Wire its output into whatever log pipeline you already run, avoiding a new silo. Pick the five ATT&CK techniques that would hurt you most, a container shell, credential-file access, a new listening socket, an unexpected outbound connection, and package-manager execution at runtime, then make sure you have a clean, tuned detection for each. Resist enabling in-kernel enforcement until your detections are quiet and your team trusts them, because a false block in production erodes confidence faster than any missed alert.
Outlook
Runtime security is converging with the rest of the platform. Expect eBPF sensors to feed the same signed-provenance and admission systems that gate deployment, closing the loop so that a workload's runtime behavior can revoke the trust its image was granted at admission. As eBPF enforcement matures, the boundary between detection and prevention will keep blurring, pushing more response logic safely into the kernel. For engineering and security teams across Tunisia and North Africa, this is a rare moment of leverage: the tooling is open source, the skills are learnable, and the ability to run deep, standards-aligned runtime detection at nearshore cost is precisely what European clients under NIS2 and DORA are now required to buy. The teams that master the kernel view in 2026 will own a durable advantage.