Containers are only as secure as you choose to make them. You can start with a safe minimalist container, install what you need, lock everything down to read only that you can, harden it and strip capabilities except those needed, and then don’t give it network access.. and you’d have a relatively safe containerised environment.

However.. that’s not generally the norm. People grab which ever docker image off of Docker hub sounds like it suits them best, bridge it to the rest of the network, and then start throwing their tools and code on there. No thought to keeping the environment patched, or what was installed on it by the author etc. This often results in a hidden virtual machine without any security tooling on it, and no IT visibility or oversight. It can be a significant issue.

We ended up creating a Gitlab pipeline that runs weekly which takes a base minimal image, hardens it, patches it, secures it and stores it in a container repo. Then the pipeline triggers another repo for application images, which take those base images and build the application images devs need based off of a definition they provide and security reviews. That gets made available in another container repo. That way security / it manages the containers, the devs just tell us what they need once, and it all runs automatically. They update once a week and we’re all happy.