51% of images on Docker Hub have critical vulnerabilities [pdf]

A few things come to mind reading this:

> For comparison, Google Play has 2.7M Android apps in its store, with a download rate of 84 billion downloads a year.

I assume Google Play downloads are actual people making decisions to physically click a button, downloading an app intentionally. Docker downloads, on the other hand, are 99.9% automated by the number of times I pull images. Downloads are nearly always part of a CI pipeline, docker-compose.yml or some other automated sequence.

It strikes me to see these numbers compared.

> At Prevasio, we have built a dynamic analysis sandbox that uses the same principle as a conventional sandbox that ‘detonates’ malware in a safe environment...

Ok, this sounds pretty cool. Would be great to see an open source repo of the work.

> With no built-in security mechanisms present or exposed to the industry, Docker Hub today reminds a Wild West that Google Play once was.

Yup, that seems fair, but I don't know if it's a bad thing. When I download Git repos or take code from the internet I am not expecting it to be safe. It is my responsibility to vet code before using it somewhere sensitive. Does Docker want there to be an expectation that user-uploaded content is somehow safe?

> Malicious... images... split into the following categories...

> - Coinminers: 44% (2,842 images)

> - Other: 6.6% (426 images)

> - Hacking Tools: 20% (1,269 images)

> - Windows Malware: 6.4% (413 images)

> - flatmap-stream: 23% (1,482 images)

This is great to see. I assumed most of the malicious images were "malware"-types, but it makes sense that coiner miners are more lucrative.

> Some publicly available Docker containers include open source web platforms or other web applications that are found to be trojanized.

This is alarming. I often look for a Dockerhub link on master repos or other official project pages, but very few are "obviously" official. For example, how are we supposed to know "jupyter/scipy-notebook" is official, but not "jupyter-notebook/scipy"? It would be great for projects to standardize on a way of flagging official images.

Finally, I will admit to not seeing the one type of vulnerability that concerns me most: host-breakout. That is, when code in the container can affect the host system it is run on. I think there is a sense of security when using a container, and if you accidentally download something malicious within the container than you can `docker rm` the whole thing and still have a clean system.

I would be interested to see an analysis of malicious Docker images that can break out into the host machine.