Trivy unable to get uncompressed layer

[pjonsson]

Description

Docker Engine v29 uses the containerd image store by default for fresh installs (https://www.docker.com/blog/docker-engine-version-29/#containerd-image-store-becomes-the-default), and this caused our Trivy scans in CI to start failing because they were unable to get the right layers. Reverting to the graph storage backend (setting the containerd-snapshotter to false in the features section in /etc/docker/daemon.json) and restarting Docker made the Trivy scans work again.

Here is the log of a failure:

docker run -v /var/run/docker.sock:/var/run/docker.sock scanner-image:latest bash --login -c "trivy image --severity HIGH,CRITICAL --skip-version-check --scanners vuln --no-progress --image-src docker -o scan-result.txt b3e8b92255301d0135b65f1e293e0d7a7b0a26266d7c2ebe7d53831e7607e457"
2025-11-17T02:08:25Z	INFO	[vulndb] Need to update DB
2025-11-17T02:08:25Z	INFO	[vulndb] Downloading vulnerability DB...
2025-11-17T02:08:25Z	INFO	[vulndb] Downloading artifact...	repo="mirror.gcr.io/aquasec/trivy-db:2"
2025-11-17T02:08:29Z	INFO	[vulndb] Artifact successfully downloaded	repo="mirror.gcr.io/aquasec/trivy-db:2"
2025-11-17T02:08:29Z	INFO	[vuln] Vulnerability scanning is enabled
2025-11-17T02:08:29Z	FATAL	Fatal error	run error: image scan error: scan error: scan failed: failed analysis: analyze error: pipeline error: failed to analyze layer (sha256:e8bce0aabd687e9ee90e0bada33884f40b277196f72aac9934357472863a80ae): unable to get uncompressed layer sha256:e8bce0aabd687e9ee90e0bada33884f40b277196f72aac9934357472863a80ae: failed to get the layer (sha256:e8bce0aabd687e9ee90e0bada33884f40b277196f72aac9934357472863a80ae): unable to populate: unable to open: unable to export the image: Error response from daemon: invalid repository name (5caf63c8860016d490692c2b280132e9a73469b71444e0cd1abbbd864b0d1d48), cannot specify 64-byte hexadecimal strings

The b3e8b92255301d0135b65f1e293e0d7a7b0a26266d7c2ebe7d53831e7607e457 in the log is the ID column from the output of docker images --no-trunc.

I don't think there is anything special with our scanner-image, it's based on Ubuntu 24.04 image and is just doing tar xf trivy.tar.gz -C /usr/local/bin/ --no-same-owner trivy contrib to install the x86_64 tarball version of the Trivy release. The user inside the container has the required permissions for /var/run/docker.sock.

Desired Behavior

The scan to complete just like it does when not using the containerd image store, or Trivy to detect that there is something wrong and give an error message containing some actionable instructions without having to run Trivy in debug mode.

Actual Behavior

I put the log of what happened in the description box.

Reproduction Steps

1. Do a fresh install of Docker Engine 29.0.1 on Ubuntu 22.04/24.04 so it uses the containerd image store.
2. Start a container containing Trivy and try to scan a docker image referenced by the `ID` from the output of `docker images`.

Target

Container Image

Scanner

None

Output Format

None

Mode

None

Debug Output

Don't have this, sorry.

Operating System

Ubuntu 24.04

Version

0.67.1

Checklist

• Run trivy clean --all
• Read the troubleshooting

[pjonsson]

From some additional testing on a different machine, it seems Trivy behaves differently when it is given the short ID from docker images versus the long version of the ID (but without the leading sha256:) from docker images --no-trunc. Prepending sha256: to the ID makes Trivy behave the same way for short/long ID when Docker is configured to use the containerd image store. I don't have the log with the failure that caused me to remove the leading sha256: when upgrading to Docker 29.0.0 (and not using containerd image store), but as far as I remember Trivy failed when it was there.

I can't guarantee that the machine I was testing on is identical to our CI machines, but this is the best I can do.

I don't particularly care which formats of the ID that Trivy accept as long as there is a human readable error message when giving the wrong format. That error message should preferably also indicate the expected format of the ID, so the user gets an idea of what they should do.