Three open-source EDR projects worth a look: Rustinel, Fibratus, owLSM

Three open-source endpoint detection projects are circulating among defenders this month, each covering a different corner of the fleet: Rustinel, Fibratus and owLSM. None require a vendor contract, and all three are free to self-host and inspect.

What each one covers

Rustinel is a cross-platform agent for Windows, Linux and macOS. It reads the telemetry each operating system already exposes -- ETW on Windows, eBPF and Endpoint Security on Linux and macOS -- normalizes it, and evaluates Sigma rules, YARA signatures and IOC lists against it. Alerts are written as local ECS NDJSON files that feed into Elastic, Splunk or any existing log pipeline; nothing is sent to a vendor cloud. It ships under the Apache 2.0 license.

Fibratus is Windows-only and built on ETW kernel telemetry. It pairs a behavior-driven rule engine with a YARA memory scanner that inspects freshly created process images, and it supports Python-based "filaments" for teams that want to write their own detections on top of the raw event stream.

owLSM, from Cybereason's public research arm, takes a different approach: it runs Sigma-style rules inside the Linux kernel itself using eBPF LSM hooks, aiming at blocking malicious activity in real time rather than just logging it after the fact. It is not a lab experiment -- Cybereason says it is already deployed across customer environments at Cybereason and LevelBlue.

Where these fit an MSP stack

None of the three is a wholesale replacement for a commercial EDR. Rustinel's own documentation is explicit about the gap: no kernel self-protection, no anti-tamper, so a privileged attacker can simply stop it. Fibratus needs administrator or SYSTEM rights to read ETW and is best treated as a detection-engineering and forensics tool rather than a hardened production sensor. owLSM is the furthest along toward production use, but its prevention rules still need to be tuned per environment, and Sigma rules written for log-based detection do not port over automatically -- fields and IDs have to be adapted to owLSM's format.

For an MSP evaluating any of the three, the practical questions are the same: does the platform coverage match the fleet you actually run, does the rule format overlap with what your SOC already maintains, and are you deploying it for detection engineering and pilot coverage or production blocking. Treat all three as an addition to existing tooling, not a swap-out, until you have run them against your own environment.

Sources: Rustinel (GitHub), Fibratus, owLSM (GitHub).