Earlier quoted context omitted.
(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
Show HN: I built ContainerCVE – a web tool to scan public Docker images
21–30 of 38 posts
Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#22Earlier quoted context omitted.
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
It was directed at you as you seem to know what you are talking about!
We recently wrote a document on how we would like to approach our own vulnerability management process. It received a lot of comments and we'll gladly take more:
https://docs.google.com/document/d/1QB3EaimrS0KlL6wIpfY5-SlE...
To answer your questions then :)
> Do vulnerabilities normally get a patch and are we expecting upcoming regulation to require the patches are installed?
Not all vulnerabilities get a patch, it's really up to the project. But this is what the CRA is about. In the commercial context it will require vendors to handle vulnerabilities by e.g. providing patches. And depending on which industry you are in you might also be required to install said patches.
> 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?
I doubt it but it's a good idea to have a good overview of what you're running in your company. This extends to dependencies which might be included in things you're running. That is what SBOMs are meant for. They will be required in the future.
> 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!”
No. That is excellent! It will be formalized into a machine readable format. Currently often called a VEX statement: Vulnerability Exploitability Exchange. One popularish format for this is CSAF. But CycloneDX (an SBOM format) can also be used for this.
Having this in a machine readable format makes it easier for users to consume the information.
The tooling for this is not great yet, which is what our document above is about.
Hope it helps.
Happy to chat about this if you're interested. Reach out if you like. Details should be in my profile.
Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#23It 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.…
Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#24Responded: > Scanning is unavailable at the moment. Try again later.
Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#25Earlier quoted context omitted.
It was directed at you as you seem to know what you are talking about!
I have been tangentially involved in the Cyber Resilience Act (CRA). I'm more an interested party than a real expert. We recently wrote a document on how we would like to approach our own vulnerability management process. It received a lot of comments and we'll gladly take more: https://docs.google.com/document/d/1QB3EaimrS0KlL6wIpfY5-SlE... To answer your questions then :) > Do vulnerabilities normally get a patch a…
Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#26Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#27It 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.…
Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#28It 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.
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.…
Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#29It 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 stri…
Re: Show HN: I built ContainerCVE – a web tool to scan public Docker images
#30Earlier quoted context omitted.
I have been tangentially involved in the Cyber Resilience Act (CRA). I'm more an interested party than a real expert. We recently wrote a document on how we would like to approach our own vulnerability management process. It received a lot of comments and we'll gladly take more: https://docs.google.com/document/d/1QB3EaimrS0KlL6wIpfY5-SlE... To answer your questions then :) > Do vulnerabilities normally get a patch a…
The question on everyone's mind is whether or not regulators (Fed/State RAMP, etc) will accept variances with a vex statement. The posture for the vast majority of businesses subject to this kind of regulation is "fix every single CVE regardless of impact".
I'm repeating myself but: CVEs are useless. Please don't use them as an equivalent for "vulnerabilities".
Regulators might take a few years to catch up but if I'm able to DDoS my competition with bogus vulnerabilities then people will do just that.
The CRA says that only "exploitable" vulnerabilities have to be fixed and it does accept VEX statements. So that's good. I would have liked to see "exploited" instead of "exploitable" but it's better than nothing.
I assume/hope the US will follow.