This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Creating SBOMs from Virtual Machines

Generate SBOMs from virtual machine filesystems and disk images using AnchoreCTL

Containers are not the only software you ship. Many organizations run virtual machines — on cloud providers, on-prem hypervisors, edge appliances, or air-gapped environments — and the workloads inside those VMs need the same SBOM-based security analysis that containerized workloads receive. This quickstart shows two practical ways to bring a virtual machine’s contents into Anchore Enterprise for vulnerability and policy analysis: by analyzing the live filesystem of a running VM, or by analyzing a VM disk image offline against a loopback mount.

When This Approach Fits

Filesystem-based analysis with AnchoreCTL fills the gap between “I have a container image” and “I have a software inventory” for workloads that don’t fit the container model:

  • Cloud or on-prem virtual machines running services that predate containerization, or that depend on kernel modules, system services, or installed packages that aren’t easily containerized.
  • Air-gapped or appliance environments where VM images are shipped as the unit of distribution and need to be analyzed before deployment.
  • Forensic or audit workflows where a disk image needs to be analyzed offline without booting the VM.
  • Build-time analysis of “golden image” VM templates before they’re cloned out across a fleet.

In each case, AnchoreCTL produces an SBOM from a directory tree and uploads it as an asset on an app version, where the result aggregates alongside any other assets (container images, filesystems, externally supplied SBOMs) attached to the same release.

Before You Start

  • An Anchore Enterprise deployment.
  • AnchoreCTL installed and configured to talk to your deployment.
  • For the running-VM approach: SSH access to the VM and the ability to install or copy in the AnchoreCTL binary.
  • For the disk-image approach: a Linux host with the QEMU utilities (qemu-utils on Debian/Ubuntu, qemu-img on RHEL/Fedora) and the NBD kernel module loaded. The module is a one-time sudo modprobe nbd max_part=8 on most distributions. Other VM disk formats (raw, vmdk, vdi) can be converted to qcow2 with qemu-img convert first.

Create the App and Version

Attach the resulting SBOM to an app version. Create the app and an initial version once — either ahead of time as part of release setup, or on-demand the first time you run the analysis:

anchorectl app add my-vm-fleet --contact-name "Platform Team"
anchorectl app version add 2026-06-01 --app my-vm-fleet

For the full app and version reference, see Manage Apps and Manage App Versions.

Approach A — Analyze a Running VM

Install AnchoreCTL inside the VM, then point it at the filesystem you want to analyze. Analyzing the root path is the broadest coverage; narrower paths (/usr, /opt, /srv) are faster if you only care about installed software:

# On the VM — install AnchoreCTL
curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=linux&architecture=amd64" \
  -H "accept: */*" | tar -zx anchorectl

# Configure connection to Anchore Enterprise
export ANCHORECTL_URL=https://my-anchore.example.com
export ANCHORECTL_USERNAME=<your-user>
export ANCHORECTL_PASSWORD=<your-password>

# Analyze the root filesystem and attach as an asset on the target app version
./anchorectl app version asset add filesystem / \
  --app my-vm-fleet \
  --version 2026-06-01 \
  --asset web-server-vm \
  --type virtual_machine_disk \
  --wait

The --type virtual_machine_disk flag tags the asset with the virtual_machine_disk type so it’s distinguishable from other filesystem-derived assets in the same version. The --wait flag blocks until the asset-add job reaches a terminal state.

Approach B — Analyze a VM Disk Image Offline

With QEMU utilities installed and the NBD module loaded (see Before You Start), mount the VM disk image read-only and run AnchoreCTL against the mount point. This walkthrough uses a qcow2 image — the most common Linux VM format.

# Connect the qcow2 image as a read-only network block device
sudo qemu-nbd --read-only --connect=/dev/nbd0 disk.qcow2

# Mount the root partition (adjust the partition number to match your image)
sudo mkdir -p /mnt/vm
sudo mount -o ro /dev/nbd0p1 /mnt/vm

# Analyze the mounted filesystem and attach as an asset
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

# Clean up
sudo umount /mnt/vm
sudo qemu-nbd --disconnect /dev/nbd0

This pattern is particularly useful for forensic or pre-deployment workflows — the VM never has to boot, no agent needs to be installed inside it, and the disk stays read-only throughout.

View Results in Anchore Enterprise

Once the asset-add job completes, open the app version detail page in the Anchore Enterprise GUI (Apps → my-vm-fleet → 2026-06-01) to see the analysis in context:

  • Summary tab — high-level asset and finding counts for the version.
  • Contents tab — every package discovered across the version’s assets, including the VM disk you just attached.
  • Vulnerabilities tab — every vulnerability surfaced from the version’s assets, sortable by Anchore Score.
  • Compliance tab — policy evaluation results, including findings that originate from the VM disk asset.

The same data is available programmatically:

# List the assets attached to the version (the VM asset should appear)
anchorectl app version asset list 2026-06-01 --app my-vm-fleet

# List vulnerabilities aggregated across the version
anchorectl app version vuln list 2026-06-01 --app my-vm-fleet

# Download the SBOM for a specific asset
anchorectl app version asset sbom get web-server-vm \
  --app my-vm-fleet \
  --version 2026-06-01 \
  --file web-server-vm.sbom.json

For the broader observability surface — package pivots, asset-location queries, and cross-asset vulnerability lookups — see Observe an App Version.

Conclusion

You’ve now extended Anchore Enterprise’s SBOM-based analysis to virtual machines — either live (running VM) or offline (mounted disk image) — and attached the result to an app version where it sits alongside any other release artifacts. Repeat the same pattern for additional VMs in your fleet, or fold the disk-image variant into your VM build pipeline to catch issues before image distribution.