It doesn’t, as long as those images are good about keeping their dependencies up to date. Because containers are entirely self-sufficient and come packaged with all of their necessary dependencies, there is a potential security concern with images keeping dependencies pinned to old, insecure versions. And catching that can be tricky sometimes, especially when you’re running larger stacks with lots of containers.
But I’d argue that is actually the image being insecure, not containerization itself. It would be no different from a program being considered insecure. We would handle an insecure image the same way we would handle an insecure program: push the maintainer to update their shit to a secure version, or fork it (if it’s OSS) to update the dependencies directly.
Plus, containerization is much more straightforward compared to the olden days of directly managing dependencies. For larger setups, that was basically a full time job by itself. Especially when you have multiple different programs all trying to call different versions of the same dependency.
But it’s a fucking container.
So - speaking as a former security guy - no.
Good thing you are a former security guy then.
Could you please elaborate? How does containerizing harm security?
Because it lets you run code, which can harm your computer. For full compliance, throw your electronics into the nearest volcano.
This is the way
It doesn’t, as long as those images are good about keeping their dependencies up to date. Because containers are entirely self-sufficient and come packaged with all of their necessary dependencies, there is a potential security concern with images keeping dependencies pinned to old, insecure versions. And catching that can be tricky sometimes, especially when you’re running larger stacks with lots of containers.
But I’d argue that is actually the image being insecure, not containerization itself. It would be no different from a program being considered insecure. We would handle an insecure image the same way we would handle an insecure program: push the maintainer to update their shit to a secure version, or fork it (if it’s OSS) to update the dependencies directly.
Plus, containerization is much more straightforward compared to the olden days of directly managing dependencies. For larger setups, that was basically a full time job by itself. Especially when you have multiple different programs all trying to call different versions of the same dependency.