Bomfather secures runtimes and GPUs and uses eBPF to make the Linux kernel enforce your workflow. Our core product is runtime security, but our security can also be applied to GPUs with much better performance than confidential computing.
Bomfather restricts access to resources (GPUs, files, IPs, sockets, etc.) to ensure your workflow is not interrupted and that, if a component is compromised, it cannot bring down the whole system.
Runtime security is a very broad concept, but our ideology is to use anti-sandboxes (we made up the term “anti-sandboxes” for this, and we think it sounds pretty good rolling off the tongue). Instead of putting a lot of things in a sandbox, it locks down a few resources that matter, making them accessible only to programs that need them. We also have a blog post about this ideology, since it is a fundamental change in how to approach security: https://bomfather.dev/blog/sandboxing-isnt-the-solution/.
We know that security is useless unless it is actually used, and it is generally not used because it is a pain to set up and maintain, or because it adds too much overhead to a service and is deemed unnecessary. Bomfather was made to address these points.
Sandboxing is good, and there are many techniques for it: VMs, TEEs, containers, unikernels, etc. Most “runtime security solutions” aim to solve this same problem, but really, most people don’t want another sandbox, since in the real world, systems are made of multiple moving parts that all access each other. And when a sandbox becomes too fine-grained, its security breaks down. https://xkcd.com/2044/
But really, most of the time, there are only a couple of real resources that should not be tampered with: DBs, message queues, logs, GPUs, and KMSs. On each system, if a bad actor gets in, that is all we want to protect. And these resources are mostly only accessed by a couple of programs, a single api server, or a backend ingestor, nothing more.
So suddenly, this picture of security looks a whole lot clearer. We don’t need to always sandbox everything; we don’t need complicated guards around every single process on a machine.
All we need is a way to state that a resource can only be accessed by one executable, and 2 or 3 of those rules for the entire system, and that’s it, the entire security config can be 10 lines long.
We don’t want to break people’s workflows by adding an invasive security protocol, but we somehow need to catch every single file open, every single socket call, and all network traffic, while still being performant and running fully in the background. To solve all of this, we decided to use eBPF (https://en.wikipedia.org/wiki/EBPF)
With eBPF, we can monitor all events that occur on a system locally, and if a process tries to access a protected resource, we can block it, even if the process is an admin user (root). With this, we are able to deploy simple agents (not LLMs, but actual programs that run on a user’s machine) that secure the system from boot on production servers, allowing people to know for certain that if things go wrong, it could only be from the compromise of one of their allowed programs.
Since we can monitor every file open on the system, what if we created a system to identify threats before they can even attempt an attack? By breaking down these file opens over time, we can identify a pattern for how a specific machine works, which programs are on it, and which files they open. If we can figure out this pattern, we can detect deviations and, with that, detect anomalies when a malicious process opens a file.