Show HN: Jibril – Runtime security monitoring and enforcement for modern infra (garnet.ai)
Jibril introduces an event-less architecture leveraging eBPF to maintain lightweight state maps directly within the kernel. Instead of buffering events, it queries kernel state directly, enabling real-time detection and enforcement with minimal overhead. This approach is especially effective for protecting ephemeral and cloud-native infrastructure against emerging threats that exploit low-level system behaviors.
The new sensor architecture delivers unique benefits: - Simple deployment with out-of-the-box coverage: deploy instantly in any Linux environment using a single binary—no sidecars, kernel modules, or application code changes required. Integrates seamlessly into existing stacks with minimal dev/ops overhead and includes a comprehensive set of MITRE-mapped runtime detections. - Real-time in-kernel detection & enforcement: enforce behavioural policies directly within the kernel in real-time. Features include live kernel-state querying, freezing suspicious processes, detailed process ancestry, and source-level context. - Lightweight footprint: engineered specifically for modern environments, jibril operates with negligible CPU and memory overhead (typically <5%), ensuring performant visibility and response without the perf impact.
This enables modern platform and engineering teams to achieve runtime detection and response at scale, enabling use cases and answering questions such as: - What network calls were made during my GitHub Actions test workflow, and what dependency triggered them? - How can I restrict the python3 process from reading /proc/[pid]/mem to block memory dump attacks in my runner (as seen in the recent tj-actions supply chain attack)? - How can I automatically block malicious DNS resolutions within K8s pods and automatically update cluster firewall rules using managed blocklists (e.g., known cryptomining pools and C2 servers)?
You can try it out for free today at https://jibril.garnet.ai/usage/installation. We’re looking forward to your feedback, questions, and suggestions on what we can improve on and build next!
13 comments
[ 2.6 ms ] story [ 48.0 ms ] threadWith 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!
I long for a production-ready runtime monitoring tool that can ACTUALLY be used in a blocking mode. Otherwise we’re always too late, and I’ve been burned more than once when dealing with an incident. Damned hackers always seem to come around weekends and holidays.
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).