4 ms·
> The less it changes the the more vulnerable it is, the less compliant it is, the more expensive it is to operate (including insurance), the less it improves a
by abadpoli 2y ago
> The less it changes the the more vulnerable it is, the less compliant it is, the more expensive it is to operate (including insurance), the less it improves and add features, the less people like it.
I don’t follow this. Complexity is what leads to vulnerabilities. Reducing complexity by reusing the same, known code is better for security and for compliance. As a security person, if a team came to me and said they were reusing the same container in both contexts rather than creating a new code base, I would say “hell yeah, less work for all of us”.
There are other reasons why using the same container in both contexts might not be great (see other comments in this thread), but security and compliance aren’t at the top of my list at all (at least not for the reasons you listed).
- mlhpdx 2y agoIf the container has any dependencies, and they change, a lack of change quickly becomes an escalating liability. I’ve heard the “fixed is reliable” arguments for decades and have never seen anything that would justify the widespread failure to keep systems patched.
- mlyle 2y agoHe is not suggesting leaving the container unpatched, so this is unrelated criticism.
- abadpoli 2y agoAs the other commenter said, nobody is saying to make your application completely immutable. You still patch it, add features, etc. But now you only have to patch one container image rather than two (or more).