Live data from Hacker News

Show HN: I built ContainerCVE – a web tool to scan public Docker images

containercve.com

11–20 of 38 posts

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#11

Don’t Docker themselves have a tool for this, Docker Scout? Pops up with how many known vulnerabilities are in each layer when you go to the page for a specific tag on Docker Hub. I think it’s a somewhat new product so it may not be too widespread yet, but it seems to work pretty well from my admittedly uninformed perspective.

If this detects things that Docker misses, then it's a good product. Consider adding support for GitHub Actions so a PR can automatically kick off a scan. You'll see lots of repeat images, so cache appropriately. With an integration, I think you could charge a subscription for this tool.

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#12
post #2

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.

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.

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#13

Don’t Docker themselves have a tool for this, Docker Scout? Pops up with how many known vulnerabilities are in each layer when you go to the page for a specific tag on Docker Hub. I think it’s a somewhat new product so it may not be too widespread yet, but it seems to work pretty well from my admittedly uninformed perspective.

If this detects things that Docker misses, then it's a good product. Consider adding support for GitHub Actions so a PR can automatically kick off a scan. You'll see lots of repeat images, so cache appropriately. With an integration, I think you could charge a subscription for this tool.

It's just Trivy under the hood, there's already an action on the marketplace for that: https://github.com/aquasecurity/trivy-action

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#14
post #2

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.

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.

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#15

Don’t Docker themselves have a tool for this, Docker Scout? Pops up with how many known vulnerabilities are in each layer when you go to the page for a specific tag on Docker Hub. I think it’s a somewhat new product so it may not be too widespread yet, but it seems to work pretty well from my admittedly uninformed perspective.

There's a number of image scanners which (IME) can produce different results from each other, although it's not always as clearly right/wrong as you might expect. Trivy (that this page is based on), Docker Scout, and Grype are three of the more common ones.

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#16
It's worth noting that whilst vulnerability scanners are very useful, they pretty easy to bypass, if someone creates an image and doesn't want them to flag things up.

One very basic example is https://raesene.github.io/blog/2023/04/22/Fun-with-container...

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#17
post #2

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.

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

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

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#18
It might sound like nitpicking but I find it dangerous to say vulnerability == CVE.

CVEs are one source of information about potential vulnerabilities but they are amongst the least reliable these days. I've heard them being called Curriculum Vitae Enhancer.

And Trivy itself uses more sources than just CVEs as well. With upcoming regulation like the Cyber Resilience Act we'll get even more sources of vulnerabilities. I believe the future will be/should be one of distributed sources for this information. Every vendor might want to be their own authoritative source of vulnerabilities.

This is a long way of saying: Useful tool, congratulations on the launch! I'd suggest a change of name as you limit yourself with the current one.

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#19

It might sound like nitpicking but I find it dangerous to say vulnerability == CVE. CVEs are one source of information about potential vulnerabilities but they are amongst the least reliable these days. I've heard them being called Curriculum Vitae Enhancer. And Trivy itself uses more sources than just CVEs as well. With upcoming regulation like the Cyber Resilience Act we'll get even more sources of vulnerabilities.…

(Not the author.) I’ve only really encountered CVEs when they have been mentioned on patches, usually Debian security updates.

Do vulnerabilities normally get a patch and are we expecting upcoming regulation to require the patches are installed? If action is required to be taken when vulns are published do we all have to just uninstall the thing until the bug gets fixed, lest we invalidate our corporate insurance policy?

Will I have to cease my current policy of running Trivy, reading the CVE output, and then declaring (and making a git commit saying) “while this stdlib library technically supports CORBA and our OS technically supports IPX, we don’t use CORBA or IPX… or networking… or this library… so I’m ignoring this!”

Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images

#20
post #19

It might sound like nitpicking but I find it dangerous to say vulnerability == CVE. CVEs are one source of information about potential vulnerabilities but they are amongst the least reliable these days. I've heard them being called Curriculum Vitae Enhancer. And Trivy itself uses more sources than just CVEs as well. With upcoming regulation like the Cyber Resilience Act we'll get even more sources of vulnerabilities.…

(Not the author.) I’ve only really encountered CVEs when they have been mentioned on patches, usually Debian security updates. Do vulnerabilities normally get a patch and are we expecting upcoming regulation to require the patches are installed? If action is required to be taken when vulns are published do we all have to just uninstall the thing until the bug gets fixed, lest we invalidate our corporate insurance pol…

I'm not sure if you're replying to the correct thread?

All I'm saying is that all CVEs are supposed to be vulnerabilities but not all vulnerabilities have a CVE. So, the name artificially limits the scope of the product. Trivy reports more than just CVEs

Post reply on HN