7 ms·

No they don't. Container scanning is a load of shit, sorry. Just because something in the container contains a vulnerability, doesn't mean the application itsel

No they don't. Container scanning is a load of shit, sorry. Just because something in the container contains a vulnerability, doesn't mean the application itself is vulnerable. It is not the same thing. Instead of doing the right thing, which would be static and dynamic analysis of the entrypoint to determine the runtime dependencies, the industry has just resorted to saying anything you bundle with your app needs to be 100% invulnerable at all times. It's stupid and practically unachievable if your container is big. Container scanners and dependency bots like Dependabot are snake oil solutions sold to people too lazy to actually secure their application.

sclarisse 4y ago
Oh, but I am going to defend Dependabot. It’s not there to secure your app. It’s there so your smallcorp team can get one or two PRs a day against your codebases, updating your software dependencies one at a time — rather than an unmanageable mess or slow rot on old systems. That’s literally the original design goal. Any security implications are indirect.
jjav 4y ago
> Container scanners and dependency bots like Dependabot are snake oil solutions sold to people too lazy to actually secure their application. Many years ago I'd have agreed with this so hard I'd hurt myself. These days I've moved on to a much more nuanced "maybe". Also many years ago the code might've had half a dozen dependencies and the developers knew quite well how they were used and what code paths were relevant now or in the near future. So it was fairly tractable to say: Nope, that doesn't impact us, ignore. These days there are thousands of dependencies and if I grab a random developer from the team and ask them "How is libfoo being used?" the response is most likely along the lines of "libfoo? never heard of it" because it was brought in as a third-degree dependency. So is the vulnerable functionality conceivably relevant or not? Nobody in the house knows. In such a world, it is quite often easiest to have a blanket policy of update/patch everything if at all possible. Only if some upgrade causes trouble, then spend human cycles to review and analyze what's up. I've seen teams that try to analyze everything fall further and further behind because vulnerabilities come in faster than they can analyze.
miohtama 4y ago
Here is the source report cited in the article: https://sysdig.com/2023-cloud-native-security-and-usage-report/ https://sysdig.com/2023-cloud-native-security-and-usage-repo... It is provided by: "Sysdig Secure: Cloud, container, and Kubernetes security that closes the loop from source to run." It's the best interest of security companies to sell scareware.
sclarisse 4y ago
I have a container that contains some vendor-provided software used to support GPU-driven machine learning in a high performance cluster. This vendor didn’t do the cleanest build ever, and so the package they supply installs kernel headers. Based on those headers, the container scanner is convinced that my container is vulnerable to many exciting things, like Atheros WiFi chipset driver vulnerabilities.
dogma1138 4y ago
A counter point when you run 1000’s of containers or even 10’s of 1000’s it’s hard to near impossible to validate what can effectively be exploited and what can’t which is why most vulnerability management program take a zero vulnerabilities approach and deal with exceptions on a case by case basis. One of the easiest ways of dealing with these vulnerabilities is by actually building your images correct there is rarely a need to take on every dependency of your base OS so by either manually crafting images or by using image minimizers like DockerSlim you can make your life much easier. Vulnerability scanners especially for container images are indeed problematic since they are often only doing static analysis on the image SBOM and comparing it to a list of vulnerabilities, this is where half of the problem begins which is again where tools like DockerSlim come really handy. DockerSlim also has another benefit of forcing teams to have good test coverage for the minimization process to work correctly and also produces runtime policy files which can be used to restrict containers further.
- pydry 4y ago
  A "zero vulnerability" approach is probably harder.
  - dogma1138 4y ago
    It is not, at least not as far as a policy goes. Zero by default is really the only effective way to handle these situations, especially when you’ll have to otherwise prove that it’s not vulnerable as the cost of getting it wrong hangs over the security team.
    - bravetraveler 4y ago
      All for the small price of paying attention to the lines in Dockerfile, which is presumably already being looked at/maintained
      - dogma1138 4y ago
        You are underestimating the problem, looking at a few lines in a docker file will not solve this issue. Take for example various framework vulnerabilities the amount of effort require to ensure that these are not exploitable is monumental even if the specific containerized workload can be proven not to invoke any vulnerable code it doesn’t mean that other workloads won’t today or tomorrow. Then you have other vulnerabilities that may not be relevant to your workload at all however if your container isn’t locked down properly, you don’t have runtime protection and there are other vulnerabilities they would allow an attacker to chain them together. This is why reducing the attack surface of the underlying image itself is one of the most cost effective preventative measures you can employ.

sclarisse 4y ago

Oh, but I am going to defend Dependabot. It’s not there to secure your app. It’s there so your smallcorp team can get one or two PRs a day against your codebases, updating your software dependencies one at a time — rather than an unmanageable mess or slow rot on old systems. That’s literally the original design goal. Any security implications are indirect.

jjav 4y ago

> Container scanners and dependency bots like Dependabot are snake oil solutions sold to people too lazy to actually secure their application. Many years ago I'd have agreed with this so hard I'd hurt myself. These days I've moved on to a much more nuanced "maybe". Also many years ago the code might've had half a dozen dependencies and the developers knew quite well how they were used and what code paths were relevant now or in the near future. So it was fairly tractable to say: Nope, that doesn't impact us, ignore. These days there are thousands of dependencies and if I grab a random developer from the team and ask them "How is libfoo being used?" the response is most likely along the lines of "libfoo? never heard of it" because it was brought in as a third-degree dependency. So is the vulnerable functionality conceivably relevant or not? Nobody in the house knows. In such a world, it is quite often easiest to have a blanket policy of update/patch everything if at all possible. Only if some upgrade causes trouble, then spend human cycles to review and analyze what's up. I've seen teams that try to analyze everything fall further and further behind because vulnerabilities come in faster than they can analyze.

miohtama 4y ago

Here is the source report cited in the article: https://sysdig.com/2023-cloud-native-security-and-usage-report/ https://sysdig.com/2023-cloud-native-security-and-usage-repo... It is provided by: "Sysdig Secure: Cloud, container, and Kubernetes security that closes the loop from source to run." It's the best interest of security companies to sell scareware.

sclarisse 4y ago

I have a container that contains some vendor-provided software used to support GPU-driven machine learning in a high performance cluster. This vendor didn’t do the cleanest build ever, and so the package they supply installs kernel headers. Based on those headers, the container scanner is convinced that my container is vulnerable to many exciting things, like Atheros WiFi chipset driver vulnerabilities.

dogma1138 4y ago

A counter point when you run 1000’s of containers or even 10’s of 1000’s it’s hard to near impossible to validate what can effectively be exploited and what can’t which is why most vulnerability management program take a zero vulnerabilities approach and deal with exceptions on a case by case basis. One of the easiest ways of dealing with these vulnerabilities is by actually building your images correct there is rarely a need to take on every dependency of your base OS so by either manually crafting images or by using image minimizers like DockerSlim you can make your life much easier. Vulnerability scanners especially for container images are indeed problematic since they are often only doing static analysis on the image SBOM and comparing it to a list of vulnerabilities, this is where half of the problem begins which is again where tools like DockerSlim come really handy. DockerSlim also has another benefit of forcing teams to have good test coverage for the minimization process to work correctly and also produces runtime policy files which can be used to restrict containers further.

pydry 4y ago
A "zero vulnerability" approach is probably harder.
- dogma1138 4y ago
  It is not, at least not as far as a policy goes. Zero by default is really the only effective way to handle these situations, especially when you’ll have to otherwise prove that it’s not vulnerable as the cost of getting it wrong hangs over the security team.
  - bravetraveler 4y ago
    All for the small price of paying attention to the lines in Dockerfile, which is presumably already being looked at/maintained
    - dogma1138 4y ago
      You are underestimating the problem, looking at a few lines in a docker file will not solve this issue. Take for example various framework vulnerabilities the amount of effort require to ensure that these are not exploitable is monumental even if the specific containerized workload can be proven not to invoke any vulnerable code it doesn’t mean that other workloads won’t today or tomorrow. Then you have other vulnerabilities that may not be relevant to your workload at all however if your container isn’t locked down properly, you don’t have runtime protection and there are other vulnerabilities they would allow an attacker to chain them together. This is why reducing the attack surface of the underlying image itself is one of the most cost effective preventative measures you can employ.