Why I built procscope instead of just using Tracee or Falco

Mutasem Kharma — Fri, 17 Apr 2026 14:17:54 +0000

If you work in cloud security, you are probably exhausted by the acronym soup of eBPF tools. From Sysdig's Falco to Aqua's Tracee and Isovalent's Tetragon, the market is flooded with "Kernel-Level Observability" daemons.

So why on earth did I write procscope?

Because enterprise EDRs are built for fleets, not for incident responders.

The Signal-to-Noise Problem

When I get paged because a suspicious container is running a slightly strange binary, I don't want to deploy a massive DaemonSet across my cluster, configure 30 YAML policy files, and then try to grep through 10,000 JSON logs to find the single /etc/shadow file access.

I just want to know what the binary is doing right now.

If I use strace -p, any cleverly written malware instantly detects the ptrace system call and goes silent (or worse, bombs the host).

Enter procscope

procscope was designed to be the tactical sniper rifle of eBPF, not the shotgun.

It is a single, statically compiled binary. You don't configure policies. You don't deploy an agent. You literally just pass it the command you want to trace like this:

sudo procscope -- ./sketchy_installer.sh

Under the hood, `procscope` injects kprobes and tracepoints into the kernel, but filters events **at the kernel-level** so it *only* evaluates events originating from that specific PID tree.

Tetragon monitors the entire host. `procscope` monitors the blast radius.

## What you see in real time

The timeline spit out on your terminal contains:
- 🌐 Every IP address and port the binary beaconed out to
- 🗂️ Every file it touched, read, or deleted
- 🔐 Every privilege escalation attempt (`setuid`/`chown`)
- ☸️ The Kubernetes Pod and Namespace it belongs to (v1.1.0+)

**Zero noise. Zero host-wide overhead.**

## Try it right now — in your browser

No installation required. We built a [free interactive sandbox on Killercoda](https://killercoda.com/mutasem04/scenario/procscope-scenario) where you can trace a fake reverse-shell payload in under 60 seconds.

[![Try it in the Browser](https://img.shields.io/badge/Try_in_Browser-Killercoda-23C13F?style=for-the-badge&logoColor=white)](https://killercoda.com/mutasem04/scenario/procscope-scenario)

## Getting it

bash

Linux amd64 — single binary, no dependencies

curl -sL https://github.com/Mutasem-mk4/procscope/releases/download/v1.1.0/procscope_1.1.0_linux_amd64.tar.gz | tar -xz
sudo mv procscope /usr/local/bin/

Star it on GitHub: github.com/Mutasem-mk4/procscope

If you are an incident responder or malware reverse engineer tired of deploying massive agents just to trace a single shell script — this tool is for you.

Once you’ve pasted that, click that blue Publish button at the bottom left. 🚀

Then, hit me with that Playtika session token so we can start the BOLA hunt!

Building a Zero-Overhead Linux Runtime Investigator with eBPF and Go

Mutasem Kharma — Fri, 17 Apr 2026 12:06:35 +0000

When it comes to Linux observability and security, traditional tools like top, ps, and standard audit daemons have a fundamental flaw: they lie. Or more accurately, they only tell you what the system wants you to see. Advanced rootkits, fleeting container processes, and malicious scripts can easily evade user-space monitoring.

The solution? We have to go deeper. We have to go to the Kernel itself.

In this post, I'll walk you through why I built Procscope—a blazing-fast, process-scoped runtime investigator written in Go and powered by the absolute superpower of modern Linux: eBPF.

The Problem with User-Space Observability
Standard monitoring tools periodically poll the /proc filesystem to see what's running. This introduces two massive problems:

Performance Overhead: Polling wastes CPU cycles.
Blind Spots: If a malicious script starts, executes its payload, and dies between your polling intervals, you will never even know it happened.
To solve this, modern security agents use eBPF (Extended Berkeley Packet Filter).

Enter eBPF: The Kernel's Superpower
eBPF allows us to run sandboxed programs directly inside the Linux kernel without changing kernel source code or loading unstable kernel modules. It is event-driven. Instead of asking the kernel "what's happening?" every second, we attach scripts to specific kernel events (like a file being opened or a network connection being made). When the event happens, our script fires instantly.

It is the technology powering the next generation of cloud-native tools like Cilium, Tracee, Falco, and now, Procscope.

How Procscope Works
I wanted to build an open-source tool that DevOps and Platform Engineers could drop onto a Linux box to instantly trace application behavior with near-zero overhead.

Procscope intercepts syscalls at the lowest possible level and bridges them up to a beautifully structured Go user-space application. Here is the architecture:

eBPF C Code: Tiny, highly optimized C programs attach to tracepoints (like sys_enter_execve).
Ring Buffers: When an event fires, the C program pushes the kernel data (Process ID, Comm name, arguments) into a high-performance eBPF Ring Buffer.
Go User-Space: The main application, written in Golang using the excellent Cilium eBPF library, consumes these ring buffers in real-time and formats them for the user.
A Look at the Code
Writing eBPF requires bridging two worlds. Here is a simplified look at how Procscope catches a process execution.

First, the eBPF Kernel probe (written in C):

c
SEC("tracepoint/syscalls/sys_enter_execve")
int tracepoint_syscalls_sys_enter_execve(struct trace_event_raw_sys_enter* ctx) {
struct event_t event = {};

// Get the Process ID and Thread ID
u64 id = bpf_get_current_pid_tgid();
event.pid = id >> 32;
// Get the process command name (e.g. "bash", "curl")
bpf_get_current_comm(&event.comm, sizeof(event.comm));
// Submit the event to our Go application
bpf_ringbuf_submit(&events, &event, 0);
return 0;

}
Then, the Go application seamlessly consumes it:

go
// Start reading from the eBPF ring buffer
rd, err := ringbuf.NewReader(bpfObjs.Events)
if err != nil {
log.Fatalf("failed to create ringbuf reader: %v", err)
}
for {
record, err := rd.Read()
if err != nil {
log.Printf("ringbuf read error: %v", err)
continue
}
// Unmarshal the byte array directly into our Go struct!
var event bpfEvent
binary.Read(bytes.NewBuffer(record.RawSample), binary.LittleEndian, &event)

fmt.Printf("🚨 New Process Detected | PID: %d | Comm: %s\n", event.Pid, string(event.Comm[:]))

}
Because we use Go's generate tools, compiling this application automatically compiles the C code into eBPF bytecode and embeds it directly into the final Go binary. The result is a single, static binary that you can drop onto any modern Linux server. No dependencies needed.

Why Build This?
While heavyweight enterprise agents exist, I wanted to create an open-source, lightweight alternative that is easy to compile, easy to read, and laser-focused on process scoping. Right now, it's perfect for incident response, malware analysis on a honeypot, or simply figuring out why a rogue container keeps crashing.

What's Next (and How You Can Help)
The project is entirely open-source, and I'd love to invite the community to help shape it! We are currently working on adding Kubernetes Pod Context Resolution so that intercepted PIDs can be automatically mapped to their respective Pods and Namespaces.

I've opened up several Good First Issues specifically designed for developers wanting to dip their toes into Go and eBPF observability.

If this sounds interesting to you: 🌟 Check out Procscope on GitHub and drop a Star! 🌟

Have you worked with eBPF before? Let me know your thoughts or questions about kernel tracing in the comments below!

DEV Community: Mutasem Kharma

Why I built procscope instead of just using Tracee or Falco

The Signal-to-Noise Problem

Enter procscope

Linux amd64 — single binary, no dependencies

Building a Zero-Overhead Linux Runtime Investigator with eBPF and Go