4 ms·
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
by 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 agoA "zero vulnerability" approach is probably harder.
- dogma1138 4y agoIt 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 agoAll for the small price of paying attention to the lines in Dockerfile, which is presumably already being looked at/maintained
- dogma1138 4y agoYou 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.
- bravetraveler 4y agoI'm totally with you, I think my short/snide remark wasn't taken quite properly. Containers shouldn't have anything more than what they need. I downplay the scrutiny a bit, boiling it down to "don't put the bad thing in, to begin with" The trick is identifying it, of course - but a good start that's commonly missed is simply stripping (or not supplying) the build tools