Cisco is using eBPF to rethink firewalls, vulnerability mitigation

Networking giant Cisco purchased Isovalent in 2024 to get in on the cloud native action.

In our cloud native community, Isovalent was primarily known for Cilium, an Extended Berkeley Packet Filter (eBPF) overlay network that worked well for Kubernetes environments, namely by replacing IP tables with in-kernel traffic routing by eBPF.

The company also built Tetragon, a vulnerability mitigation platform that Cisco has already embedded into its own smart switch software.

Today, Cisco is one of the chief purveyors of network infrastructure, gear such as routers and switches, aimed primarily at enterprises.

“They liked what we were doing, and they saw value and continue to see value in the solutions that we have for the Kubernetes world,” says Liz Rice, Isovalent chief open source officer, in an interview with The New Stack. “Cisco has this enormous global footprint across traditional networking, so being able to bridge those two things together is really nice.”

Cisco runs its switches on Linux, which, like any software, has its share of vulnerabilities. Powering down a fleet of them just to apply a patch across each box isn’t ideal, however. Tetragon allows users to patch, or even upgrade, these switches while they continue to run.

These eBPF technologies “are incredibly foundational to where Cisco wants to go from an existing product perspective, but also from a future perspective,” says Thomas Graf, Isovalent chief technology officer and a co-creator of Cilium, also in the TNS interview.

“I think they’re learning that cloud native is not just Kubernetes, but a concept of how infrastructure will be done in general in the future, and that it will go beyond Kubernetes and containers,” Graf says.

eBPF provides a way to interject programmability directly into the Linux kernel, allowing the kernel to make decisions about incoming and outgoing traffic even before it gets to the application.

“With eBPF, we can attach miniature firewalls everywhere in the operating system or in the application code as well,” Graf says. “It’s a completely new era of firewalling that is not based on choke point firewalls that sit somewhere physically in the network.”

Faster patching

Today’s elaborate processes of vulnerability mitigation could change dramatically with eBPF, Graf says.

In today’s world, if there is a bug in your software that can be exploited by a malicious party, it must be patched.

This is “easier said than done,” Graf says, noting that most organizations have long lists of patches they need to apply, which are usually ranked by severity to set the priority of how quickly they should be applied. And if they run on dedicated hardware, such as an Internet of Things (IoT) device, the underlying operating systems will need patches as well.

eBPF can either mitigate the attack itself or drastically reduce the blast area by blocking the specific action that the malicious user wants to take with the faulty software. The user still must patch, but it is not as urgent, and malicious actions can be blocked by eBPF in the meantime.

Originally called the Berkeley Packet Filter, the technology originally served as an HTTP packet filter for the Berkeley Software Distribution (BSD). It has since been expanded into a virtual machine (VM) that can execute sandbox-secured code.

Since its inclusion in the Linux kernel a decade ago, the Linux-based eBPF has found widespread adoption, particularly for observability, security, and compliance tools that benefit from its programmable in-line speed to analyze and filter packets without the need for cumbersome modules or dangerous kernel modifications.

Cisco’s application

Cisco has integrated eBPF into its Hypershield technology, available in its Cisco Nexus 9300 Series Smart Switches. It addresses the changing patterns in data center traffic.

“Traditional security creates chokepoints. You route traffic through firewalls, IPS appliances, or virtual security functions. This made sense when your data center had clear boundaries and most traffic crossed them,” writes analyst Robb Boyd in a blog post. “But modern infrastructure doesn’t work that way anymore.”

For one, a lot of network traffic used to run north-south, meaning between the server and the outside world. Today, especially with AI traffic and distributed Kubernetes deployments, a lot of traffic goes east-west, or across an internal network.

Using eBPF, Hypershield adds visibility into each endpoint, such as VM Kubernetes pods, to get kernel-level visibility and control. “This agent sees everything: network packets, file operations, process behavior, system calls,” Boyd writes.

eBPF as control plane

The platform only hints at the possibilities down the road. One of Cisco’s goals with eBPF is to move away from centralized firewalls and towards distributed firewalls for each device and even each program.

Patching an entire fleet of switches means each one must be rebooted individually, which is an expensive operation, one that would preferably be done during a scheduled maintenance window. Perhaps the reboots could even be spread out so that no downtime would be incurred at all.

“You want to be able to pick your time of choice and not have the timeline be dictated by the vulnerability being disclosed,” Graf says.

In fact, this is one of the reasons that Facebook/Meta got involved in eBPF. That company runs thousands of Linux servers, and to patch them all at once during a time of a critical vulnerability would be nearly impossible.

“So they were very interested in essentially investing into eBPF to mitigate zero-day attacks where the entire Facebook server fleet was vulnerable,” he says.

All attacks leverage an interface that the OS provides, either an API call or a system call. Think of eBPF as a miniature firewall, one located in working memory that can filter out specific actions.

“eBPF can hook into all of these interfaces and to essentially be in the middle of whatever calls the interface and what uses the interface and can then filter out” any malicious activity, Graf says.

This would work not only for OSes, but for any application on the network as well. Think of the severe Nginx vulnerability unearthed last March (CVE-2025-1974). This vulnerability hit a lot of Kubernetes deployments, whose management teams had to figure out where they were using the Nginx software. An eBPF deployment within all the OSes could take care of the problem once: If you are running Nginx, apply this filter.

eBPF’s next frontier: The laptop

While eBPF may work to secure Linux servers, what about desktop computers?

The ongoing work on bringing eBPF to Microsoft Windows is nearly completed, Graf says.

This is an entirely new market for eBPF, he notes. Linux is dominant in the server market, but Windows rules the endpoint market for laptops, desktop computers, and small devices.

“I think now we can apply eBPF For security purposes, not just for the workload and server side, but also for your laptop,” Graf says.

eBPF excels at understanding programs as they run. It can operate at the operating system level, without damaging it, he says. He points to how eBPF is already being used in Google Android-powered devices. If you want to know how much network bandwidth Android is using, eBPF is behind that.

Developers running agents and models on their laptops will need to be protected, and here is where eBPF could come into play. Applications that run on your behalf, like AI agents, that do work under your user account need a new form of security.

Another challenge in the future will be connecting the identities of machines with those of users. Just because someone has your password shouldn’t mean that they should get access to your company’s network.

“It’s a network of agents and services that are connected together. So we have to carry the identity forward all the way to where you actually access the sensitive data,” Graf says.