8 ms·

Although vulnerability scanners can be a useful tool, I find it very troublesome that you can utter the sentence "this package contains XX vulnerabilities, and

by DCKing 8y ago

Although vulnerability scanners can be a useful tool, I find it very troublesome that you can utter the sentence "this package contains XX vulnerabilities, and that package contains YY vulnerabilities" and then stop talking. You've provided barely any useful information! The quantity of vulnerabilities in an image is not really all that useful information. A large amount of vulnerabilities in a Docker image does not necessarily imply that there's anything insecure going on. Many people don't realize that a vulnerability is usually defined as "has a CVE security advisory", and that CVEs get assigned based on a worst-case evaluation of the bug. As a result, having a CVE in your container barely tells you anything about your actual vulnerability position. In fact, most of the time you will find that having a CVE in some random utility doesn't matter. Most CVEs in system packages don't apply to most of your containers' threat models. Why not? Because an attacker is very unlikely to be able to use vulnerabilities in these system libraries or utilities. Those utilities are usually not in active use in the first place. Even if they are used, you are not usually in a position to exploit these vulnerabilities as an attacker. Just as an example, a hypothetical outdated version of grep in one of these containers can hypothetically contain many CVEs. But if your Docker service doesn't use grep, then you would need to manually run grep to be vulnerable. And an attacker that is able to run grep in your Docker container has already owned you - it doesn't make a difference that your grep is vulnerable! This hypothetical vulnerable version of grep therefore makes no difference in the security of your container, despite containing many CVEs. It's the quality of these vulnerabilities that matters. Can an attacker actually exploit the vulnerabilities to do bad things? The answer for almost all of these CVEs is "no". But that's not really the product that Snyk sells - Snyk sells a product to show you as many vulnerabilities as possible. Any vulnerability scanner company thinks it can provide most business value (and make the most money) by reporting as many vulnerabilities as it can. For sure it can help you to pinpoint those few vulnerabilities that are exploitable, but that's where your own analysis comes in. I'm not saying there's not a lot to improve in terms of container security. There's a whole bunch to improve there. But focusing on quantities like "amount of CVEs in an image" is not the solution - it's marketing.

tapland 8y ago
'My image only has one vulnerability! (it's a terminal that's reachable from the public internet)'
- rkeene2 8y ago
  Hi, I have a terminal that's reachable from the public Internet that lets you execute arbitrary code: http://rkeene.org:8080/ http://rkeene.org:8080/
- gpm 8y ago
  'My image has zero vulnerabilities! (it's a proprietary terminal that's reachable from the public internet)'. The flip side of "this reports too many vulnerabilities" is "this reports too few vulnerabilities", it should always be made clear we are talking only about publicly known vulnerabilities, which is a subset of all discovered vulnerabilities, which is a subset of all vulnerabilities.
danbolt 8y ago
I’m a hobbyist game developer and I sometimes package web games with Electron. The build/package scripts for the games usually have a small set of npm dependencies, and I’ll usually get a warning indicating that there’s a vulnerability every once in a while. I usually don’t look into them, since the script rarely gets run and isn’t exposed on the internet, but I do wonder if there could be any real vulnerability.
- tracker1 8y ago
  Depends on what modules are used, how they are used and how/when your builds happen and are/were configured.
ben509 8y ago
I agree that a simple count of vulnerabilities is not useful for determining the actual security of a system. But it is useful for maintaining a system if you examine this as an ongoing business process in which you're continually trying to minimize a set of "unknowns". For third-party libraries, I argue it's generally cheaper to get rid of unknowns (when you can) rather than take the time to quantify them. What's left over is easier to prioritize. As you point out, all these things are probably not vulnerabilities, but they might be. What's the likelihood? Well, by upgrading or patching, the probability becomes zero, and then you can stop caring about exactly what it is. Patch it, move on. (And, to be clear, some unknowns are related to your code, so you do want to investigate those, but those are presumably the unknowns that you have the most expertise with, so they're much cheaper.)

by DCKing 8y ago

tapland 8y ago

'My image only has one vulnerability! (it's a terminal that's reachable from the public internet)'

rkeene2 8y ago
Hi, I have a terminal that's reachable from the public Internet that lets you execute arbitrary code: http://rkeene.org:8080/ http://rkeene.org:8080/
gpm 8y ago
'My image has zero vulnerabilities! (it's a proprietary terminal that's reachable from the public internet)'. The flip side of "this reports too many vulnerabilities" is "this reports too few vulnerabilities", it should always be made clear we are talking only about publicly known vulnerabilities, which is a subset of all discovered vulnerabilities, which is a subset of all vulnerabilities.

danbolt 8y ago

I’m a hobbyist game developer and I sometimes package web games with Electron. The build/package scripts for the games usually have a small set of npm dependencies, and I’ll usually get a warning indicating that there’s a vulnerability every once in a while. I usually don’t look into them, since the script rarely gets run and isn’t exposed on the internet, but I do wonder if there could be any real vulnerability.

tracker1 8y ago
Depends on what modules are used, how they are used and how/when your builds happen and are/were configured.

ben509 8y ago

I agree that a simple count of vulnerabilities is not useful for determining the actual security of a system. But it is useful for maintaining a system if you examine this as an ongoing business process in which you're continually trying to minimize a set of "unknowns". For third-party libraries, I argue it's generally cheaper to get rid of unknowns (when you can) rather than take the time to quantify them. What's left over is easier to prioritize. As you point out, all these things are probably not vulnerabilities, but they might be. What's the likelihood? Well, by upgrading or patching, the probability becomes zero, and then you can stop caring about exactly what it is. Patch it, move on. (And, to be clear, some unknowns are related to your code, so you do want to investigate those, but those are presumably the unknowns that you have the most expertise with, so they're much cheaper.)