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.