// the find
exein-io/pulsar
A modular and blazing fast runtime security tool for the IoT, powered by eBPF.
Pulsar is an eBPF-based runtime security agent for Linux (aimed at IoT devices) that watches process, file I/O, and network activity in the kernel and matches events against a custom rule DSL to flag threats. It's for people building device security/intrusion-detection into embedded Linux products, not a general-purpose EDR.
The module system is real, not just marketing: process-monitor, file-system-monitor, network-monitor, rules-engine, and notifiers are separate crates, and there are working examples for embedding Pulsar as a library, writing extension modules, or running standalone probes. The rule engine (validatron + lalrpop DSL) compiles conditions against typed event payloads instead of just string-matching TOML fields, so rules like the sensitive-symlink example are actually structured and type-checked. They've clearly eaten the pain of eBPF portability: separate vmlinux.h per arch (x86_64/aarch64/riscv64) plus compat shims for kernel struct drift (iov_iter_compat.h, kernfs_node_compat.h) instead of pretending one header works everywhere. CI is split into build/quality/integration/audit/release workflows, including cargo audit for dependency CVEs.
Dual licensing (GPL-2.0 for the eBPF probes, Apache-2.0 for userspace) is exactly the kind of thing that kills adoption at IoT vendors who want to bundle this into closed firmware - that's a real obstacle for the audience the project claims to target. The README explicitly says 'we do not recommend building from source,' which is a strange thing to tell people evaluating a security tool meant to run with root/admin privileges on their devices - you want that path to be easy, not discouraged. Requiring kernel 5.5+ with BTF rules out a lot of actual shipping IoT hardware, which tends to run old vendor forks for years; the IoT framing and the kernel requirement are in tension. At ~1k stars this is still a single-vendor (Exein) project with limited outside scrutiny for something asking for root-level kernel visibility, and there's no visible fuzzing or rule-testing framework to validate custom rules before they run against production traffic.