Patch CVEs in minutes

No. A WAF is a proxy or an edge service that terminates TLS and ships managed rulesets. The yeet programmable firewall adds no hop and terminates nothing: it runs on the host, behind your TLS termination, and reads the decoded request in the kernel. Keep your WAF. This covers the origin behind it.

No. Your NGFW decides on the network path with the vendor's signatures. The yeet programmable firewall decides on the origin host with rules the yeet agent writes and your team reviews, so the time between a CVE and a matching rule is a review, not a vendor cycle. They run side by side.

Yes. From the network in, a rule drops everything that reaches a host or a container except traffic from the sources you trust, live in the same 3 to 6 ms, so you can reach the box and fix it while everyone else is held off. Outbound containment, holding what the host sends, uses the kernel's egress hook, which the runtime attaches the same way. It is next on the roadmap; inbound is what ships today.

Per host, per interface, per port, per container or per pod, from the same program. By default it attaches in the host's network namespace, where every container's traffic crosses an interface the host owns, so pod-to-pod traffic on the same node and anything arriving from outside are covered with no sidecar and no change to the pod spec. A rule reads the destination port, the protocol and the interface, so it can narrow itself to one service. For one container or one pod, the runtime attaches inside that container's network namespace or on its cgroup, and the agent resolves a container name or a pod label to the namespaces and cgroups on each node. Overlay networks are matched at the pod's interface, after decapsulation.

XDP sees bytes as they come off the NIC. If those bytes are TLS records there is nothing to match, so the yeet programmable firewall runs where traffic is already cleartext: origin servers behind an edge, a load balancer or a sidecar that terminates TLS. The TLS client hello is the exception, since the server name travels in the clear.

A specialized network security agent that is bound by yeet's ISA. It reads the CISA KEV feed, drafts a rule for each CVE that touches software you run, tests it against a reproduction of the exploit, and opens a pull request with the C, the assembly and the bytes. Your reviewer approves. Nobody on your team needs to know how to write a firewall rule, and our engineers work with you on the first rules and rollout.

A program that cannot read a packet passes it, unless you chose fail-closed for that rule. Run a new rule in monitor mode first and watch the histogram, then switch it to enforce. Unapply clears the program and drains the flow table.

No. The matcher is one XDP program, checked by the Linux verifier when it loads. Rules are data it interprets inside fixed budgets, so a rule cannot crash the kernel, loop forever or read past the packet.

Linux 6.12 or later on the origin hosts, cleartext traffic at the NIC (TLS terminated upstream), and the yeet runtime, installed via a package from your distribution's package manager, a container image, a Terraform provider or a one-line installer, as a Kubernetes DaemonSet or a systemd service. It runs on VMs or bare metal in any cloud that is in production on enterprise traffic, and updates ride your normal image rebuild.

A vendor signature is written on the vendor's schedule, in the vendor's format, and lands at the edge. Here the rule is a program the yeet agent writes from the CVE's own indicators, reviewed in a pull request, then compiled on each origin host and matching at XDP seconds after the merge. The two are not exclusive. Keep the edge signature; the host rule covers the hours before it ships and the east-west traffic the edge never sees.