eBPF-based cybersecurity mechanisms: a systematic literature review

eBPF-based cybersecurity mechanisms: a systematic literature review. eBPF, which stands for Extended Berkeley Packet Filter, is a programmable framework for running security logic at kernel level. This 2026 article is by Stamatios Kostopoulos, Panagiotis Tsakonas, and Evangelos K. Markakis. It was published in the International Journal of Information Security. Earlier research was scattered across different security areas, evaluation methods, and deployment settings. This review identifies, categorizes, and synthesizes research on eBPF-based cybersecurity mechanisms.

eBPF programs can attach to events inside the operating-system kernel, close to system calls and network traffic. That placement lets a security control observe or act before data travels through a separate user-space monitoring pipeline. The reviewed work uses it for packet processing and system tracing. Other systems apply it to runtime workload protection and kernel integrity monitoring. It also supports intrusion detection and distributed denial-of-service mitigation. The attraction is fast observation and enforcement with fine-grained telemetry. The trade-off is that safety constraints designed to protect kernel stability also limit stateful analysis, deep packet inspection, and machine-learning logic inside the kernel.

The review’s problem is broader than whether eBPF can perform one isolated security task. It maps how eBPF has been used across cybersecurity, how those mechanisms were evaluated, what threat models and deployment assumptions they rely on, and what architectural limits recur. Fragmented methods and missing standardized benchmarks make results hard to compare. The useful distinction is between demonstrated measurements in particular settings and a broader claim that an eBPF design will transfer cleanly to another kernel, workload, or scale.

The authors used a structured literature-review process with formal inclusion and exclusion criteria. They screened 3735 records and retained 54 primary studies. They grouped the studies by their primary research objective. Broadly, the categories covered network defense, workload and connected-device security, and general security tooling. When a study crossed areas, it was assigned to the category that best matched its primary objective rather than every environment in which it was tested.

The synthesis found eBPF being used as both a sensor and an enforcement point. Systems collected kernel events and system-call traces. They also gathered network-flow data. Those inputs supported detection, observability, and policy enforcement. The reviewed results included kernel-level monitoring and real-time packet processing. They also included cloud-native workload protection with low reported overhead and high reported detection accuracy. The review also found a recurring architectural bargain: moving logic into the kernel can reduce latency and dependence on user-space pipelines, but the kernel’s safety limits reduce how complex that logic can become.

To put the performance claims in context, the median CPU overhead reported across the analyzed work was a few percent, while detection accuracy was reported in the mid-to-high nineties. Those measurements span different domains and conditions. Costs ranged from negligible for rarely used hooks to much higher on heavily exercised kernel paths, and the literature used heterogeneous evaluation methods without standardized benchmarking. These numbers summarize the reviewed studies; they should not be heard as a guaranteed performance envelope for a particular production system.

Several limits are operationally important. The first concerns implementation. Kernel safety rules restrict algorithm complexity, while kernel-version differences undermine portability. More than 85 percent of the reviewed studies required low-level programming expertise. The second concerns assurance. More than 96 percent did not address vulnerabilities in eBPF’s own verifier, compiler, or runtime. The third concerns evidence and deployment. Production validation and standardized evaluation remain research gaps. Isolation between tenants and machine-learning robustness under adversarial input also remain research gaps. Evaluated systems did not reach much larger production scales. Monitoring alone cannot prevent every kernel-level exploit without prohibitive overhead.

For detection engineers and cloud workload teams, the review supports a cautious deployment pattern: use eBPF where early kernel or packet visibility solves a defined problem, then measure it on the kernels and heavily exercised paths you actually run. Treat portability, safety limits, engineering skill, and self-protection as design requirements rather than late integration details. Security architects should also layer eBPF with other controls; the evidence does not support assuming that observation equals prevention, or that results from one workload will hold at a much larger scale. These are operational inferences from the measured variation and documented gaps, not a deployment recipe tested by the authors.

The contribution is a structured map that brings the recurring trade-offs and gaps in eBPF security research together. Security teams can use it to assess product claims. Reported low overhead and high accuracy suggest that eBPF can be useful in evaluated settings. They do not prove portable protection at production scale. Teams evaluating eBPF should test it in their own kernel and deployment environment, including the security of the eBPF subsystem itself.