Background
Modern cloud-native applications are often packaged as container images and run in container orchestration environments. A fairly typical security need for containerized applications is visibility into the known security vulnerabilities (I’ll be subsequently referring to them as CVEs for brevity) in the images. As companies mature their tooling and start tracking and mitigating the CVEs, they inevitably realize what a messy world container images are, and feel the need to make the process of addressing the CVEs less painful and resource-intensive. A big factor in optimizing these efforts is selecting base images:
- images that are well supported and actively updates make the process of addressing the CVEs easier and faster
- images with minimal included components have less CVEs over time
In order to understand the issue better and provide guidance for our software engineering teams, I conducted a quick test of some of the popular base images to determine the number of unresolved CVEs in them, and I present the result of my test below.
How To Scan?
There’s a number of open source, as well as commercial, tools that can be used for image CVE scanning. Firstly, in the newer versions of Docker and Docker Desktop, there is a scan command that allows scanning of images (actual scanning is done with Snyk).
While it is a good option, I’ve opted for trivy— an open source tool from Aqua Security. You can find trivy here: https://github.com/aquasecurity/trivy
Trivy is a command line scanner, is CI/CD friendly, and supports several formats for scan result output, including text/tabular and JSON. Once installed, using trivy is as easy as running:
trivy image <IMAGE>:<TAG>Scan Results
I have limited the scans to some of the popular images, namely:
- “Bare OS” type images — Ubuntu, Debian, Alpine Linux, and Amazon Linux.
- Google’s distroless images (https://github.com/GoogleContainerTools/distroless).
- Images used for load balancing — nginx, haproxy.
- Language and runtime-specific images — python, ruby, golang, openjdk, and distroless Java 11.
Note that all the results are point in time (scans were completed on 20 April 2022). You can easily verify the scans, but I expect you to get slightly different CVE numbers, though overall trends are not likely to change.
Conclusions
- There’s an enormous variance in CVE numbers across the different images. My take is that selecting a good base image would significantly affect the churn of your container vulnerability management.
- Minimal base images (Alpine and distroless) tend to have noticeably less CVEs.
- Ubuntu, Alpine, and Amazon Linux (which was a nice surprise, personally) seem to be better maintained and had fever CVEs.
- With non- “bare OS” images, picking Alpine based images significantly affects the number of CVEs.
openjdk:latestandopenjdk:17(they’re currently based on Oracle Linux 8) are surprisingly well maintained, even compared to Alpine flavour of the images.
Note that CVEs is only one (small) aspect of the container and image security. For example, I would say that distroless images are likely to provide better security, even if they have higher CVE count, as there are much less opportunities for an attacker to move laterally and generally use their access even if they’re successful in getting a foothold. The mental model that I use is that container image CVEs are part of good hygiene — we should strive for less, but it’s not the end-all be-all of container security.
