Jibril is a cutting-edge runtime monitoring and threat detection engine, designed to deliver real-time insights with minimal impact on system performance. Powered by eBPF, it remains efficient even under heavy event loads exceeding hundreds of thousands of events per second–delivering real-time protection for modern environments from dev to prod. Jibril's query-driven eBPF approach, unlike traditional event-streaming models, collects kernel behavioral data with minimal overhead, eliminating performance bottlenecks while maintaining monitoring integrity.
Jibril (https://jibril.garnet.ai/) is a free runtime monitoring and threat detection tool for Linux, designed for development, CI/CD, and production environments. It captures system activity - processes, files, network connections, users - with high precision and low overhead, processing hundreds of thousands of events per second. Installation takes under 5 minutes, and it integrates with GitHub Actions for CI/CD or Kubernetes for cluster monitoring.
## Introduction
Jibril delivers real-time visibility into system behavior, detecting threats like unauthorized executions, file tampering, or network anomalies. Its modular design, driven by a centralized configuration file, balances flexibility and performance, scaling from single systems to enterprise deployments. It provides comprehensive telemetry with tamper-evident logs, ensuring reliable security insights.
## Features
- *Attenuator*: Filters security events using private & public LLM models in order to reduce false-positives noise. Analyzes events for context, like process ancestry or executable paths, and deduplicates repetitive alerts. Useful for prioritizing alerts in automated pipelines.
- *Alchemies*: Custom detection rules framework. Users can create "detection recipes" to define specific monitoring conditions, e.g., file access patterns or network activity. Includes built-in recipes and supports enabling/disabling rules on-demand for tailored security.
- *Cache Configurations*: Manages memory for event storage. Users set cache sizes via config files to handle large event volumes, preventing performance degradation in high-load environments.
- *Cadence Configurations*: Controls timing of operations, like event polling or cache updates. Adjusts frequency to balance responsiveness and resource usage, ensuring efficient monitoring in real-time.
- *Network Policies*: Enables blocking of network connections based on domains or IP CIDRs. Provides a complete view of remote peers per process, linking detections to corresponding peers with full DNS resolution paths. Groups all processes communicating with the same remote node and flags detections for each entry.
- *High Event Load Handling*: Processes hundreds of thousands of events per second with minimal performance impact, leveraging eBPF’s efficiency and a so called 3rd-generation EDR architecture.
Take a look at https://jibril.garnet.ai/readme/theory-behind so you have a better understanding what we are doing. As long as there is 'a resource' and 'an action', we can track it. Full memory (file-backed or not) introspection is tricky due to performance reasons (like checksumming files, picking entire content being read/write to pages, etc). Still, we would be able to do if we wanted (specially considering we can add uprobes on-demand for binaries being executed). Hope that helps.
I agree it’s risky and, IMO, it would be as good as the policy that drives it. Same happens with seccomp, lsm hooks (bpf or apparmor:selinux:smack:tomoyo), nft or netfilter, or any other policy driven mechanism.
Now, the enforcement feature, will never be unanimous (although runtime tools try to provide it). Of course there are straight forward cases like never execute a binary from procfs, or never allow x vídeos.com (that is a no brain automatic enforcement for almost everyone, let’s put this way).
It also depends on what kind of enforcement we talk: we apply synchronous network policies and dynamic ones after DNS answers for example (and that is enforced if the policy says so). This is an action (to something currently going on), different than a re-action (which happens after something has already happened but allows me to enforce a cluster policy, for example). We have synchronous actions (like our network policy update, and, soon, execution and file access policies) and mitigation reactions (try to kill, pause, introspect, etc) jittered from original trigger (search the whole tetragone discussion).
In our case we have actions for the network policy, actions for detections (in some detection methods), reactions to detection events and integration with external tools as detections occur.
To your answer: yes you will be able to define the actions, reactions and drive enforcement for reactions (3rd party integrations for example). For now we are only distributing the network policy and we are about to include more (we just need good feedback on things people want and use cases). We will also be providing soon a way for users to create their detection recipes (but we will probably have a big list of recipes made for the biggest use cases so users don’t have to worry).
Thanks for asking, I do agree with your concern (and I think most of sec people also share the same concern on that).
Thanks for the detailed reply! I see custom policy/assertions on kernel behavior as powerful. As a current osquery user managing a fleet of 10k+ hosts (mostly Linux boxes) I find the query model resonates in terms of ux. We have a set of SQL pipelines that run on top of it at my org. osq works well for monitoring but not detections. So this direction is interesting, I'll forward to my detection eng folks
I'm looking forward to talking them. Let them know we have a free of charge partnering program right now (where they can be design partners for the tool, get integrations and features that attend their needs and support). This is meant for medium/big sized companies with specific needs so we can better shape the tool. Ping me if you have any doubts. Cheers!
Hello everyone! I'm Rafael David Tinoco, the lead developer behind Jibril Runtime Security at Garnet Labs. I'm thrilled to share this exciting journey with you as we launch Jibril, a next-generation runtime security tool designed to revolutionize how we approach Linux security monitoring.
With over 22 years in IT, my career has spanned across industry leaders like AquaSec, Canonical, IBM, Linaro, RedHat, and Sun Microsystems. I've contributed as a core developer to projects such as Tracee (eBPF) and Ubuntu, always driven by my passion for open-source software, kernel development, and security introspection.
I'm passionate about combining deep technical knowledge with innovative approaches to security, and Jibril represents exactly that—a powerful, adaptable solution for modern runtime security challenges.
Feel free to connect, ask questions, or discuss anything related to Runtime Security. I'm excited to engage with the community and continue pushing the boundaries of runtime security together!
Let's secure the future, one kernel at a time!
Rafael Tinoco
Jibril Runtime Security @ Garnet Labs
Jibril, help us!
1. Feature isn't public yet, but currently we're able to block ingress/egress by IP + MASK and/or DOMAIN resolutions (meaning blocking the resolution itself, or anything that is resolved from or to example.com, synchronously while the resolution happens). This would be given as a setting (yaml?) to our CI action to be configured by the end user. L7 firewall is in our roadmap.
2. Leo is former falco creator (sysdig), I'm former tracee core developer (aqua). For CI/CD, performance isn't usually a concern, unless the "sidecar" is consuming all runner resources and causing latencies/jitterings/false-positives in functional tests (saying this because your comment about bad experiences with side cars, or eBPF agents).
3. I don't want to FUD but argus is currently consuming less than 10% resources when compared with other eBPF security tools around, with the same workload, and it does not miss events (not a single one don't matter what you do, without causing latencies to your code). Argus has a complete different architecture. You don't even need an userland agent running if that is mandatory (although it improves some available data). Userland code basically aggregates and report, almost no resource consumption.
4. Although argus performs so well, we're targeting it for CI/CD now, until something changes (never know), but all its infrastructure is ready for staging and production environments (same info and detection events).
5. About the threat model:
- Everything is a resource (namespace, user, group, task, socket, network flow, file).
- Resources suffer actions (different depending on the resource, files actions are heavily influenced by VFS operations like unlink, read, write, mmap, for example).
- All resources can be stored for further analysis (historical deduplicated data of all actions that have ever happened to each resource).
- Detections are built on top of this model: events are deduplicated and generated (or re-generated) only if the resource data has changed (like another action was taken on it).
Example: process opens a file that triggers a detection (under certain conditions). A detection event is generated with an unique deduplicated id. The process exits and know the "task" resource has a new info (exittime), so the event is sent again with updated info (but same unique key).
Putting all this together, our detections vary among Evasion, Brute Force, Credentials, Discovery, Drift, Escalation, Execution, Exfiltration, Lateral Move, Mining, Persistence, Tamper OS, Tamper Kernel, Tamper Argus, App Hooking, Kernel Hooking, Denial-of-Service, Offensive Tool, Informational. We're not mapping 1:1 with MITRE but some of our labels are a mix of couple (or sometimes 3) of MITRE classes.
Thanks for the detailed reply! The arch and perf gains sound compelling.
It might be a bit early for benchmarks, but I'd be curious to see how argus compares vis-à-vis other ebpf-based introspection tools at scale, in terms of stability and coverage... Probably makes for a good blog post for some day.
About short lived, or dynamically generated, steps: yes (or it is a bug if it can't). About tasks duration: it does not matter if a task existed for 1 ms or 10 mins, we catch what we need/want (with almost no overhead, at all).
About differentiating behaviors, we are going to provide more details in documentation very soon.
Jibril is a cutting-edge runtime monitoring and threat detection engine, designed to deliver real-time insights with minimal impact on system performance. Powered by eBPF, it remains efficient even under heavy event loads exceeding hundreds of thousands of events per second–delivering real-time protection for modern environments from dev to prod. Jibril's query-driven eBPF approach, unlike traditional event-streaming models, collects kernel behavioral data with minimal overhead, eliminating performance bottlenecks while maintaining monitoring integrity.
## Read more:
The 3rd Generation EDR with in-depth context: - https://jibril.garnet.ai/jibril/readme/new-era
Why Jibril out performs other runtime engines: - https://jibril.garnet.ai/jibril/readme/theory-behind
## Give it a try:
Command Line - https://jibril.garnet.ai/jibril/installation/command-line
Systemd service - https://jibril.garnet.ai/jibril/installation/systemd-service
Docker Container - https://jibril.garnet.ai/jibril/installation/docker-containe...
Kubernetes - https://jibril.garnet.ai/jibril/installation/kubernetes
## Features
Create your own detection recipes (Alchemies) using YAML - https://jibril.garnet.ai/jibril/components/alchemies/create-...
Reduce false positives using The Attenuator (powered by AI) - https://jibril.garnet.ai/jibril/components/attenuator
Block network using the network policy - https://jibril.garnet.ai/jibril/components/network-policy
## Repositories
Find our public repositories - https://jibril.garnet.ai/jibril/installation/repositories
Unmarshal detection events using the public types package - https://github.com/garnet-org/jibril-ashkaal
Find & Share public detection recipes - https://github.com/garnet-org/jibril-wahy