Today I Learned (March 30, 2024)

That GitLab container scanning does not by default support linux/arm64 images.

:bulb: Tl;dr: Use the --platform option to specify your image platform.

triy is a container scanning tool by Acqua Security.

If we run a container scan on an image built exclusively for another platform (like linux/arm64) (cf. related GitHub issue), trivy will fail with an error similar to the following:

INFO Vulnerability scanning is enabled
 FATAL image scan error: scan error: unable to initialize a scanner: unable to initialize an image scanner: 4 errors occurred:

* docker error: unable to inspect the image (**********): permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "[(**********](**********)": dial unix /var/run/docker.sock: connect: permission denied

* containerd error: containerd socket not found: /run/containerd/containerd.sock

* podman error: unable to initialize Podman client: no podman socket found: stat podman/podman.sock: no such file or directory

* remote error: no child with platform linux/amd64 in index **********

Note that last line that says no child with platform linux/amd64 was found. (Since we only have a child for platform linux/arm64, this error makes complete sense.)

Why does this happen? Well, simply, trivy by default assumes the platform linux/amd64. If we want a scan for another platform, we have to specify this using the --platform option to trivy image (cf. trivy docs).

If we use GitLab container scanning to run trivy on an image, there currently seems to be no way to pass the platform option. Consequently, the container scanning template cannot—currently—be used to scan images for platforms other than linux/amd64.

How missing image digests while using docker buildx build may be fixed

The provenance false option fixes empty metadata/no digest issue in GitLab (cf.

docker buildx build --provenance false ...