Several openssl and glibc vulnerabilities reported by snyk in the docker image

[bu3]

Hi,
I was trying to use the docker image from Dockerhub but the Snyk scanner that runs in my organization raised several vulnerabilities related to debian:11.
It sounds like the base image is quite outdated.

I've uploaded the scanner report here:
snyk.report.zip

I couldn't find the Dockerfile in the repo, otherwise, I'd have tried to upgrade it by self and then send a PR.

[mostynb]

Hi, thanks for the report.

The bazel-remote container images aren't built using a Dockerfile, they're built using the go_image target (I'm unsure if that's the right name) from https://github.com/bazelbuild/rules_docker - I'll try upgrading that to see if it helps: #606

[mostynb]

The snyk report mentions vulnerabilities in openssl and glibc. These libraries seem to come from the gcr.io/distroless/base-debian11 container image that rules_docker uses for go_image's with cgo enabled. So I wonder if the rules_docker upgrade mentioned above upgraded these components- could you try rescanning docker.io/buchgr/bazel-remote-cache:latest ?

Note that even though openssl is included in this image, bazel-remote doesn't use it (go has its own TLS implementation).

[bu3]

Hi @mostynb thanks for replying so quickly. I tried with the latest and I got the same result.

Good to know that openssl is not a big deal but I need to make the security department digest it though.
In my organization security is pretty picky and to have a third-party library used in production requires to have a passing Snyk scanner only to have the conversation started.

[bu3]

I sent this PR with the most recent rules_go and gazelle. Waiting for PR build result, even though build didn't work on my Mac m1.

I wanted to push an updated version of the docker image to have it scanned again by Snyk but of course, if I cannot build there was not much I could do

[mostynb]

I added your changes to the master branch, but as I mentioned in the other PR I don't think it will help this issue.

While I haven't figured out how to upgrade the distroless base image yet, I have found a reference that seems to agree with the diagnosis: https://github.com/GoogleContainerTools/distroless/blob/main/base/README.md confirms that gcr.io/distroless/static is used for go apps that use cgo, and libssl + openssl are included.

It might be that we can avoid the warnings if we can find a suitable base image with recent glibc but without openssl and libssl, and specify that in the go_image. If you want a quick fix, you could probably create a minimal Dockerfile with suitable base and use the standalone release binary (https://github.com/buchgr/bazel-remote/releases/download/v2.3.9/bazel-remote-2.3.9-linux-x86_64).

[mostynb]

Hmm: there's work-in-progress in distroless to create "base-nossl" images: GoogleContainerTools/distroless#1098

[bu3]

Wow. That's good news @mostynb. I might be able to convince security by having them take a look at that issue. Thanks a million

[mostynb]

@bu3: I figured out how to try the preview distroless base-nossl-debian11 images: #611

Here's a test image, I wonder if you could scan this? https://hub.docker.com/layers/mostynb/bazel-remote-cache/no-openssl-amd64/images/sha256-a66cf03d5ad1b766018bdb90190840e1f174e13aeee89dc9545c97cb88304d74?context=repo

[bu3]

You're great @mostynb!
That got rid of all the high-severity issues. Only the low ones are still there but there is no fix available as far as I can tell from Snyk report.
Please find the report in the attachment FYI.

This will help me a lot in building my case with the security department.

Thanks a million
snyk-report-low-severity.zip

[mostynb]

Thanks for following up. I landed the change, it's available in buchgr/bazel-remote-cache:latest now, and will be in the next release (maybe in a week or two).