Hacker News Reader

Comment by calrain | Hacker News Reader

It looks great. My main concern with Docker Hub images is what else is in the image that shouldn't be there. Not necessarily CVE issues, but just down right malicious code.

How do you identify what is a safe Docker Hub image?

Surely it's not just reputation of the publisher of the image.

View on HN

Docker is slowly improving tooling for reproducible builds. I'm working in a blog post presently about how to do it. Reproducible images allow others to audit the build. If you're worried about third party build systems getting infected and injecting malware (unknown to the otherwise trustworthy publisher), this can help.

At the moment I'm rat-holing on apt package pinning, which doesn't work at all like I expected. Looking like I'm stuck between the Debian snapshot archive and vendoring .deb files (I don't like either).

Eventually this will go out on https://alexsci.com/blog/

I'm with you. I thought Debian was much better at this, but it seems really tricky to do decent version pinning. I have new respect for NixOS.

Hi there, I'm from the Trivy team -- you can scan the misconfiguration of container images i.e. Dockerfile, with Trivy as well.

However, without the source code being open source, you cannot really check what anyone is up to -- thus, don't just use any container image on DockerHub

Docker images can be signed. And docker images are no different than any other software: if you don't trust who it's from, don't run it.

(Whether the standard docker tooling or user decides to validate signatures is another thing.)

For production, I'd recommend not using any image that isn't in the base image set, which are maintained by Docker, and if you're using Docker Hub, you already trust Docker :) There is also "verified publisher" scheme where Docker have done some verification on the publisher, so you may also want to trust those.

Outside of that any image can have anything in it.(Docker do sometimes remove actively malicious images if they're notified of them)

If you want an image similar to an existing one, you can often just read the dockerfile and create your own.

> Surely it's not just reputation of the publisher of the image.

Literally this for all of the software and dependencies that I use.

Honestly I think it is just the reputation of the publisher. Isn't that the case with almost all software?

Scanning one package is one thing, but distributing what are essentially entire disk images for a functioning OS plus whatever software you’re after just never seemed appealing to me. It’s doubly laughable when it’s Java or something else with its own VM, because for some reason we never have enough abstractions.

I did like the idea of running an OS that is a purpose-built container host, and containers that are stripped as bare as possible, until I thought about it more and realized that that’s supposed to be what a normal OS does with normal software. Zones and jails and cgroups and LX(C|D) were good ideas that we needn’t have reinvented on top.

That seems pretty much impossible to accurately classify. Any container image that runs a server could be seen as malicious depending on the user

Reply on news.ycombinator.com