4 ms·
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 oth
by 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 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