Skip to content

Fix the Container Scanning Dockerfile builds to copy correct Trivy binary architecture

Summary

In v8.2.0 of container-scanning, we released arm64 images, but forgot to update the setup.sh script. This resulted in arm64 images that had the wrong binary in them. We should fix this by copying from the published aquasec/trivy images on Docker Hub.

Improvements

  • Smaller build cache!
  • Less bash
  • Faster build times because we copy less things around - think of --link like a symlink but for image layers

Involved components

  • .gitlab/ci/release.yml - I think we'll need to update the docker buildx bake to pass a build arg for TRIVY_VERSION like so --build-arg TRIVY_VERSION="$(cat version/TRIVY_VERSION)".
  • script/setup.sh
  • docker-bake.hcl
  • Dockerfile
  • Dockerfile.fips

Optional: Intended side effects

  • We should update the release for v8.2.0 to "yank" it for arm64 consumers. More visibility of this known issue is always better, and we can link to this issue as well.
  • We get some form of integrity and tampering checks. Previously we just downloaded the binary, but didn't check the published checksum or signature. Docker verifies the digest of the layer against the one in the manifest which is better than what we had before.

Optional: Missing test coverage

Should we add a test that verifies the file is correct?

gitlab@3d5653e1fa0c:~$ file opt/trivy/trivy
opt/trivy/trivy: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=e770b201a21ddc081579f1cc92b5a94cf264bc37, stripped

Keep in mind I had to do this in the container because file isn't installed by default.

sudo apt-get update && sudo apt-get install -qq -y file

Implementation plan

  • Fix the Dockerfiles to that they include the right Trivy binary
  • Release a new version with the fix
  • Write documentation explaining how to scan arm64 images
  • Create a release post to advertise this and drive adoption of the analyzer further
Edited by Oscar Tovar