BSidesCharm 2026 - The Case for MicroVMs: Container-Like Agility with the Security of VMs

Hi everyone, my name is Caitlyn. Thank you for being here. Uh oh. Oh, my laptop went asleep. Okay. Okay, great. Um, today I'm talking about virtual machines and containers and how virt micro virtual machines are sort of the best of both worlds. Um, okay. So, a little bit about me. Oh, and why am I speaking about this? Uh, so my name is Caitlyn Sang. I started off my career at the John's Hopkins Applied Physics Lab. uh working in a research group that did um defensive cyber security research and specifically I focused on cloud security. Um I worked there for a bit and then I went to go to a startup in the Maple Lawn area called Unveil and we

worked on private information retrieval. Um and now I'm currently working at a small startup called Ginger Cyber Security and we are creating um a secure um minimal operating system to run on microVMs. And as part of my work at my current role, I'm trying to stay very current on the um on the landscape of virtualization and containerization. And so I wanted to share that all with you today. Um so I just wanted to do a quick show of hands. Uh how many of you are already familiar with the concept of a microVM? Okay. So some people and is anybody already using microVMs in your workflow or in your day-to-day uh work? Okay. [gasps] All right. Sounds good. So let's

talk about it today. Um so I'm going to start by talking about a brief history of virtualization and containerization. And I'm going to focus on some of the threat vectors of what we're uh concerned about or what we're trying to address. And then I'm going to talk about some of the benefits of microVMs. Okay. So now we're going way back to the 1960s and 1970s when the main computing technology was a mainframe. So there were these big large expensive >> [snorts] >> um mainframes and the goal with that was to make it more efficient for people to time share. And so that was when the first concept of virtual machines uh came about. At the time it wasn't called

virtual machines necessarily. It was a program called CP uh in CMS. The CP stood for control program which was essentially the very first hypervisor. Um CMS was it changed names a couple times. The Cambridge console or conversational monitor system. Um and so the control program acted as uh what we now call a hypervisor. Uh fun fact, the name hypervisor came um because uh what they considered a supervisor was the guest um operating system kernel. That was the supervisor and they needed something to supervise those supervisors. And so that's how the t the term hypervisor was for something that's supervising the supervisors. Um okay. And so we called this a type one hypervisor. This is where you have

the control program or the hypervisor directly installed on the hardware. Um, and as a side note, around the same time, we also saw some container-l like primitives being um integrated into the Unix kernel. Uh, uh, CH root or change routt was a utility that would allow the apparent file system to be changed for a running process. um developers who were working on the Unix kernel at the time used it to um uh sort of develop and iterate on the kernel without messing up their operating system that they were operating on. Okay, so for a bit there was some slow and steady progress but things really took off in the 1990s and the 2000s. Um, at this time, um, personal workstations

were a little more common at this point and developers wanted a way to change operating systems without powering down their system. And so, um, we came up with type two hypervisors where maybe you already have a host operating system running on your system and you want to install a hypervisor, uh, on there as well to run your virtual machines without powering down your main uh, desktop. And so here we saw innovations such as VMware introducing VMware Workstation which was a pri proprietary solution um shortly after Virtual Box which was released which was an open-source solution. Um the QMU team made the first stable release. Um in addition we also saw Intel and AMD integrating uh hardware virtualization

support to make virtualization faster on your desktop. Um okay and then now we're talking back again about type one hypervisors. Um the industry was standard standardizing on x86 hardware moving away from proprietary riskbased architecture. Um VMware took some of the im innovations that they made for the type two hypervisors and introduced them in their type 1 hypervisor uh ESX which could run bare metal. We saw Zen 1.0 was released and KVM was merged into mainline kernel which allowed some of the virtualization support from directly within the kernel. Um okay and then we saw another leap in innovation with uh containers in the 2000s 2010s uh time period. Um the goal here was to sort of isolate processes

and have reproducible environments for development and deployment. You could sort of create your container locally and then deploy the exact same thing on on the cloud. Um so what sort of enabled this leap in innovation was um namespaces and screen cgroups were merged into the Linux kernel. Um this allowed you to um uh categor um group together processes that were running uh logically and then name spaces allowed you to isolate what those processes saw in the context of the the wider system. Um the very first iteration of a container sort of tying all those technologies together was Linux containers um LXC but they were a little bit bulky to use and they didn't fully take off. Uh however in 2013 Docker was

released uh which sort of simplified the container experience. They introduced things like a image registry where you could easily download the images. Um they had a very simple command line tool for running containers. You could just say docker up or docker run. Uh and then shortly after only a year after Docker was released, Kubernetes was released and that gave you the orchestration piece where you could sort of control all your containers uh sort all at once and manage them that way. Um and I love this graph here. Uh let's see. So this is a graph of Google search trends uh over time. And you know, I know it's not an exact um replica of how many

downloads were happening at that time, but it just shows developer interest. Uh so the blue line is searching for VMware, the red line is searching for Virtual Box, and the yellow line that really takes off there is um searches for Docker and the green line after that is containers. Um and this was a really uh wild time for me. At the time I was on a team that was contributing to OpenStack uh which is primarily built on um the infrastructure for running virtual machines as a cloud service and um right around the time Docker and Kubernetes were being released and growing in popularity. Uh we would go to these OpenStack summits and people were talking about oh Kubernetes is the next

big thing. So I really feel like I I lived this whole sort of transition here. Um so why did they take off so quickly? My take is that we had already built up this infrastructure around VMs and orchestrating them. Um and then container containers came along and showed that you could do it so much more quickly. You could download things quickly, launch them quickly. Um the containerized applications more were quicker to start than booting a virtual machine and you could pack so many containers all in the hardware all at one time. Uh but what about uh security? Are there any security implications here? Well uh actually yes. part of the reason why containers um are so popular

such as their speed and their small image format have sort of um a little bit of security risks involved in them and I'll go more into the architecture of why that is. Um so here we're going to talk a little bit about container escape which is one of the main reasons why uh people talk about why containers are less secure than virtual machines. Um so here we have some containers running on their container runtime such as Docker. We have the host operating system and then we have all that running on some hardware. Now the thing about containers about why they are able to boot so quickly uh is because they are sharing the host kernel. So in in that container

image it's not a full operating system. They're sharing all the containers are making sys calls and interacting with the host kernel directly which is why the images can be so small is because they're not they don't contain the whole operating system. um why they can start up so quickly is because you don't have to wait for the whole OS to boot. It's just like your sort your one simple process and um we'll go from there. So here we're going to focus on app A. Say we're responsible for keeping app A um secure and um say for example a different app running on our same host app B is subject to a cyber attack. Uh that's bad

news for them. But what does that mean for us? uh over here in AB A. Um and so we're going to look at some CVE numbers real quick. Uh because all of those containers are sharing the host um kernel system, uh we're um we're looking at the CVEes for those for the kernel. Now there in 2025, for example, we saw between like 5,000 and 6,000 kernel CVES reported. Uh there's sort of a rest a rough estimate that maybe 30 to 40% were either high or critical severity. Um and it seemed like there were reports that seven were seen exploited in the wild. Um so not only are we concerned about that container um the kernel that

everyone is sharing, but we're also concerned about uh the container runtime. And so we saw around like five or more container runtime CVEs uh reported explicitly. So now not every single CVE means that there's a container escape. I'm just trying to illustrate that there's sort of a large attack surface there and there's more opportunity more potential there for something to happen. Uh and so once an attacker escapes uh that one container all of the rest of the containers are at risk. Uh so how about a VM escape? Can the same thing happen there? So let's say again we are responsible for app A. concerned about app a but um a different app running on your host is uh in a

different VM is compromised. Um so yes I will admit that VM escapes do happen in 2025 we did see a critical trio of CVS that could be chained together affecting VMware. Um but that in general that hypervisor space is much um the attack service is much smaller. uh there's much less code going onto the hypervisor um that makes up the hypervisor as compared to the whole Linux kernel. Um and then also if there's an attacker trying to escape out of the VM, they have to escape all of that hardware hardware virtualization emulation to get out of the uh uh virtual machine. Um and so that was you know talking about container escape, virtual machine escape escape. Here are

some other threat vectors we may want to consider. Uh there can be image or supply chain attacks like if your container image or your VM image that you're downloading is at risk. Uh orchestrator attacks if you're using extra software to manage all of your containers that is also a whole another attack surface. um side channel attacks where uh maybe the attacker is not accessing your system directly but they can sort of um um predict the memory that's going to happen in your virtual machine and exploit uh your isolated uh virtual machine in that way. Uh also additionally there can be application layer attacks either in code that you've written yourself or in libraries that you're pulling in like we see that sort

of thing happen with log for shell where everyone was using log forj and uh attackers were able to access the shell through that threat vector. Um so given all these threat vectors you know we've seen the growth of virtual machines and containers. What is sort of the next trend? uh uh the trend that I'm seeing is generally these um technologies are focusing on reducing that attack surface and there's um different companies out there trying to solve these problems for containers. Uh we're seeing companies trying to provide base container images that have been audited for CVEEs beforehand, distrulus container images that only run exactly your application and its dependencies and not much else. Um, we see solutions

that are trying to intercept SIS calls to the kernel and additionally we see solutions where you're trying to wrap that container in a VM and just sort of launching it that way. Um, but let's go back to our virtual machine uh use case. You know, the Linux kernel has been around for a long time. Hardware has advanced significantly since uh Linux was first around. So maybe even if virtual machines were slower to start, maybe we can strip out a lot of that functionality and make our virtual machines much smaller and make them just as lightweight and as speedy as a container. Um, additionally, I don't mean to make this an AI talk, but it feels a little bit like the elephant in

the room. Um, I'm seeing people want to sandbox their AI agents on their desktops as their AI agents are pulling in all of these random dependencies and we want to try to control that and make sure that they aren't pulling anything too risky. Um, I also see a need where AI attackers are automating their attacks with AI. Um, and that speed of CV announcement to attacks in the wild is becoming shorter and shorter. And so as defenders we need to sort of reduce our attack space as much as possible. Um so thinking again about these virtual machines. Uh in the previous slide I mentioned a few different solutions for containers but um layering containers with virtual machines. Well, let's think

about deploying our applications directly on very lightweight, very small uh microVMs instead of uh layering our containers around with virtual machines. So, adding a new era to my timeline of virtualization and containerization uh microVMs. So, I am not the person who coined the term microvms. I believe AWS has that honor. they released um firecracker in this time period. Uh they had a use case where they wanted to run user submitted code in their lambda jobs and um containers didn't provide the amount of isolation that they needed. So they turned to microVMs to to run user submitted um Lambda jobs. And they've open sourced this since then. Uh so because um here I'll go on to my next slide. So

what exactly is a microVM? Well, there's not exactly one specific definition. Uh in general, it's a lightweight virtual machine. So I spent so much time talking about the architecture of VMs and containers. It's the same architecture just stripped down a lot smaller. Uh virtual machines uh microVMs are purpose-built for a specific task. Um, that's how we can take the traditional virtual machine architecture and make it just as lightweight as a container by stripping down everything that we don't need. Uh, so we can achieve this. We can generally achieve some combination of faster boot times, smaller images, stripped down kernel. Um, we can even drastically reduce the number of files in your default file system. um emulate

only the necessary devices. Uh there's fewer you can have a fewer number of processes running on your system. Um so we talked earlier about type one and type two hypervisors. Uh microVMs can run in either situation, but because of their stripped down and purpose-built nature, you're probably going to do either one or the other. So your sandbox that you're going to run your AI in may not be the same microVM that you're deploying your server applications to the cloud in. Okay. So let's see how does this impact our security of our uh virtual machines. Um so microVMs have the same security properties of general purpose VMs that we're talking about before as far as um

the isolation goes uh plus more because if we've stripped down the hypervisor to remove all the unnecessary um functionality there are fewer lines of code which would lead to hopefully fewer CVEes if you've stripped down the kernel and removed all of the legacy devices and the leg legacy drivers that you don't need for your purpose. Um, that kernel can boot a lot faster. Um, if you have a smaller number of files in your file system because you're only running exactly the app that you want to run, you can um measure and audit your system a little bit more accurately. Uh, you can attest that only certain things are running on your system uh at a given time.

Uh, so in summary, I don't mean to hate on containers. there's a time and place for every technology. I really feel if you really trust your code and you really trust your architecture, maybe containers are still the right solution for you. Uh you can still run containers very densely. uh microVMs. However, if you have any other sort of security concerns such as the isolation um and needing to remove any sort of the extra functionality, uh microVMs will improve on that boundary compared to containers and they may still operate just as speedily and lightweight um in the same sort of realm as containers uh because of that guest kernel isolation. Okay, so that uh concludes my talk. Um,

I have a uh I'm out at a booth for Ginger Cyber Security, my company, out in the lobby if you want to talk about our operating system and how we're using microVMs. Um, and so I guess now at this time I can take some questions. [applause]

[applause] >> Okay. Yes. >> Being containers, but get started fig. >> Yes, a very good question. So the question was how to get started building microVMs for like a simple Python app for example. Um there's a few different technologies now. It sort of depends on your purpose like if you're deploying this app um in the cloud. Uh I'm a little bit partial to our own operating system that has its own tool chain but there's also firecracker. Firecracker has really great documentation. Um, I believe Firecracker claims that it can generally run any uh Linux-based operating system, but they do offer their own operating system uh image that is very paired down as well to help solve that space.

>> Yeah, that is the tool and it's open source and um or yes. So, okay.

Okay. Oh yes.

>> Oh, okay. So, the question was, have we done any testing on hostbased security systems such as EDR? Is that correct? Um,

Yes. Uh the short answer is I personally have not done that. That would be an interesting experiment. Uh at least for how we're deploying them at St. Ginger Cyber Security. we um have uh made a bet on sort of our own lockdown system of making our system immutable and making the files uh read only where they need to be. Um but that would be interesting to try to run an experiment such as that I think. So okay. Okay. Well, I don't see any more questions. So, um, thank you so much [applause]