The version you're actually running

Every chapter so far has been about architecture: which model you are in, what a container is made of, where the second wall goes, how to match the tier to the threat. Architecture is durable. It is also not what you are running.

What you are running is a build. A specific commit of a specific VMM, chosen by whoever packaged the product you adopted, frozen at whatever moment they last thought about it. The ladder tells you which rung you are on. It does not tell you whether the rung has been repaired since it cracked.

The gap nobody puts on the box

A June 2026 comparative study measured five sandbox products across six axes, and its headline finding was not about architecture at all. Upstream engines patch fast: under coordinated disclosure, the fix is typically ready the day the bug is announced, so engine-side latency rounds to zero. The lag is downstream, in the products that ship those engines. Across five products the study found downstream lag ranging from zero days, to 471 days, to "opaque", to never.

That range is wider than the gap between tiers. It can be wider than the gap between models. A hardware boundary running a VMM with a known escape-class bug in it is not the boundary the tier promises, and no amount of picking the right rung fixes that.

The two worked examples in that study are worth sitting with, because they are both microVM products, both on the strongest rung of the ladder:

• E2B pinned Firecracker at v1.14.1 in April 2025 and had not bumped it 399 days later. When CVE-2026-5747 landed, an out-of-bounds write in virtio-pci rated 8.7, the upstream fix shipped and the pin did not move for another 44 days. Newer builds sat in the project's own version registry the whole time; the orchestrator default simply did not consume them.
• arrakis held Cloud Hypervisor at v44.0 for 471 days and twelve upstream releases. Upstream shipped a fix for a host-leak CVE the same day it was disclosed. The pin meant that fix took 90+ days to reach anyone running the default.

Now the inversion, which is the part that should change how you shop. gVisor (runsc) is a shared-kernel design, architecturally weaker than either of those, and it had no pin lag at all, because it releases rolling and there is no pin to go stale. microsandbox bumps its engine every one to three months. Daytona, which has the weakest architecture in the whole set, was shipping a fully current runc with every in-window fix applied.

So the three products with the best architecture-on-paper included the two worst exposure windows, and the product with the worst architecture had one of the best. Both facts are true at once. This is why you read the axes separately instead of collapsing them into a score.

Why we are not going to keep score for you

Everything in the section above has a shelf life. E2B may have bumped that pin the week after the study went out; arrakis may still be sitting on v44.0. Both are one commit away from being wrong, and a site that prints a number cannot tell you which.

So read those figures as what they are: dated snapshots, June 2026, on default settings, on one machine. They are here as worked examples of a question, not as a scoreboard. The question does not expire. The answer expires constantly. That distinction is the whole chapter, and it is why the rest of this page is questions.

Four questions to ask before you adopt anything

Each of these comes from a case where a product's marketing and its measured behaviour disagreed. None of them require you to trust us, or the study, or the vendor. They are all things you can go and check today, about a product we have never evaluated.

1. What runtime does it actually start? Not what the docs say, what the process table says. Daytona documented a hardened Sysbox default and marketed a dedicated kernel per sandbox; the measured default install path started a plain runc container with Privileged:true hardcoded, which switches off the seccomp profile, AppArmor, and user namespaces in one line. Read the runner config, or start a sandbox and look.

2. Which build of the engine, and who bumps it? Find the pin. Compare it to the engine's release history. Then find out whether anything automatically moves it, or whether it moves when someone remembers. A pin with no bump policy is not a version number, it is a countdown.

3. Is there a second wall, and is it on by default? A microVM boundary is enforced by a VMM that parses hostile guest input in userspace. Ask what confines that process. Ask specifically whether the confinement is default or opt-in: Cloud Hypervisor supports Landlock self-confinement, and the deployment measured in that study still had its leader thread running unfiltered. microsandbox has a genuine hardware boundary and no confinement of the VMM process at all.

4. What can the sandbox read about your host, and reach on your network? Egress default first, because that is how anything stolen leaves. Then leakage: the same study read ten host identifiers out of one product's sandbox, CPU brand, RAM, kernel version, BIOS details, disk serials, while two others leaked nothing across 28 probes.

A vendor who answers all four plainly is telling you more than any tier badge can. A vendor who cannot answer question two has already answered it.

What this does not mean

It does not mean the ladder was wrong. A privileged container with a current runc is still a privileged container; being up to date does not buy Daytona a kernel boundary, and the four escape-class runc CVEs in that same window are the architecture talking, not the pin. Architecture sets the ceiling on how bad a bug can be. The pin sets how long you live with the ones already found.

You want both. Pick the rung that matches your threat, then check that the rung is maintained. The first question gets asked once, when you choose. The second one you keep asking, because the answer keeps changing.

The study behind this chapter is on the further reading page, and it is worth reading in full, including its own account of what it does not establish. For where each product stands on the axes we do track, the dictionary has the per-entry detail.