CVE global threat

[dav-m85]

Just wanted to notify for the recent @banyanops study showing that >30% of the images built here have CVE threats.

Any idea how to address that ? IMHO, we shall provide at least information on which boxes are CVE-free and which are not.

[md5]

It looks like they're pulling all tags from the Docker Hub API (cf. https://github.com/banyanops/collector/blob/c790b784d2b9bb68aaeb39dde3b3268aabde6289/metadata.go#L407), so that "30%" needs to be taken with a grain of salt. Because they're counting all tags and not just the currently supported tags, they're counting things that have already been fixed in many cases. I haven't run their tool myself since I don't have enough time or disk space to download every tag of every official image, so I can't say for sure how many of these vulnerabilities apply to currently supported tags.

Now, just because a tag isn't currently supported as defined by the Official Images project doesn't mean that people aren't using it. However, since we don't have usage numbers for what percentage of deployed and running containers are based on vulnerable builds of official images, it's hard to say what the actual impact of that 30% number is.

One thing I've discussed with @eave is the idea that Docker Hub should support tagging image IDs with metadata about whether or not they are vulnerable to known exploits like CVEs or NVDs. The docker client could then be enhanced to warn users when they're installing a known-vulnerable image ID (or a derived image that includes known-vulnerable layers). There could even be a mode where the docker client errors out if the vulnerabilities were assigned a "high" risk category.

If there are specific vulnerabilities in the currently supported tags of the Official Images, those should of course be addressed. In my experience, I've seen any reported CVEs for the Official Images addressed quickly and transparently.

[md5]

cc/ @jgummaraju @yoshiotu from @banyanops, @ewindisch from @docker

[md5]

For that matter, being able to query the Docker Hub API for currently supported tags of an image instead of having to look at the text description on Docker Hub would be helpful too.

[ewindisch]

Agreed with @md5 that many of the figures here are for all tags, of which most are unsupported. Some figures, but too few, are specific to the latest tag, of this I think we could extract more meaningful data. Better yet, is if they could build this analysis against all of the supported image tags.

I agree that tooling such as Docker Engine or registries could provide better warnings/information about image EOL. If we could tag an image as EOL or give it an expiry, this could trigger info/warning messages to end-users. That could potentially help the issue of insecure "general images" as noted in the article.

Finally, if base operating systems do not patch for CVEs, we only inherit this. In fact, I know we've had to push at times for upstream distributions to patch security vulnerabilities. I'm curious to know what the difference here is to the cloud images for the same operating systems, to their bootable ISOs, and other installation mediums? We should strive to be excellent regardless, but the comparison to these other images and analysis specific to supported tags would be far more interesting to me in terms of how we might improve the security of images for users.

[psftw]

I played with the collector tool to see what it does. It runs scripts to gather information such as all versions of packages and a package dependency graph. This information comes from the OS CLI tooling mostly. I don't see where they are doing anything with the non-OS software in the images, but it looks like they have a way to extend the functionality of banyanops/collector with user-defined checks as well. This sounds similar in theory to some of the testing scripts in this repository, except those are actual functional tests. I presume the SaaS offering takes the OS package info and analyzes it to produce the results in their post, but that part is currently a black box as I don't have an account yet. I'm hoping to get an account with banyan to see more details and see what other value they offer.

I think we agree that the bigger picture of staying on top of this across all official images (and beyond) is not an easy problem, but one that many people rely on us to handle for them. It isn't clear to me how thorough the analysis really is -- matching distro package versions against CVEs is useful, but only part of the picture. Raw results on a per image basis would be more interesting to review. This post is a good reminder that we should continue thinking about these things and improve our strategy as we go. I'm well aware that there has already been a good deal of work in this area, but we haven't communicated much about it and our efforts are not perfect. There is no perfect solution, only continuous effort to stay on top of the problem with the best assurance we can provide. We are still dependent on a number of external entities.

[jgummaraju]

Thanks for the comments!

We intentionally did not publicize which images have what vulnerabilities, etc. because we did not want to offend/blame any stake holders. Our focus was more to make people aware of the security vulnerabilities so that they take this into account in their container deployment strategy. That said, we'd love to work with the official repositories team on some of this stuff. What would be a good way to move forward? @md5 @ewindisch @psftw

Good point about generating results just for supported tags -- we should be able to do that pretty quickly!

Cheers,
Jayanth

[eave]

We're speaking with Tarun on Friday—perhaps you could follow up with him and join?

Best,
Mario

[jgummaraju]

Ah yes, sounds great! I'm on that invite already...Just wasn't sure if the agenda was different for that call.

Looking forward to it!

Thanks,
Jayanth

[tianon]

Here's a good start:

$ bashbrew/bashbrew.sh list --all

The follow-up:

$ bashbrew/bashbrew.sh list --all --uniq