eBPF Visibility Tools Are Built for Performance, Not Protection
Using eBPF observability tools as security monitors is a category error. These tools are engineered for one purpose: to run safely in production while you diagnose a live performance issue. That means keeping overhead as low as possible, and low overhead often means accepting blind spots that are unacceptable in a security product.
Consider tcpdump(8). Under load it will drop packets rather than keep up, which is fine for a quick packet capture but disastrous for security monitoring: an attacker can flood the network with benign traffic to push malicious packets out of the capture window. One old audited system approach was to halt the kernel if a log write ever failed, guaranteeing complete logs but at the cost of trivial denial of service. That is a different design philosophy with a different tradeoff.
Observability tools have known evasion vectors that have existed for decades. top(1) samples the process list and relies on the comm field, which can be spoofed. Even ls(1) can be fooled by escape characters in file names. These are not bugs awaiting a fix; they reflect the intended use. The bcc and bpftrace tools inherit similar weaknesses: they can be overwhelmed with events, are susceptible to time-of-check-time-of-use (TOCTOU) attacks, and can be evaded with technique such as escape characters.
Adding security hardening to these tools runs counter to their reason for existing. Extra probes and filters to close evasion windows add overhead. Making the tracing logic more robust means moving from stable tracepoints to deeper, more fragile kernel internals, which hurts maintainability. If someone set out to build a dedicated security monitor on eBPF, they would design it differently from the start: use LSM hooks, implement a plugin architecture rather than standalone CLI tools, make drop behavior configurable via policy, and optimize event logging — a gap that still exists in bcc today.
Experienced security engineers already know all this. The writing below is aimed at the ones who see a working bpftrace one-liner and think a few lines of shell scripting could turn it into a security product. That impression is understandable, but the gap is large. If you are building a security monitoring product, the most useful investment is hiring a security engineer with solid penetration-testing experience.
eBPF itself is not the problem. The kernel runtime is designed as a secure sandbox, and eBPF's low overhead makes it an attractive base for security monitoring. And the privilege question is moot: running these tools already requires root.
Early Work Points the Way
The idea of BPF for security monitoring was explored in a 2017 BSidesSF talk by Brendan Gregg, together with Netflix security engineer Alex Maestretti.
The talk laid out the visibility eBPF can provide, but the real story is the overhead evaluation from that work. Measurements of bcc/eBPF showed it to be far more efficient than either auditd or go-audit. That early collaboration unfortunately stayed as slides: the contributors left Netflix before the code was ever open sourced.
Since then other eBPF-based security projects have appeared, including open source options like Cilium's tetragon. Which one to choose is not a question the author can answer with confidence, given the number of projects now in the space.
The distinction matters because the eBPF ecosystem is often described as a single toolkit. It isn't. The observability tools are built to answer "what is happening right now?" with minimal interference. A security monitor must answer "did something happen that I need to know about?" with completeness and resistance to evasion. Those are different requirements, and a tool designed for one should not be expected to float when dropped into the other.
