Reducing vulnerabilities detected by scanners by using different base

[pboushy]

The current container being based on debian has a significant number of vulnerabilities detected by snyk and trivy.
Alpine usually has fewer because you can usually create an alpine container that has far fewer items in it (might not be true here based on reading on past usage of alpine)
Using ubuntu:22.04 appears to have significantly fewer than current debian, but a much larger image size.

Any thoughts on how to handle this?

[pboushy]

More details about the scan tool results:

Image Base	Trivy Vulns	Snyk Vulns
ubuntu:22.04	108 low, 59 medium	23 low, 5 medium
python:3-slim-buster	118 low, 13 medium, 32 high, 1 critical	93 low, 1 medium, 2 high, 1 critical

NOTE - snyk even says:

Base Image                 Vulnerabilities  Severity
python:3.11.4-slim-buster  75               1 critical, 2 high, 1 medium, 71 low

Recommendations for base image upgrade:

Alternative image types
Base Image                     Vulnerabilities  Severity
python:3.12.0b3-slim           29               0 critical, 0 high, 0 medium, 29 low
python:3.12.0b2-slim-bookworm  29               0 critical, 0 high, 0 medium, 29 low
python:3.12.0b3-slim-bullseye  50               0 critical, 0 high, 0 medium, 50 low
python:3-bookworm              140              0 critical, 0 high, 0 medium, 140 low

[jertel]

The below PR has the most recent detailed discussion regarding the base image, image size, built times, etc.:

#102

That was over 2 years ago so certainly things have changed since then. If you can improve on the image size and security posture, without sacrificing build time, functionality, or product stability, then I'm open to it.

[pboushy]

If the eventual solution improves on image size and security posture, but sacrifices a little built of build time is that ok?
Build time should only be occurring once in a while. Download time of a container is usually far more important.

[jertel]

Per the thread I attached it was important enough to one community member that he spent significant effort improving the build time. So for that reason I do not want to undo what he has achieved. I agree, though, that a small change in build time isn't going to be an issue.

[pboushy]

@jgregmac - would you mind chiming in with your thoughts?
As jertel mentioned, you spent a significant amount of time driving down total build time. I tend to focus more on size of container and security rather than build time cause that should happen relatively infrequently compares to pulls.

Any thoughts on this?
Do we provide multiple image specs and people choose one?

[jgregmac]

Sure, I have some thoughts about this:

Personally, I would prioritize base image stability first, followed by security, build time, and size. Base images running more current versions of python always will have fewer vulnerabilities, but that does not matter if the application that uses the python runtime is not validated against that version of python. Is ElastAlert validated against python 3.12? If yes, then absolutely use the base tag 3.12. Are there any issues with running ElastAlert on the bookworm base image? If no, then by all means transition to the bookworm base. Compatibility takes priority every time. Certainly I have no vested interest in preserving use of the "slim-buster" tag. This is an EOL image tag and will only become more vulnerable over time. A better image tag likely would be: 3.<testedRevision>-slim, where would be the most current python 3 point release with which ElastAlert is known to be compatible.

If security is the top priority, nothing will be more secure (or smaller) than a "distroless" image: that is am image with no package manager, no shell, and no diagnostic tools. Distroless images are a big win for security, but a huge compromise on usability, and thus are a really hard sell for most projects. However, short of going distoless, the security gains of switching between base image will be relatively minor.

Just whatever we do, let's not go back to an Alpine base. Alpine images are smaller, true, but they use a different C runtime for which pre-compiled python wheels are not available. This introduces compatibility issues and greatly reduces build reporducability. It also makes builds take forever because you have to re-compile your wheels every time.