Scanning disk images with Trivy is surprisingly effective because it doesn’t need to boot the OS or run any code within the image to find vulnerabilities.
Here’s how it looks in practice:
# First, download a disk image (e.g., a Debian cloud image)
wget https://cloud.debian.org/images/openstack/current/debian-11-genericcloud-amd64.qcow2
# Then, scan it with Trivy
trivy vm debian-11-genericcloud-amd64.qcow2
The output will look something like this, detailing OS packages and application dependencies with their known vulnerabilities:
debian-11-genericcloud-amd64.qcow2 (debian 11)
Total: 211 (UNKNOWN: 0, LOW: 100, MEDIUM: 80, HIGH: 31)
┌───────────────────────────────┬───────────┬───────────┬───────────────┐
│ VULNERABILITY ID │ PACKAGE │ VERSION │ SEVERITY │
├───────────────────────────────┼───────────┼───────────┼───────────────┤
│ CVE-2023-XXXX │ openssl │ 1.1.1k-1 │ HIGH │
├───────────────────────────────┼───────────┼───────────┼───────────────┤
│ CVE-2023-YYYY │ linux │ 5.10.0-10 │ MEDIUM │
├───────────────────────────────┼───────────┼───────────┼───────────────┤
│ CVE-2023-ZZZZ │ curl │ 7.74.0-1 │ LOW │
...
This capability stems from Trivy’s ability to mount the root filesystem of the disk image (or VMDK, QCOW2, etc.) as a temporary filesystem on your host. It then traverses this mounted filesystem, identifying installed packages by looking for standard package manager databases (like /var/lib/dpkg/status for Debian/Ubuntu, or /etc/redhat-release and RPM databases for RHEL/CentOS/Fedora). For application dependencies, it scans common locations for language-specific manifest files (e.g., package.json, requirements.txt, pom.xml, Gemfile). Once it has a list of installed software and their versions, it queries its vulnerability database to find matches.
The core problem Trivy VM scanning solves is the security assessment of "immutable" infrastructure components. In cloud-native environments, virtual machines and disk images are often treated as deployable units. Scanning these before deployment, or scanning dormant images in artifact repositories, provides a crucial security gate. It allows you to catch vulnerabilities in the base operating system and pre-installed applications without needing to spin up the VM, connect to it, or rely on agents running inside. This is particularly useful for images that might be infrequently updated or for auditing compliance requirements.
Internally, Trivy uses a technique called "guestfs" or similar library mechanisms to mount the various disk image formats without altering the original image. It creates a read-only mount point, extracts the necessary metadata about the filesystem structure and contents, and then proceeds with its analysis. You can control the depth of scanning and the types of vulnerabilities Trivy looks for using flags like --severity and --scanners. For instance, --scanners os,app is the default for VM scanning, covering both operating system packages and application dependencies.
When scanning a disk image, Trivy constructs a virtual root filesystem by inspecting the image’s partition table and then mounting the relevant partition. It’s effectively treating the disk image as a raw block device and extracting a usable filesystem from it. This means it can find vulnerabilities even in images that haven’t been fully provisioned or booted, which is a significant advantage for offline analysis and security hardening.
The most surprising mechanical detail is how Trivy handles different filesystem types within the image. It doesn’t rely on a single filesystem driver; rather, it leverages underlying libraries that can understand and mount common Linux filesystems like ext4, XFS, and even Btrfs, all without needing the host OS to have native support for them. This abstraction layer is key to its broad compatibility with various disk image formats and operating systems.
The next challenge you’ll encounter is integrating this offline scanning into your CI/CD pipeline for automated image security checks.