9 ms·

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

91 points by steelcityamir 3y ago

I found it odd there wasn’t a simple web tool to scan Docker Hub images for vulnerabilities. So I built one. It’s powered by the popular open-source tool Trivy.

kylequest 3y ago
Nice and simple interface! Congrats! There are a number of web/SaaS based vulnerability scanners out there actually :) Snyk's SaaS does it, for example. Free to sign up, free to use. My company's SaaS also provides container scanning with Grype and Trivy. There was another free web-based tool I found a while ago too (forgot the name... will look for it).
calrain 3y ago
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.
- SoftTalker 3y ago
  Honestly I think it is just the reputation of the publisher. Isn't that the case with almost all software?
- athorax 3y ago
  That seems pretty much impossible to accurately classify. Any container image that runs a server could be seen as malicious depending on the user
- bityard 3y ago
  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.)
- 8organicbits 3y ago
  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/ https://alexsci.com/blog/
  - robertlagrant 3y ago
    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.
- seanp2k2 3y ago
  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.
  - deleted 3y ago
    [deleted]
- raesene9 3y ago
  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.
- wiseowise 3y ago
  > Surely it's not just reputation of the publisher of the image. Literally this for all of the software and dependencies that I use.
- urlichsanais 3y ago
  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
andenacitelli 3y ago
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.
- 8organicbits 3y ago
  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.
  - smitty1110 3y ago
    It's just Trivy under the hood, there's already an action on the marketplace for that: https://github.com/aquasecurity/trivy-action https://github.com/aquasecurity/trivy-action
- raesene9 3y ago
  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.
nubb 3y ago
you should include seed phrase and private key detection. a few crypto protocols that offer public docker images have been drained from accidentally committing keys to docker hub.
- 8organicbits 3y ago
  I think Trivy does that already [1]. I personally use trufflehog [2] to find secrets of all kinds. Unfortunately, these sorts of tools have false positives [1] https://aquasecurity.github.io/trivy/v0.27.1/docs/secret/scanning/ https://aquasecurity.github.io/trivy/v0.27.1/docs/secret/sca... [2] https://github.com/trufflesecurity/trufflehog https://github.com/trufflesecurity/trufflehog
raister 3y ago
Responded: > Scanning is unavailable at the moment. Try again later.
- talonx 3y ago
  Got this too. 504 Gateway timeout - probably HN hug of death?
  - steelcityamir 3y ago
    Author here. HN hug of death indeed - running on a t2.micro instance. It is back up now.
raesene9 3y ago
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-images-Bypassing-vulnerability-scanners/ https://raesene.github.io/blog/2023/04/22/Fun-with-container...
- urlichsanais 3y ago
  Security Scanners are not supposed to be defensive tools -- they flag what they can find; evaluating the quality of the resources is still the responsibility of the user
lars_francke 3y ago
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.
- heads 3y ago
  (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!”
  - kylequest 3y ago
    Quite a few vulnerabilities don't have CVEs. You can find some of them in the Github Security Advisories.
  - lars_francke 3y ago
    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
    - 3y ago
deleted 3y ago
[deleted]
1729175067 3y ago
[flagged]
robofanatic 3y ago
Great tool! minor feature suggestion to add a querysting parameter to pass the image name so that it can be linked from other sites

91 points by steelcityamir 3y ago

I found it odd there wasn’t a simple web tool to scan Docker Hub images for vulnerabilities. So I built one. It’s powered by the popular open-source tool Trivy.

kylequest 3y ago

Nice and simple interface! Congrats! There are a number of web/SaaS based vulnerability scanners out there actually :) Snyk's SaaS does it, for example. Free to sign up, free to use. My company's SaaS also provides container scanning with Grype and Trivy. There was another free web-based tool I found a while ago too (forgot the name... will look for it).

calrain 3y ago

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.

SoftTalker 3y ago
Honestly I think it is just the reputation of the publisher. Isn't that the case with almost all software?
athorax 3y ago
That seems pretty much impossible to accurately classify. Any container image that runs a server could be seen as malicious depending on the user
bityard 3y ago
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.)
8organicbits 3y ago
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/ https://alexsci.com/blog/
- robertlagrant 3y ago
  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.
seanp2k2 3y ago
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.
- deleted 3y ago
  [deleted]
raesene9 3y ago
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.
wiseowise 3y ago
> Surely it's not just reputation of the publisher of the image. Literally this for all of the software and dependencies that I use.
urlichsanais 3y ago
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

andenacitelli 3y ago

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.

8organicbits 3y ago
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.
- smitty1110 3y ago
  It's just Trivy under the hood, there's already an action on the marketplace for that: https://github.com/aquasecurity/trivy-action https://github.com/aquasecurity/trivy-action
raesene9 3y ago
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.

nubb 3y ago

you should include seed phrase and private key detection. a few crypto protocols that offer public docker images have been drained from accidentally committing keys to docker hub.

8organicbits 3y ago
I think Trivy does that already [1]. I personally use trufflehog [2] to find secrets of all kinds. Unfortunately, these sorts of tools have false positives [1] https://aquasecurity.github.io/trivy/v0.27.1/docs/secret/scanning/ https://aquasecurity.github.io/trivy/v0.27.1/docs/secret/sca... [2] https://github.com/trufflesecurity/trufflehog https://github.com/trufflesecurity/trufflehog

raister 3y ago

Responded: > Scanning is unavailable at the moment. Try again later.

talonx 3y ago
Got this too. 504 Gateway timeout - probably HN hug of death?
- steelcityamir 3y ago
  Author here. HN hug of death indeed - running on a t2.micro instance. It is back up now.

raesene9 3y ago

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-images-Bypassing-vulnerability-scanners/ https://raesene.github.io/blog/2023/04/22/Fun-with-container...

urlichsanais 3y ago
Security Scanners are not supposed to be defensive tools -- they flag what they can find; evaluating the quality of the resources is still the responsibility of the user

lars_francke 3y ago

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.

heads 3y ago
(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!”
- kylequest 3y ago
  Quite a few vulnerabilities don't have CVEs. You can find some of them in the Github Security Advisories.
- lars_francke 3y ago
  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
  - 3y ago

deleted 3y ago

[deleted]

1729175067 3y ago

[flagged]

robofanatic 3y ago

Great tool! minor feature suggestion to add a querysting parameter to pass the image name so that it can be linked from other sites