This is the first post in a series on the operational problems Anchore’s product quickstarts solve. This one is about what your SBOM inventory is missing if it only covers containers.
Ask most security teams what percentage of their software supply chain has an SBOM, and they’ll answer with a number that describes their container fleet. Ask what percentage of their actual infrastructure that covers, and the number gets a lot smaller. Legacy applications, regulated systems that can’t be containerized yet, hybrid servers that predate the container conversation entirely: none of that shows up in a registry, so none of it shows up in most SBOM programs.
That gap didn’t matter much when an SBOM was mostly a compliance checkbox. It matters a great deal more now and not because of a new regulatory field to check off. It’s because the assumption underneath most SBOM roadmaps, that infrastructure is steadily moving from VMs to containers and the VM problem will eventually just go away, doesn’t hold up. IDC forecasts that nearly 85% of all containers will still be running inside VMs through 2028, because enterprises trust the virtualization layer for the isolation, governance, and operational control containers alone don’t provide. VMs and containers aren’t a transition story. They’re two things that coexist for the long term, which means an SBOM program that only covers one of them isn’t a temporary gap that adoption trends will close on their own.
We see this most often with organizations running a mix of containerized services and long-lived VMs, whether that’s a legacy application nobody’s gotten around to containerizing, a regulated workload that can’t move to containers yet, or infrastructure that’s simply been running fine for years and nobody’s touched it. When a new CVE drops, the team can answer “are we affected” for their container fleet in minutes. For everything else, they’re back to manually checking servers one at a time. That’s the exact gap Anchore Enterprise’s quickstart for creating and storing SBOMs is built to close, by treating a VM filesystem as a legitimate first-class source.
What’s actually different about generating an SBOM from a VM versus a container
Container SBOM tooling matured first because containers made the problem easier: an image is immutable, it has clearly defined layers, and there’s a registry to pull it from. A VM or a bare server has none of that. There’s no registry, no layers, and the filesystem you’re inspecting is often live and changing while you’re looking at it.
Anchore Enterprise handles this by treating a filesystem, not just a container image, as a first-class thing you can generate an SBOM from. You create an app (the software you ship or host) and a version (a point-in-time release), then attach assets to it. An asset can be a container image, an analyzed filesystem, or an SBOM someone handed you, and they all aggregate together under an application version.
```shell
anchorectl app add my-vm-fleet --contact-name "Platform Team"
anchorectl app version add 2026-06-01 --app my-vm-fleet
```For a running VM, install AnchoreCTL inside it and point it at the filesystem you want to analyze. AnchoreCTL walks the directory tree, generates the SBOM locally using Syft, and uploads the result. Pseudo-filesystems like `/proc` and `/sys` are skipped by default, so analyzing `/` is safe, and narrower paths (`/usr`, `/opt`, `/srv`) are faster if you only care about installed software:
```shell
anchorectl app version asset add filesystem / \
--app my-vm-fleet \
--version 2026-06-01 \
--asset web-server-vm \
--type virtual_machine_disk \
--wait
```For a VM disk image, you don’t boot the VM at all. With the QEMU utilities installed and the NBD kernel module loaded, mount the image read-only and scan the mount point:
```shell
sudo qemu-nbd --read-only --connect=/dev/nbd0 disk.qcow2
sudo mount -o ro /dev/nbd0p1 /mnt/vm
anchorectl app version asset add filesystem /mnt/vm \
--app my-vm-fleet \
--version 2026-06-01 \
--asset web-server-vm-image \
--type virtual_machine_disk \
--wait
```No agent gets installed inside the VM, the disk stays read-only throughout, and the same pattern works for forensic workflows and for golden-image templates before they’re cloned out across a fleet.
Container images attach to the same app version the same way (`anchorectl app version asset add container-image`), and so do SBOMs generated by someone else’s tooling (`anchorectl app version asset add sbom`). That’s the mechanism behind everything that follows: containers, VMs, and third-party SBOMs are three asset types in one version.
The format matters
Whichever path generates the SBOM, the format it comes out in matters more than it might seem. Anchore Enterprise stores SBOMs internally in its Syft-native format and imports and exports both dominant open standards, CycloneDX (JSON and XML) and SPDX (JSON and tag-value), and the SBOMs it generates meet the NTIA’s minimum required elements: supplier name, component name, version, a unique identifier such as a `purl`, dependency relationships, SBOM author, and timestamp. The filesystem command even takes `--author` and `--supplier` flags, so authorship gets stamped at generation time instead of backfilled later.
An SBOM missing a unique component identifier or a clear dependency relationship isn’t a smaller SBOM. It’s one that can’t be reliably queried during the exact moment it’s supposed to help, which is when a new vulnerability shows up and someone needs an answer in minutes, not days.
What changes once containers and VMs are one inventory
Go back to where we started: most SBOM programs can answer “are we affected” fast for containers and slowly, manually, or not at all for everything else. That’s the actual risk. Not that VMs are inherently less secure, but that the inventory covering them doesn’t exist in a form anyone can query under pressure. That pressure has a real deadline attached for a lot of organizations: the EU Cyber Resilience Act’s vulnerability reporting requirement takes effect September 11, 2026, and it doesn’t grant an exception for infrastructure that’s harder to inventory.
The technical outcome is a single, queryable inventory that treats a container image and a mounted VM filesystem as two assets feeding the same app version, not two separate problems with two separate processes. Anchore Enterprise’s unified queries work across every asset in a version, so “which parts of this release contain `openssl 3.0.13`?” is one request whether the answer lives in a container or a VM. The business outcome is the same incident response speed for your oldest infrastructure that you already have for your newest.
One of our customers DreamFactory runs a higher percentage of containers rather than VMs, however they serve defense and other highly regulated customers who require on-premises, air-gapped deployments where the usual assumption of always-on cloud connectivity simply doesn’t hold. By integrating automated SBOM generation directly into their build pipeline and running daily scans regardless of network isolation, DreamFactory cut time spent on vulnerability management and compliance work by 75% and now deploys 70% faster with security checks built in, rather than bolted on after the fact. The underlying lesson transfers directly to VM and legacy infrastructure: the moment you stop treating an environment as a special case that gets manual, occasional attention, and start treating it as another source feeding one inventory, the response time problem mostly resolves itself.
This is the same SBOM generation and storage workflow Anchore Enterprise customers use today, whether the source is a container image or a filesystem. If you’re already running Anchore Enterprise, our quickstart for creating SBOMs from virtual machines walks through both paths end to end, including viewing the results alongside your container assets.
If you’re evaluating how this would extend your own inventory, request a demo and bring your actual mix of containers and legacy infrastructure to the conversation.
This is the first post in the series. Next up: what changes once you can see what’s actually running in a Kubernetes cluster, not just what’s declared.
